Blog GIS Support


Tworzenie skryptów Pythona w QGIS za pomocą narzędzi geoprocesingu

Wtyczka Processing (do wersji QGIS 1.8 SEXTANTE) zawiera wiele pomocnych narzędzi usprawniających pracę z danymi przestrzennymi w QGIS. Jednym z nich jest mechanizm pozwalający na tworzenie i uruchamianie przez użytkowników skryptów napisanych w języku programowania Python. Dzięki temu aby dodać nową funkcjonalność nie trzeba tworzyć nowej wtyczki, a przy tym martwić się o zbudowanie interfejsu, właściwe wypełnienie metadanych itp. Skrypty traktowane są przez Processing w ten sam sposób jak pozostałe algorytmy. Można je więc uruchomić w oknie dialogowym lub w trybie wsadowym jak również wykorzystać w graficznym modelarzu. Co więcej, w skryptach można wykorzystać już istniejące algorytmy.

Edytor skryptu

Aby stworzyć nowy skrypt należy w oknie Narzędzia geoprocessingu rozwinąć pozycję Scripts ->Tools i podwójnie kliknąć na Create new script. Zostanie wyświetlony edytor skryptu. Posiada on kilka funkcji ułatwiających pisanie kodu źródłowego jak kolorowanie i autouzupełnianie składni, zwijanie/rozwijanie bloków kodu czy numerowanie linii. W górnej części okna dostępne są przyciski umożliwiające m.in. zapis zmian, edycję pomocy czy uruchomienie skryptu.

edytor

Tworzenie skryptu

Definiowanie danych wejściowych

Na początku kodu można określić nazwę grupy, w której będzie wyświetlany skrypt w oknie Narzędzi geoprocessingu:

[code lang=”python”]##Nazwa grupy=group[/code]

Jeśli sami nie określimy grupy to skrypt zostanie przypisany do grupy User scripts.

Następnie należy określić pola do wprowadzania przez użytkownika niezbędnych parametrów. Każdy parametr określa się w jednej linii zaczynającej się znakami ##, następnie należy podać jego nazwę, typ danych oraz, w niektórych przypadkach, opcje:

[code lang=”python”]##nazwa_zmiennej=typ_danych [opcje][/code]

Nazwy zmiennych nie powinny zawierać spacji – zamiast niej należy wpisać podkreślnik – wtyczka automatycznie zamieni go w spację. Nie należy również korzystać ze znaków specjalnych, w tym polskich znaków diakrytycznych. Opcje pozwalają m.in. na ustawienie domyślnych wartości lub typu geometrii warstwy wektorowej, w większości przypadków nie są one jednak wymagane. Należy je oddzielić od typu danych pojedynczą spacją. Aktualnie dostępne są następujące typy danych:

  1. raster – pole wyboru umożliwiające wybór jednej z wczytanych do QGIS warstw rastrowych lub wskazanie pliku na dysku;
  2. vector – jw. z tym że dotyczy warstw wektorowych. Domyślnie dostępne są wszystkie rodzaje warstw, jednak istnieje możliwość określenia rodzaju geometrii poprzez ustawienie odpowiedniej opcji: point, line, polygon. Przykładowo w celu ograniczenia wyboru użytkownika do warstw punktowych należy wpisać:
    [code lang=”python” gutter=”false”]##warstwa_punktowa=vector point[/code]
  3. table – pole wyboru z tabelami, wyświetlane są warstwy wektorowe jak i tabele nieprzestrzenne (pliki CSV, excel);
  4. field – pole wyboru z polami z tabeli atrybutów danej warstwy wektorowej lub tabeli. Warstwę określa się poprzez podanie jej nazwy jako opcji np.:
    [code lang=”python”]##warstwa=vector
    ##pole_tabeli=field warstwa[/code]
  5. multiple raster i multiple vector – umożliwiają jednoczesny wybór więcej niż jednej warstwy;
  6. selection – pole wyboru ze zdefiniowanymi elementami, kolejne pozycje należy rozdzielić średnikiem:
    [code lang=”python” gutter=”false”]##typ_dzialki=selection budowlana;rolnicza;woda powierzchniowa;nieznany[/code]
  7. 
    

    selection

  8. boolean – wybór wartości logicznej prawda/fałsz (tak/nie);
  9. number – wartość liczbowa, jako opcję można podać wartość domyślną np.:
    [code lang=”python” gutter=”false”]##liczba=number 4
    ##liczba_rzeczywista=number 2.5[/code]

    Liczby rzeczywiste należy podawać z kropką;

  10. string – dowolny łańcuch znaków, podobnie jak przy liczbie można określić wartość domyślną;
  11. extent – zakres geograficzny (Xmin, Xmax, Ymin, Ymax);
  12. crs – wybór układu współrzędnych, domyślnym układem jest WGS 84, ale można to zmienić ustawiając opcję parametru np.:
    [code lang=”python” gutter=”false”]##uklad=crs EPSG:2180[/code]
  13. file – wybór dowolnego pliku z dysku;
  14. folder – jw. ale wybór katalogu;

Tak przedstawiają się powyższe kontrolki w oknie skryptu:

cale_okno - Kopia

Określanie danych wyjściowych

Dane wyjściowe określa się w taki samo sposób jak wejściowe. Jako typ danych należy podać output, natomiast jako opcję należy wpisać wybrany rodzaj:

  1. output raster – warstwa rastrowa;
  2. output vector – warstwa wektorowa;
  3. output table – tabela;
  4. output html – format HTML;
  5. output file – plik;
  6. output number – liczba;
  7. output string – łańcuch znaków.

[code lang=”python”]##warstwa_wyjsciowa=output vector
##liczba_iteracji=output number[/code]

Skrypt może mieć określonych wiele danych wyjściowych. Wartości przyjmowane przez zmienne wyjściowe to, w zależności od ich rodzaju, ścieżka dostępu do pliku (1-5), liczba (6) lub łańcuch znaków (7).

Funkcje pomocnicze

Dostęp do parametrów określonych przez użytkownika odbywa się poprzez odwołanie do zmiennej za pomocą zdefiniowanej na początku nazwy (stąd zakaz korzystania w nazwach zmiennych ze spacji i znaków specjalnych). Część danych jak liczby czy łańcuchy znaków są określone wprost tzn. w formie podanej w oknie skryptu. Aby mieć dostęp do pozostałych można skorzystać z dodatkowych funkcji udostępnianych przez wtyczkę Processing które ułatwiają pracę z danymi wejściowymi:

  • getObject(str) – zwraca klasę reprezentującą w QGIS warstwę (QgsVectorLayer lub QgsRasterLayer), jako parametr może przyjmować warstwę wskazaną przez użytkownika;
  • features(layer) – zwraca iterator po obiektach danej warstwy;
    [notice]Jeśliw opcjach Geoprocesingu zaznaczona jest opcja Use only selected features to zostaną zwrócone tylko zaznaczone obiekty. Jeśli nie ma zaznaczenia to iteracja odbędzie się po wszystkich obiektach.[/notice]
  • values(layer, field1, field2, …) – zwraca słownik, w którym kluczem jest nazwa pola z tabeli atrybutów, a wartość to lista wszystkich wartości z tego pola (obsługuje tylko wartości numeryczne!);
  • uniqueValues(layer, field) – zwraca listę unikalnych wartości z pola w tabeli atrybutów.

Poniższy przykład pozwala zapisać do pliku tekstowego unikalne wartości z tabeli atrybutów warstwy wektorowej:

[code lang=”python”]##input=vector
##pole=field input
##plik=output file
wektor = processing.getObject(input)
wartosci = processing.uniqueValues(wektor, pole)
f = open(plik, ‘w’)
try:
for wartosc in wartosci:
f.write(‘%s\n’ % str(wartosc))
finally:
f.close()
[/code]

  1. Zdefiniowanie warstwy wejściowej. Zmienna input przechowuje ścieżkę dostępu do warstwy.
  2. Wybór przez użytkownika pola z tabeli atrybutów wybranej warstwy.
  3. Plik, do którego zostaną zapisane dane.
  4. Pobranie wskaźnika do warstwy wejściowej (klasa QgsVectorLayer).
  5. Pobranie unikalnych wartości z wybranego pola tabeli atrybutów.
  6. Otwarcie pliku do zapisu.
  7. Zabezpieczenie przed błędem w trakcie zapisu.
  8. Iteracja po pobranych wartościach.
  9. Zapis wartości do pliku, dane konwertowane są do łańcucha znaków.
  10. Po zakończeniu…
  11. … zamknięcie pliku.

Drugą grupą funkcji pomocniczych są funkcje pozwalające tworzyć nowe warstwy rastrowe, wektorowe i tabele. Znajdują się one w module processing.core.

  • VectorWriter(warstwa_wyjsciowa,kodowanie_znakow,pola,typ_geometrii,uklad_wspolrzednych)
  • RasterWriter(warstwa_wyjsciowa, minX, minY, maxX, maxY, rozmiar_komorki, liczba_kanalow, uklad_wspolrzednych)
  • TableWriter(tabela_wyjsciowa,kodowanie_znakow,pola)

[code lang=”python”]##input=vector
##output=output vector
from processing.core.VectorWriter import VectorWriter
vectorLayer = processing.getObject(input)
writer = VectorWriter(output, vectorLayer.dataProvider().encoding(), vectorLayer.pendingFields(),vectorLayer.wkbType(), vectorLayer.crs())
features = processing.features(vectorLayer)
for feat in features:
writer.addFeature(feat)
del writer[/code]

  1. Zdefiniowanie warstwy wejściowej.
  2. Definicja warstwy wyjściowej, zmienna output również przechowuje ścieżkę do pliku.
  3. Import klasy VectorWriter do stworzenia nowej warstwy na dysku.
  4. vectorLayer przechowuje instancję klasy QgsVectorLayer.
  5. Stworzenie pliku na dysku, większość parametrów pobrana jest z warstwy wejściowej.
  6. Stworzenie iteratora po obiektach warstwy.
  7. Pętla po obiektach warstwy.
  8. Dodanie obiektu do nowej warstwy.
  9. Zamknięcie pliku nowej warstwy.

Wykorzystanie istniejących algorytmów

Istnieje również możliwość wykorzystania dostępnych algorytmów wtyczki Processing. W tym celu należy wywołać funkcję runalg z odpowiednimi parametrami:

[code lang=”python”]##input_raster=raster
##input_wektor=vector
##warstwa_wyjsciowa=output vector

wektor = processing.getObject(input_wektor)
raster = processing.getObject(input_raster)
processing.runalg(‘qgis:pointsfromlines’, raster, wektor, warstwa_wyjsciowa)[/code]

W powyższym przykładzie zmienne raster i wektor to odpowiednio instancje klas QgsRasterLayer i QgsVectorLayer uzyskane dzięki funkcji getObject.
W jaki sposób można uzyskać informacje o algorytmach? I w tym przypadku z pomocą przychodzi wtyczka Processing. Najprościej jest z nich korzystać za pomocą Konsoli Pythona QGIS.
Funkcja alglist wyświetla wszystkie dostępne algorytmy:

[code lang=”python”]>>> processing.alglist()
Add autoincremental field—————>qgis:addautoincrementalfield
Add field to attributes table———–>qgis:addfieldtoattributestable
Advanced Python field calculator——–>qgis:advancedpythonfieldcalculator
Basic statistics for numeric fields—–>qgis:basicstatisticsfornumericfields
Basic statistics for text fields——–>qgis:basicstatisticsfortextfields
Clip————————————>qgis:clip
…[/code]

Po lewej stronie wyświetlany jest krótki opis algorytmu, a po prawej stronie jego nazwa, którą należy użyć jako pierwszy parametr funkcji runlag. Możliwe jest ograniczenie wyników poprzez podanie tekstu (fragmentu nazwy lub opisu) jako parametru funkcji alglist() np.:

[code lang=”python”]>>> processing.alglist(‘buffer’)
Fixed distance buffer——————->qgis:fixeddistancebuffer
Variable distance buffer—————->qgis:variabledistancebuffer
Grid buffer—————————–>saga:gridbuffer
Grid proximity buffer——————->saga:gridproximitybuffer
…[/code]

Aby uzyskać szczegółowe informacje odnośnie konkretnego algorytmu należy skorzystać z funkcji alghelp np.:

[code lang=”python”]>>> processing.alghelp(‘qgis:fixeddistancebuffer’)
ALGORITHM: Fixed distance buffer
INPUT
DISTANCE
SEGMENTS
DISSOLVE
OUTPUT [/code]

Funkcja ta wyświetla opis algorytmu oraz jego parametry. Jeśli algorytm ma parametry typu <ParameterSelection>, czyli wybór z góry określonych opcji, dodatkowo na końcu znajduje się spis dostępnych wartości.

[code lang=”python”]&gt;&gt;&gt; processing.alghelp(&quot;saga:slopeaspectcurvature&quot;)
ALGORITHM: Slope, aspect, curvature
ELEVATION
METHOD
SLOPE
ASPECT
CURV
HCURV
VCURV

METHOD(Method)
0 – [0] Maximum Slope (Travis et al. 1975)
1 – [1] Maximum Triangle Slope (Tarboton 1997)
2 – [2] Least Squares Fitted Plane (Horn 1981, Costa-Cabral &amp; Burgess 1996)
3 – [3] Fit 2.Degree Polynom (Bauer, Rohdenburg, Bork 1985)
4 – [4] Fit 2.Degree Polynom (Heerdegen &amp; Beran 1982)
5 – [5] Fit 2.Degree Polynom (Zevenbergen &amp; Thorne 1987)
6 – [6] Fit 3.Degree Polynom (Haralick 1983)[/code]

Opcje te można wylistować również funkcją algoptions(nazwa_algorytmu). Aby je ustawić należy podać numer danej opcji według kolejności:

[code lang=”python” gutter=”false”]processing.runlag(&quot;saga:slopeaspectcurvature&quot;, raster, 1, nachylenie, …)[/code]

W powyższym przykładzie zostanie użyta metoda Maximum Triangle Slope.

Informacje o postępie algorytmu

W trakcie działania skryptu może zdarzyć się, że chcemy wyświetlić dodatkowe informacje o aktualnym postępie pracy. Jest to szczególnie przydatne przy czasochłonnych operacjach. Z pomocą przychodzi moduł progress, który udostępnia metody pozwalające ustawić procentowe zaawansowanie obliczeń lub opis aktualnych działań:

  • progress.setPercentage(i) – pozwala ustawić wartość paska postępu w dolnej części okna, parametr i powinien mieć wartość od 0 do 100;
  • progress.setInfo(tekst, error=False) – wyświetla podany komunikat w oknie Log. Jeśli drugi argument zostanie ustawiony na True to wyświetlony tekst będzie miał kolor czerwony (przydatne przy informowaniu o błędach);
  • progress.setText(tekst) – jw. ale dodatkowo tekst pojawia się nad paskiem postępu;
  • progress.setCommand(tekst) – wyświetla komunikat w oknie Log w formacie tekstu o stałej szerokości znaków;
  • progress.setDebugInfo(tekst) – wyświetla komunikat w oknie Log w kolorze niebieskim;
  • progress.setConsoleInfo(tekst) – jw. ale w kolorze jasnoszarym.

[notice]Funkcje setCommand, setDebugInfo i setConsoleInfo wyświetlą informacje w oknie tylko jeśli w opcjach Geoprocesingu zaznaczona jest opcja Show extra info in Log panel. Są one pomocne głównie przy tworzeniu skryptu, w ostatecznej wersji należy używać setInfo lub setText.[/notice]

Przykładowe użycie powyższych funkcji:

[code lang=”python”]from time import sleep
progress.setInfo(‘setInfo(tekst)’)
progress.setInfo(‘setInfo(tekst, True)’, True)
progress.setCommand(‘setCommand(tekst)’)
progress.setDebugInfo(‘setDebugInfo(tekst)’)
progress.setConsoleInfo(‘setConsoleInfo(tekst)’)
for i in range(10):
progress.setPercentage(i*10)
progress.setText(‘setPercentage: %d’ % (i*10))
sleep(0.5)[/code]

log_window

Przerywanie działania skryptu

Jeżeli po uruchomieniu algorytmu wystąpi krytyczny błąd uniemożliwiający dalsze działanie należy go przerwać. W tym celu można wykorzystać klasę GeoAlgorithmExecutionException, która pozwala przerwać działanie skryptu oraz wyświetlić odpowiedni komunikat:

[code lang=”python”]##dzielnik=number 0
from processing.core.GeoAlgorithmExecutionException import GeoAlgorithmExecutionException
if dzielnik == 0:
raise GeoAlgorithmExecutionException(u’Dzielenie przez zero!’)

[/code]

error_log

Edytor pomocy

help_editor

Edytor pomocy pozwala przygotować opis algorytmu i jego parametrów. Można go wywołać przyciskiem edithelp. W górnej części wyświetlony jest podgląd pomocy. Poniżej, z lewej strony znajduje się lista elementów do edycji. Dostępne pozycje:

  • Algorithm description – ogólny opis skryptu;
  • Input parameters – opis poszczególnych parametrów;
  • Output – opis danych wyjściowych;
  • Algorithm created by – autor skryptu;
  • Algorithm help written by – autor pomocy.

Po wybraniu pozycji w prawej części okna można wpisać treść pomocy dla danego elementu. Pliki pomocy mają taką samą nazwę jak skrypt, ale mają rozszerzenie .help.


Stworzone skrypty widoczne są w oknie Narzędzia geoprocessingu pod pozycją Scripts . Po zapisaniu można je używać jak pozostałe algorytmy lub wykorzystać w graficznym modelarzu lub innym skrypcie.

narzedzia_geoprocessingu_skrypty

Domyślnie przechowywane one są w katalogu konfiguracyjnym QGIS /.qgis2/processing/scripts/. Ścieżkę tą można zmienić w opcjach geoprocesingu. Można je kopiować i przenosić na inne komputery jak zwykłe pliki.

skrypty_pliki

Tagi: ,
Rozwój bazy wiedzy GIS Support

Analiza statystyk naszej strony www wyraźnie wskazuje, że dział Baza wiedzy cieszy się niezwykłą popularnością (głównie wśród studentów i urzędników). Te same sygnały docierają do nas podczas spotkań na konferencjach. Niestety ze względu na zmianę formy działalności oraz dużą ilością pracy, nie mamy czasu na jej rozwój i pisanie nowych artykułów.

W związku z tym zmieniamy formułę funkcjonowania bazy wiedzy. Zapraszamy studentów i wszystkich zainteresowanych do współpracy w publikowaniu artykułów open source GIS, w szczególności:

  • opis lub aktualizacja opisu wtyczek QGIS,
  • opis działań krok po kroku w QGIS,
  • wszystkiego co związane jest z OpenStreetMap,
  • podstawy GIS,
  • analizy przestrzenne

Jesteśmy również zainteresowani zupełnie nowymi, nie opisanymi dotąd obszarami wiedzy.

Każdy zainteresowany dostanie konto do logowania się na stronie oraz możliwość tworzenia szkiców. Szkic po zaakceptowaniu, pojawi się w bazie wiedzy opatrzony imieniem i nazwiskiem, adresem e-mail oraz notką o autorze. Jest to dobra okazja do zaprezentowania swojej wiedzy i zainteresowań w praktycznym zastosowaniu GIS. Wszystkich zainteresowanych prosimy o kontakt drogą e-mailową.

Tagi: , ,
Analiza funkcjonalności oprogramowania QuantumGIS w zakresie analiz przestrzennych na przykładzie danych topograficznych. Katarzyna Kisielińska

Praca magisterska Pani Katarzyny Kisielińskiej, napisana pod kierunkiem dr. inż. Pawła Kowalskiego w Zakładzie Kartografii na Wydziale Geodezji i Kartografii Politechniki Warszawskiej.

Praca magisterska ma swoją charakterystykę i nie czyta jej się jak thrillera od deski do deski, ale w przypadku magisterki Pani Kisielińskiej nie o to chodzi. Jest to pierwsza od dawna publikacja, dostępna za darmo, po polsku, która porusza tematykę QGIS.

Polecamy ją każdemu, kto już trochę zna QGIS i chcę poczytać o jego możliwościach w zakresie analiz przestrzennych. Dużą wartością dodaną jest porównanie podstawowych możliwości analitycznych z QGIS i ArcGIS.

Praca do pobrania ze strony Katedry lub z naszego serwera.

Tagi: , ,
QGIS 2.0 wydany!

splash_qgis2.0

Po wielu miesiącach wytężonej pracy wydana została nowa wersja QGIS oznaczona numerem 2.0 i nazwą Dufour. Przynosi ona wiele zmian dla użytkowników, zarówno w istniejących dotychczas funkcjonalnościach jak i nowych narzędziach ułatwiających pracę z danymi przestrzennymi. Należy zaznaczyć że aplikacja zmieniła swoja nazwę, od wersji 2.0 Quantum GIS został przemianowany na QGIS.

Najważniejsza zmiana nie jest widoczna dla użytkownika od razu po uruchomieniu aplikacji. Jej efektem jest to, że wtyczki z wcześniejszych wersji oprogramowania nie działają w nowej wersji. Jest to związane ze znacznymi zmianami w API, które jest teraz bardziej przejrzyste i logiczne dla programistów. Na szczęście większość wtyczek została już przepisana i jest dostępna przez (również zaprojektowany od nowa) menedżer wtyczek, a liczba kompatybilnych rozszerzeń sukcesywnie rośnie.

Interfejs użytkownika został odświeżony. Zmieniono wygląd większości ikon, zakładki w oknach dialogowych zostały zastąpione przez listę wyświetlaną z lewej strony danego okna, udoskonalono konsolę Pythona i narzędzie do etykietowania obiektów. Zarządzanie stylami warstw wektorowych odbywa się teraz z pomocą rozwijanej listy, a nie kolejnych okien dialogowych. Również obsługa warstw rastrowych została gruntownie przebudowana. Wtyczkę SEXTANTE zintegrowano z QGIS i przemianowano na Processing (przetłumaczone w polskiej wersji na Narzędzia). Narzędzia geoprocessingu można teraz wywołać z poziomu konsoli, która jest wywoływana poprzez kombinację klawiszy Ctrl+Alt+M.

Wśród nowych funkcjonalności chyba najefektowniejszą jest dodanie możliwości przenikania się warstw (tzw. blend mode), przykłady wykorzystania można znaleźć pod tymi adresami:

Nowa wtyczka Kontrola topologii pozwala na sprawdzanie wzajemnych zależności pomiędzy obiektami lub warstwami co pozwala na odnalezienie i ewentualne usunięcie błędów geometrycznych. Dodano natywne sterowniki pozwalające na bezpośrednią obsługę baz danych Oracle i usługi Web Coverage Service.

Zmiany nie ominęły również kompozytora wydruków. Dzięki integracji wtyczki Atlas można generować serie wydruków w oparciu o wybraną warstwę, dodano prowadnice i przyciąganie do obiektów ułatwiające odpowiednie rozmieszczenie kompozycji czy wsparcie dla wielokolumnowych legend. Kompozytor pozwala od teraz tworzyć również wielostronicowe dokumenty.

Razem z wydaniem nowej wersji QGIS odświeżona została strona główna projektu http://qgis.org/.

Powyżej przedstawiono jedynie część zmian jakie wprowadzono w QGSI 2.0. W serwisie Flickr dostępne są galerie zrzutów ekranowych przedstawiające QGIS 2.0 w akcji (QGIS i przykładowe mapy – linki z oficjalnego polskiego bloga projektu).

Najnowszą wersję można ściągnąć z tej strony. Dostępna jest wersja 32 i 64 bitowa. Dla systemów Windows jest ona również dostępna przez instalator OSGeo4W.

Tagi:
Otwarty Katalog Danych RDOŚ w Białymstoku

opendata-logoRegionalna Dyrekcja Ochrony Środowiska w Białymstoku uruchomiła Katalog Otwartych Danych, dzięki któremu każdy zainteresowany ma nieograniczony dostęp do danych źródłowych szybko, wygodnie i bezproblemowo. Poniżej znajduje się pełna informacja na ten temat.

Gratulujemy inicjatywy i liczymy, że uda się zachęcić inne instytucje publiczne do podobnych działań. Takie podejście do udostępniania danych ma tylko zalety:

  • Użytkownicy danych nie muszą nigdzie dzwonić i wypełniać wniosków
  • Pracownicy mogą zająć się swoimi zadaniami zamiast co chwilę przygotowywać dane na konkretne zamówienie
  • Dane zostały upublicznione na podstawie ustawy o dostępie do informacji publicznej (czytaj więcej)
  • Dane są w formatach GIS, jak i tabelarycznych, dzięki czemu nawet użytkownik bez wiedzy specjalistycznej może skorzystać.
  • Katalog powstał siłami własnymi RDOŚ – bez dodatkowego finansowania.
  • Dane upublicznione są w sposób standardowy (WMS i WFS), co pozwoli na ich szerokie wykorzystanie
  • Usługi sieciowe działają (co nie jest normą)
  • Usługi sieciowe działają szybko (co absolutnie nie jest normą)

Warto zajrzeć do rejestru zmian w serwisie w celu zapoznania się z nowościami

Jeszcze nie wszystkie dane są w katalogu, ale liczymy, że niedługo wszystkie dane będą publicznie dostępne. Adres WMS i WFS do wszystkich danych przestrzennych:

[important]http://sdi.gdos.gov.pl/podlaskie/[/important]

Regionalna Dyrekcja Ochrony Środowiska (RDOŚ) w Białymstoku uruchomiła Katalog Otwartych Danych, w którym można znaleźć wiele interesujących informacji związanych z szeroko pojętą ochroną środowiska województwa podlaskiego.
Na zbiór udostępnionych danych składają się dane przestrzenne, zestawienia tabelaryczne, a także elektroniczne wersje publikacji wydanych podczas pięciu lat działalności RDOŚ w Białymstoku. Informacje zebrano według grup tematycznych obejmujących formy ochrony przyrody, strefy ochrony gatunkowej, ochronę międzynarodową, służby ochrony środowiska, infrastrukturę ochrony środowiska oraz edukację ekologiczną.

Duży zbiór informacji stawią dane przestrzenne związane z ochroną przyrody oraz infrastruktury ochrony środowiska. Dane udostępniane są przez usługi sieciowe zgodne ze standardami Open Geospatial Consortium – WFS (Web Feature Service – do pobierania danych w formacie GML) oraz WMS (Web Map Service – do przeglądania danych).

Wśród zebranych danych część udostępniono po raz pierwszy w historii – do tej grupy należą elektroniczne wersje publikacji RDOŚ, a także unikalne zbiory danych przestrzennych związane z ochroną przyrody, m.in. ochroną międzynarodową wynikającą z „Konwencji o obszarach wodno-błotnych mających znaczenie międzynarodowe, zwłaszcza jako środowisko życiowe ptactwa wodnego”, sporządzonej w Ramsarze czy obszary objęte ochroną na podstawie „Listy Światowego Dziedzictwa Kulturowego i Przyrodniczego Ludzkości” UNESCO.

Katalog jest ciągle uzupełniany i będzie rozwijany w wielu płaszczyznach, zarówno w kwestii dostępnych zasobów jak i nowych funkcjonalności. Korzystanie z serwisu jest bezpłatne, a kwestie prawne regulowane są przepisami o ponownym wykorzystaniu informacji publicznych.

Więcej informacji pod adresem: http://www.bialystok.rdos.gov.pl/opendata/

Tagi: ,
Osm2gis – nowy sposób na pobieranie danych OSM?

Pod adresem http://www.osm974.re/osm2gis francuska firma GeoTribu uruchomiła usługę, umożliwiającą pobieranie wycinków bazy danych w formatach zgodnych z aplikacjami GIS. W odróżnieniu od innych podobnych usług, łączy w sobie możliwość wybrania obszaru niezależnie od granic administracyjnych, dostępność standardowych formatów GIS i łatwość obsługi.

Pobieranie danych za pomocą osm2gis jest bardzo proste. Korzystając z wyświetlonej mapy, należy wybrać obszar zainteresowania – nie może być on zbyt duży, aplikacja akceptuje obszary o powierzchni rzędu pojedynczego powiatu lub dużej aglomeracji miejskiej.

Strona główna osm2gis

Strona główna osm2gis

Po dopasowaniu właściwego obszaru, możemy przystąpić do „zamówienia“ danych. Możemy wybrać format (KML,GML,TAB,SHP lub SQLite) i układ współrzędnych (WGS84 albo Google Mercator). Kolejnym krokiem jest podanie adresu e-mail, na który zostanie przesłane powiadomienie o możliwości pobrania danych wraz z linkiem.

Wybór opcji pobierania danych

Wybór opcji pobierania danych

Aplikacja umożliwia pobranie porcji danych raz na godzinę z jednego adresu IP. Dane pochodzą z kopii bazy danych OSM utrzymywanej przez stowarzyszenie OpenStreetMap France.

Dane pobieramy w postaci archiwum ZIP, gdzie w podkatalogach umieszczono poszczególne formaty. Niezależnie od formatu, tworzone są 3 niezależne warstwy – osm_point, osm_line i osm_polygon.

Tabela atrybutów każdej warstwy składa się z 75 kolumn, zawierających większość używanych tagów, oprócz tego dołączona jest kolumna o nazwie tags w której zapisano wszystkie tagi obiektu w formacie klucz => wartość oddzielone przecinkami. Jest to więc znacznie bogatsza tabela, niż tworzona przez standardową wtyczkę QGIS.

Do tego etapu wszystko wygląda wspaniale, jednak usługa ta ma bardzo istotne wady. Po pierwsze – używany konwerter zupełnie nie radzi sobie z obiektami powierzchniowymi. Zdarzają się niezamknięte linie zamiast poligonów, lub wręcz zupełnie nieużyteczne warstwy bez czytelnej geometrii. Z uwagi na skomplikowany sposób zapisu poligonów w modelu danych OSM, generowanie ich geometrii w prawidłowy sposób jest sporym wyzwaniem – nie jest to jednak żadne wytłumaczenie, ponieważ istniejące konwertery radzą sobie z problemem dość dobrze.

Po drugie, w przypadku wyboru opcji zapisu w SQLite dostaniemy wynik w „czystym“ SQLite, bez użycia rozszerzenia SpatiaLite. Nie skorzystamy więc z dobrodziejstw jakie daje przestrzenna baza danych, czyli zaawansowanych indeksów przestrzennych i możliwości wykonywania analiz wprost z poziomu zapytań SQL. Ponadto zamiast jednego pliku z bazą i trzema tabelami wewnątrz, nadal otrzymamy trzy odrębne.

Podsumowując, narzędzie osm2gis jest niewątpliwie krokiem w dobrym kierunku – zwiększenia dostępności i interoperacyjności danych OSM – lecz wykonanie pozostawia wiele do życzenia. Obecnie nadal lepiej jest korzystać z wybranego programu do konwersji, lub gotowych plików Shapefile od Geofabrik.

Bardziej skutecznym rozwiązaniem problemu może być funkcja konwersji danych OSM wbudowana w bibliotekę GDAL/OGR – jednak najnowsza wersja 1.10 w chwili pisania artykułu nie była jeszcze dostępna dla wszystkich systemów operacyjnych.

Tagi: , ,
Nie tylko Google Maps API

Google Maps API jest jednym z najpopularniejszych rozwiązań, umożliwiających wyposażenie aplikacji webowej w mapy. Jest bogate w funkcje i dane oraz cechuje się wysoką dostępnością i stabilnością działania. Nie oznacza to jednak, że jest w każdym wypadku rozwiązaniem optymalnym, a w niektórych wypadkach jego użycie będzie wręcz niemożliwe. W tym artykule postaram się przedstawić powody, dla których warto rozpatrzyć użycie alternatyw dla Google Maps API oraz pokrótce je scharakteryzować.

Dlaczego szukać alternatywy?

Google Maps API, pomimo swoich zalet, posiada pewne ograniczenia. Szczególnie dotkliwe są one w przypadku użycia usługi bezpłatnej. W takim wypadku wykluczone są m.in.:

  • aplikacje do nawigacji i/lub śledzenia pojazdów,
  • mapy drukowane oraz materiały reklamowe o nakładzie powyżej 5000 egz.,
  • aplikacje działające w sieci wewnętrznej (za firewallem),
  • aplikacje z płatnym dostępem.

Z kolei usługa płatna umożliwia takie działania, ale jest sprzedawana z indywidualną wyceną, zaczynającą się od 10 000 $ rocznie. Dla wielu aplikacji może to oznaczać spadek rentowności poniżej akceptowalnego poziomu. Dodatkowo, nie wszystkie ograniczenia są zniesione – nadal nie można np. przechowywać wyników geokodowania w osobnej bazie danych i wyświetlać na mapach innych niż Google.

Jak zastąpić?

Pakiet Google Maps API składa się z dwóch podstawowych komponetów:

  • biblioteka programistyczna JavaScript,
  • dane geograficzne i usługi na nich oparte, m.in. mapy podkładowe, geokodowanie, wyznaczanie trasy przejazdu.

W większości zastosowań alternatywnych komponenty te są niezależne od siebie i można je wybrać spośród różnych dostawców.

Biblioteka programistyczna

Ten element może być trudny do wymiany w przypadku rozbudowanej aplikacji, gdyż pociąga za sobą przepisanie kodu. Ponieważ jednak samo Google od czasu do czasu publikuje nową wersję API, wymagającą przynajmniej częściowego przepisania własnego kodu, należy być zawsze gotowym na taką ewentualność i bez zmiany biblioteki. Ponadto można tą okazję wykorzystać do modernizacji i naprawienia błędów, lub wręcz przekazania klientom zupełnie nowej wersji aplikacji.

Istnieje kilka bibliotek Open Source mogących wyświetlać mapy w środowisku przeglądarki internetowej, z czego dwie najbardziej godne polecenia to OpenLayers i Leaflet.

OpenLayers

Jest bardzo rozbudowanym, dojrzałym (pierwsze wydanie w 2006) projektem. Rozwój był zainicjowany przez firmę MetaCarta, obecnie jest niezależnym projektem wspieranym przez fundację OSGeo. Umożliwia współpracę z różnymi źródłami danych przestrzennych (m.in. usługi sieciowe TMS, WMTS, WMS, WFS oraz pliki KML, GeoJSON i GPX) oraz szeroki zakres interaktywności (rysowanie i pomiary, edycja danych, zaznaczanie obiektów, wyświetlanie informacji o obiekcie).

Wadą OpenLayers jest duży rozmiar (770 kB) oraz duża ilość starego kodu, związana z długą historią projektu. Obecnie trwają prace nad wersją 3, która ma zachować zakres funkcjonalności przy modernizacji i ograniczeniu rozmiaru kodu.

Leaflet

Najważniejszy konkurent dla OpenLayers. Wykorzystuje standardy HTML5 i CSS3 przy zachowaniu zgodności z Internet Explorer 8. Podstawowa biblioteka zajmuje 125 kB bez kompresji. Bardziej skomplikowane aplikacje – np. z możliwością rysowania, pomiarów, z wykorzystaniem plików KML – nie obędą się jednak bez użycia wtyczek, których powstało już wiele.

W odróżnieniu od OpenLayers wymaga od programisty znacznie mniejszej znajomości terminologii i teorii GIS (szczególnie zagadnień związanych z układami współrzędnych), oraz mniejszej ilości kodu dla osiągnięcia podstawowej funkcjonalności mapy. Przy bardziej złożonych aplikacjach może być jednak zbyt ograniczona.

Dane i usługi sieciowe

Biblioteki OpenLayers i Leaflet, w odróżnieniu od Google Maps API JavaScript, nie są w żaden sposób powiązane z dostawcami map. Możemy wybrać dowolnego dostawcę, który udostępnia swoje usługi w standardowej formie. Najczęściej jednak używa się ich z mapami i usługami powstałymi na bazie danych projektu OpenStreetMap, który jest “Wikipedią wśród map” (więcej informacji tutaj) i umożliwia nieodpłatne korzystanie z źródłowych danych geograficznych.

Mapa drogowa

Ten element jest najprostszy do zastąpienia. Spośród map bazujących na danych OSM, możemy wybrać oficjalną mapę projektu widoczną na stronie osm.org (OSM Standard, nazywaną też OSM Mapnik) – obie zaproponowane biblioteki posiadają gotowe funkcje do jej dodania. Oprócz tego można wykorzystać alternatywne wizualizacje (np. MapQuest, Hike&Bike) lub wreszcie – utworzyć własną, choć w tym wypadku niezbędny będzie serwer do jej utrzymania.

Zdjęcia satelitarne

W odróżnieniu od mapy drogowej, pozyskanie danych siłami społeczności jest przy obecnym stanie techniki mocno utrudnione. Z tego powodu brak projektu analogicznego do OSM, umożliwiającego dodanie do własnego projektu mapy satelitarnej praktycznie bez ograniczeń licencyjnych.

Komercyjna konkurencja dla Google Maps w zakresie map satelitarnych, obejmujących zasięgiem Polskę, jest dość skromna. Możliwe jest skorzystanie z Bing Maps API, które do 125 000 zapytań rocznie dla aplikacji publicznie dostępnych.  Aplikacje wymagające logowania, przeznaczone do użycia za firewallem wymagają odpowiedniej licencji biznesowej.

Drugą alternatywą jest MapBox Satellite. Ta usługa jest płatna w każdym przypadku, a wysokość opłaty zależy nie od rodzaju aplikacji, ale od wielkości ruchu i waha się od 5 do 500 $ miesięcznie.

W przypadku aplikacji działających na terenie jednego państwa, czasem możliwe jest skorzystanie – płatne lub bezpłatne – z map lotniczych oferowanych przez państwowe agencje, w formie usługi sieciowej WMS/WMTS. Niestety, polski geoportal.gov.pl na chwilę obecną nie udostępnia takiej usługi do wykorzystania we własnych aplikacjach.

Wyszukiwanie i geokodowanie

Do wyszukiwania miejscowości i nazw geograficznych można wykorzystać usługę GeoNames.  Wyszukiwanie ulic i adresów znajdujących się w zasobie OpenStreetMap możliwe jest dzięki usłudze Nominatim, choć działa ona w nieco staroświecki sposób – nie oferuje bowiem sugestii wyników na podstawie wpisanego fragmentu tekstu.

Dla polskich punktów adresowych, znajdujących się w gminach posługujących się Internetowym Menedżerem Punktów Adresowych (IMPA) można skorzystać z usługi lokalizacji adresów opisanej na stronie producenta aplikacji.

Wyznaczanie tras przejazdu (routing)

Istnieje kilka usług, umożliwiających wykreślenie najkrótszej/najszybszej trasy przejazdu pomiędzy zadanymi punktami, bazując na danych OSM. Jedną z nich, możliwą do integracji we własnych aplikacjach jest YOURS oparty o silnik Gosmore. Wyniki są zwracane w formacie GeoJSON lub KML, można również określić różne profile (najszybciej, najkrócej oraz środek transportu – samochód osobowy, ciężarowy, motorower, rower, pieszy). Drugą, charakteryzującą się większą wydajnością i aktualnością danych jest OSRM, wykorzystujący algorytmy nowej generacji. W tym przypadku mamy jednak do dyspozycji wyłącznie jeden profil trasy (samochód – naszybciej).

Podsumowanie

Za wyjątkiem zdjęć satelitarnych, uniezależnienie się od Google Maps API nie powinno nastręczać poważniejszych trudności. Odseparowanie od siebie kluczowych komponentów aplikacji mapowej, choć wymagające włożenia pewnego wysiłku, znacznie zwiększa jej elastyczność i ułatwia korzystanie z różnych źródeł danych. Przy odpowiednim przygotowaniu, możliwe jest nawet stworzenie systemu działającego bez stałego dostępu do sieci Internet.

 

Tagi: , ,
OSM dla programisty

W przeciwieństwie do większości komercyjnych i urzędowych rozwiązań mapowych, OpenStreetMap wyróżnia się pełnym (zarówno do pobrania, jak i edycji) dostępem do danych źródłowych. Fakt ten jest niesamowicie istotny dla twórców aplikacji i usług, oznacza bowiem znacznie szersze możliwości oraz większą paletę narzędzi. W tym artykule omówię podstawowe aspekty użycia OpenStreetMap we własnych aplikacjach.

Licencja

Od przeprowadzonej w 2012 r. zmiany licencji dane OSM są dostępne na zasadach licencji Open Database License. W przypadku wykorzystania niezmienionych danych, jedynym obowiązkiem nakładanym przez licencję jest właściwe oznaczenie źródła danych. Jeśli natomiast dane OSM mają być łączone z innymi, należy je albo odseparować (w przypadku aplikacji GIS, najprościej poprzez umieszczenie na osobnej warstwie), albo opublikować połączoną bazę danych (np. o zweryfikowanej topologii, lub wzbogaconej treści) na takich samych zasadach jak oryginał.

Wytworzone na podstawie niezmienionych danych OSM produkty (jak mapy cyfrowe i drukowane) i usługi (np. wyszukiwanie, wyznaczanie trasy) mogą być sprzedawane i licencjonowane na dowolnych zasadach, pod warunkiem właściwego oznaczenia źródła danych.

Możliwość edycji

Elementem wyróżniającym OSM na tle innych, podobnych projektów jest zapewnienie równych praw do edycji wszystkim użytkownikom. Brak tu wyznaczonych moderatorów, poziomów uprawnień, obowiązku zdobywania doświadczenia itp. Zasada ta czasem budzi kontrowersje i dyskusje nad jej zmianą, ale obecnie się na to nie zanosi. Jedynym wymogiem jest posiadanie konta, przy czym nie jest wymagane tworzenie nowego loginu i hasła – można wykorzystać OpenID.

Edycji danych można dokonywać za pośrednictwem jednego z edytorów ogólnego przeznaczenia (przeglądarkowe iD lub Potlatch, desktopowe JOSM lub Merkaartor, mobilny Vespucci), ale też wyspecjalizowanych aplikacji mobilnych umożliwiających szybkie zbieranie danych określonego typu (np. punktów POI, hydrantów, słupków kilometrowych, punktów adresowych) bezpośrednio w terenie.

Każdy może stworzyć własną aplikację umożliwiającą edycję danych OSM. Aktualna wersja API projektu nosi numer 0.6 i jest udokumentowana na tej stronie.

Własny wygląd mapy

Wolny dostęp do danych źródłowych i większości narzędzi do renderowania obrazów map daje możliwość stworzenia własnego, niepowtarzalnego stylu graficznego. Właściwie każdy program do renderowania map z surowych danych geograficznych może być użyty w tym celu. Do najłatwiejszych w obsłudze i najlepiej dostosowanych do danych OSM zalicza się TileMill oraz Maperitive.

Działanie w trybie offline i w sieciach wewnętrznych

OSM daje wiele możliwości wykorzystania bez połączenia z głównym serwerem projektu. Najprostszą jest pobranie zestawu obrazów mapy – tzw. kafelków – i przechowanie ich w pamięci urządzenia. Należy pamiętać, że o ile nie ma żadnych formalnych ograniczeń co do ilości czy czasu przechowywania danych, regulamin serwera osm.org zabrania masowego pobierania kafelków ze względów technicznych – powoduje to bowiem duże obciążenie serwera. Należy wtedy zwrócić się do wyspecjalizowanego dostawcy lub uruchomić swój własny serwer.

W urządzeniach mobilnych oprócz gotowych kafelków mapy, można zastosować również renderowanie wprost z danych wektorowych. Dla systemu Android istnieje np. biblioteka MapsForge.

Możliwość działania offline nie jest ograniczona wyłącznie do obrazów map. Na podstawie pobranej kopii danych można uruchomić także inne usługi, np. nawigację.

Tagi: , ,
Google Maps API 2 jednak do 19.11.2013

Niedawno napisaliśmy, iż jeszcze nie wiadomo jak będzie wyglądało wygaszenie Google Maps API 2. Przed weekendem majowym, na blogu Google Geo Developers pojawił się wpis rozwiewający wątpliwości.

W telegraficznym skrócie:

  • Działanie Google Maps API v.2 zostanie przedłużone o 6 miesięcy (do 19.11.2013).
  • Do tego czasu zostanie wdrożona “przejściówka” która pozwoli na zachowanie tylko najprostszych funkcji map, które wciąż są oparte o API v2, za pomocą API w wersji 3.
  • Warto skorzystać z poradnika nt. przepisywania kodu z wersji 2. na 3.
Tagi: ,
GIS modelowanie i monitoring w zarządzaniu systemami wodociągowymi i kanalizacyjnymi

GIS modelowanie i monitoring w zarządzaniu systemami wodociągowymi i kanalizacyjnymi

Dnia 12 kwietnia 2013 r. w Warszawie odbyła się naukowo-techniczna konferencja z cyklu GIS, modelowanie i monitoring w zarządzaniu systemami dystrybucji wody i kanalizacji. Z wygłoszonych podczas niej referatów została wydana publikacja GIS modelowanie i monitoring w zarządzaniu systemami wodociągowymi i kanalizacyjnymi, będąca ciekawym nawiązaniem do już dość dawno wydanej książki GIS w wodociągach i kanalizacji.

W książce sporo miejsca poświęcono doświadczeniom polskich firm wodociągowo-kanalizacyjnych z wdrażania Zintegrowanych Systemów Zarządzania Infrastrukturą Techniczną (ZSZIT), bez których trudno już sobie wyobrazić funkcjonowanie średnich i dużych przedsiębiorstw sieciowy. W zebranych artykułach widać wyraźną tendencję, iż systemy GIS stają się powoli głównymi systemami informatycznymi wykorzystywanymi w tych przedsiębiorstwach.

Ponadto można również przeczytać m.in. o takich zagadnieniach jak rejestracja prac eksploatacyjnych na sieciach, systemie wykrywania wycieków, wyznaczaniu modeli sieci czy też możliwościach wykorzystania oprogramowania typu Open Source do stworzenia systemu GIS przedsiębiorstwa wod-kan.


Szkolenia GIS i QGIS

Szkolenia podstawowe i dedykowane w formie zdalnej oraz stacjjonarnej

Zobacz ofertę szkoleń