Blog GIS Support


OGR2Layers

O tym, że ogry mają warstwy, dowiedzieliśmy się z kultowej pierwszej części „Shreka“. Ale do czego może nam się przydać ta wiedza w QGISie?
Otóż dostępna z QGIS Contributed Repository wtyczka, stworzona przez zespół: Nicholas Bozon, Rene-Luc D’Hont, Michael Douchin, Mathias Walker, Luca Delucchi o wdzięcznej nazwie OGR2Layers służy do szybkiego generowania tak zwanych mash-upów mapowych w oparciu o OpenLayers. Co to takiego mashup? W kartografii internetowej oznacza to połączenie mapy podkładowej (najczęściej Google Maps lub OpenStreetMap) z nałożonymi danymi użytkownika. Mogą być to lokalizacje restauracji w mieście, przebieg trasy turystycznej, przystanki autobusowe i tak dalej. Stworzenie takiej prostej mapy w OpenLayers wymagało napisania przynajmniej kilku linijek kodu w JavaScript i odpowiedniego przygotowania danych. Dzięki wtyczce można przynajmniej częściowo zautomatyzować ten proces.

Co będzie potrzebne? Do widoku QGIS musimy dodać jedną lub więcej warstw wektorowych ze zdefiniowanym układem współrzędnych. Prawidłowa definicja jest niezbędna do zadziałania wtyczki. Układ może być dowolny, format też.

Po drugie, należy ustawić wizualizację danych korzystając z starych stylów QGIS. Nowe nie działają i nie wiadomo, kiedy autorzy wtyczki uporają sie z ich implementacją. Należy też pamiętać o tym, że możliwości samego OpenLayers są ograniczone, więc bardzo skomplikowana symbolizacja i tak byłaby nie do przeniesienia. Możemy korzystać z ustawienia „symbol pojedynczy“ lub „wartość unikalna“.

Uwaga 1. Przy ustawianiu symboli punktów z plików SVG należy koniecznie ustawić „Opcje wypełnienia“ na „Brak“ – w przeciwnym wypadku zamiast grafik pojawią się kolorowe punkty. Symbole SVG nie działają również w przypadku wyboru „wartości unikalnej”.

Uwaga 2. OGR2Layers nie przeliczy jednostek wielkości symboli z milimetrów na piksele, tylko bezpośrednio przeniesie wartości. Należy więc założyć wszystko odpowiednio większe.

Kiedy już wszystko będzie gotowe, wywołujemy wtyczkę z menu Wtyczki – OGR2Layers Plugin. Okno ma 4 zakładki: QGIS, OpenLayers, Optional i Output.

W zakładce QGIS pokaże się lista warstw wektorowych dodanych do mapy. Oprócz tego trzeba zdecydować, gdzie będą zapisane pliki wynikowe (Output directory), oraz do jakiego formatu powinny być konwertowane wektory: GML albo GeoJSON. Zakładka OpenLayers posiada pole na wpisane tytułu mapy, rozmiaru (do wyboru jest 400×400 px, 800×600 px i pełny ekran), domyślny zakres (ustawiany jest do zasięgu aktualnego widoku QGIS), oraz umożliwia włączenie/wyłączenie przełącznika warstw. Jest tu również wybór podkładu – niestety, tylko z listy. W wersji 0.8.2 dostępnej przez instalator wtyczek można wybrać trzy różne wizualizacje OSM lub Vmap level 0, wersja rozwojowa umieszczona na GitHub umożliwia również wybranie Google Maps.

W zakładce „Optional“ można dodać do mapy kolejne elementy, jak wyświetlanie współrzędnych, skalę, opis źródła danych, pasek stopnia powiększenia, mini-mapę przeglądową i link do widoku. Sekcja „Render option“ dotyczy symbolizacji – „default OpenLayers render“ pominie ustawienia QGISa, natomiast „QGIS render“ – przeniesie symbolizację z projektu do wygenerowanej mapy. W sekcji „Query option“ wybieramy, czy kliknięcie na obiekcie ma spowodować wyświetlenie w „dymku“ jego atrybutów. Opcja „Query more features“ działa tylko wtedy, gdy dodane będą wyłącznie warstwy punktowe. Umożliwia odczyt atrybutów kilku punktów położonych bardzo blisko siebie.

Po zdefiniowaniu wszystkich parametrów wystarczy kliknąć na OK i czekać na efekty. Wygenerowany kod będzie zapewne wymagał modyfikacji (choćby zmiana nazw warstw, użycie biblioteki OpenLayers ze swojego serwera zamiast głównego serwera projektu), ale w porównaniu do pisania od zera i tak mamy zaoszczędzone sporo pracy.

Trzeba jednak pamiętać, że taki sposób tworzenia internetowych map ma swoje ograniczenia. Przede wszystkim nie mamy swobody w wyborze układu współrzędnych, wtyczka automatycznie transformuje nasze dane do Web Mercator (którego nie znoszę). Również lista dostępnych podkładów jest ograniczona. Wreszcie – tego typu mapy działają dobrze, gdy nie muszą pokazywać zbyt wielu danych. Dla Internet Explorera bezpiecznym limitem jest 100 obiektów na wszystkich warstwach, dla pozostałych przeglądarek kilkaset, ale szybkość działania może być niezadowalająca. Dane przechowywane są w formatach tekstowych, więc nadzwyczaj mało ekonomicznych. Powyżej pewnego progu nie będzie już wyjścia: trzeba zainwestować w Server GIS z prawdziwego zdarzenia.

To jednak temat na osobną opowieść, a tymczasem – miłej zabawy z OGR2Layers!

Dlaczego warto zaprzyjaźnić się ze słoniem?

Kto w pionierskich czasach powszechnego dostępu do Internetu w Polsce próbował tworzyć własną stronę internetową (na przykład w kultowym edytorze Pajączek), pamięta zapewne, że każdą z podstron zapisywało się w oddzielnym pliku .html. Na prostej stronie nie stanowiło to specjalnego problemu, ale jak trzeba było dokonać aktualizacji większego serwisu i żadnego takiego pliku nie pominąć – było już gorzej. Ciężko również wyobrazić sobie, jak w takim systemie mogłyby funkcjonować rzeczy tak dziś oczywiste: system komentarzy czy forum.

Współcześnie sprawa ma się zupełnie inaczej: kod html jest generowany dynamicznie, według szablonu, z jednego źródła, któremu na imię baza danych.

Po co ten wstęp? Ponieważ dzisiejszy wpis ma dotyczyć właśnie korzyści z zapisu geodanych w bazie danych właśnie. Rozwiązanie to jest znane już dość długo, ale zaporowe ceny licencji czyniły je osiągalnym jedynie dla bardzo dużych (i bogatych) organizacji. Na szczęście za rogiem jest OSGeo z swoją bazą, zupełnie darmową i o dużych możliwościach: PostGIS. Jest to rozszerzenie dodające obsługę danych i zapytań przestrzennych do opensource’owego systemu zarządzania relacyjnymi bazami danych o nazwie PostgreSQL.

A w czym PostGIS może nam pomóc?

Po pierwsze, daje dostęp do potężnego języka zapytań SQL, rozszerzonego o zapytania przestrzenne. Poznanie odpowiedzi na pytania typu:

  • Jak nazywa się gmina o najmniejszej gęstości sieci dróg?
  • Ile jest kilometrów linii kolejowych o prędkości szlakowej do 40 km/h w województwie śląskim?
  • Ile hoteli 4-gwiazdkowych znajduje się nie dalej niż 5 km od lotniska i 6 km od rynku?
  • Jakie działki rolne klas V i VI lub nieużytki są oddalone co najmniej 500 m od zabudowy i 200 m od terenów leśnych?

będzie trywialne, pod warunkiem, że nauczymy się je tłumaczyć na Spatial SQL 😉

Bez zastosowania bazy danych, do udzielenia odpowiedzi trzeba by było stworzyć co najmniej jeden przejściowy shapefile. Który po rozwiązaniu zadania nie będzie przedstawiał żadnej wartości i którego trzeba będzie skasować, a są to 4 osobne pliki. Jeśli zapytanie będzie bardziej złożone, plików przybędzie. Tymczasem w PostGIS to zbędne – wszelkie buffer, intersect, union i inne tego typu możemy generować w locie za naciśnięciem klawisza. A jeśli zajdzie potrzeba ich zapisania – nic prostszego, wystarczy dodać instrukcję tworzenia nowej tabeli.

Po drugie – współpraca w zespole. Choćby banalna wektoryzacja. Każda z osób pracuje nad jedną i tą samą warstwą, widzi postępy innych na bieżąco, wszystko może dokonywać się przez sieć lokalną lub Internet. Zero przesyłania i sklejania szejpów. Oraz zmyślania, że miało się już bardzo dużo, ale pendrajwa pies zjadł 🙂

Po trzecie – publikacja w sieci. Wszelkie narzędzia do serwowania danych przestrzennych (MapServer, GeoServer, Mapnik i takie tam) najbardziej lubią się właśnie z PostGIS-em. Możliwe jest zdefiniowanie tylko wybranych danych jako warstwy – np. z tabeli zawierającej wszystkie POI stworzymy osobne warstwy hoteli, stacji benzynowych i bankomatów właśnie z pomocą zapytań SQL. Indeksy przestrzenne znacznie przyspieszą pracę. Wreszcie można uruchomić usługę WFS-T i umożliwić użytkownikom  edycję danych z poziomu przeglądarki, bez instalacji nawet najprostszego programu GIS.

A czego PostGIS nie da?

Trzeba tutaj zaznaczyć, że baza PostGIS różni się bardzo od geobazy znanej z ArcEditor/ArcInfo. W aktualnej wersji stabilnej (1.5) baza PostGIS służy do przechowywania wyłącznie danych wektorowych, bez topologii – identycznie jak shapefiles. Może być za to edytowana przez wielu użytkowników na raz przez sieć. Tymczasem z geobazą jest dokładnie odwrotnie: służy do integracji danych różnego typu i przechowywania topologii, może być jednak edytowana tylko przez jednego użytkownika jednocześnie. Te wady PostGIS zostaną w dużej części wyeliminowane po ostatecznym wydaniu wersji 2.0 – tam topologia i rastry są obsługiwane.

Poza tym,  PostGIS zapewnia możliwość pracy z danymi z poziomu bardzo różnych programów – ale tylko OpenSource. Bo gdyby ArcGIS miał możliwość korzystania z geobazy wielodostępnej za darmo, to kto by płacił (bardzo)ciężkie pieniądze za ArcGIS Server? W firmach, gdzie jest jedno stanowisko wyposażone w program ESRI i kilka innych z np. Quantum GIS – instalacja PostGIS się nie sprawdzi.

Więcej na temat PostGIS można poczytać na oficjalnej stronie projektu:

http://www.postgis.org/

Sporo materiałów znajduje się też na stronie Boston GIS: http://bostongis.com/?content_name=postgis_tut01#20

Wprowadzenie do GRASS GIS

GRASS. Czyli Ten, Od Którego Się Wszystko Zaczęło w świecie wolnego oprogramowania GIS. Jedni uciekają przed nim gdzie pieprz rośnie, uznając za niezwykle trudnego do opanowania. Inni – nie wyobrażają sobie pracy bez niego. Jaki GRASS jest naprawdę?

Program powstał w 1982, czyli przyszłym roku skończy 30 lat istnienia! Dla porównania, pierwsza wersja Windows – jeszcze nie jako samodzielny system, ale nakładka na DOS – została opublikowana trzy lata później. Skąd w ogóle wziął się ten pakiet?

Otóż GRASS, tak jak system GPS czy koncepcja sieci Internet, wywodzi się z amerykańskiej armii. Rozwijany przez Construction Engineering Research Laboratory służył głównie celom planowania przestrzennego (za Wikipedią). W 1995 roku armia przestała się nim interesować i system „poszedł do cywila”, a konkretnie – zainteresowali się nim naukowcy z Baylor University. Wkrótce stał się programem typu open source, udostępnianym na licencji GNU GPL, a dzięki jego modułowej budowie liczba funkcji zaczęła szybko rosnąć, uwzględniając najnowsze odkrycia w dziedzinie GIS. Pomimo sędziwego, jak na program komputerowy wieku jest wciąż rozwijany, a jego najnowsza wersja stabilna nosi numer 6.4 i została opublikowana we wrześniu 2010.

Do czego dziś może przydać się GRASS? Nie ma co ukrywać: trzon programu niewiele się zmienił od początków jego istnienia, a archaiczny model danych (o którym za chwilę) znacznie utrudnia używanie systemu. Jednak spośród dostępnych darmowych programów GIS jedynie GRASS jest prawdziwym kombajnem, umożliwiającym wykonywanie zaawansowanych analiz i modeli przestrzennych. Analizy sieciowe, struktury krajobrazu, tworzenie powierzchni kosztów, modelowanie hydrodynamiczne – to wszystko dla GRASSa jest przysłowiowy „pikuś”. Wiele modułów zostało stworzonych przez naukowców i jest niezwykle przydatnych w pracy naukowej właśnie.

Gdzie więc tkwi haczyk? W modelu danych, który powinien dostać etykietkę „Zabytek techniki”. Jest on podobny do – wywodzącego się zresztą z tych samych czasów – starego ARC/INFO Workstation (nie mylić z współczesnym ArcInfo!) z wektorami „Coverage” i rastrami „GRID”. Do zapisania choćby jednej warstwy potrzebna jest GRASSowi cała struktura katalogów, która przedstawia się następująco:

GISDBASE – nadrzędny katalog, w którym trzymane są wszystkie dane GRASS. Może być specjalnie wydzielony lub nie,na przykład w systemie Linux może to być /home/nazwa_użytkownika.

Lokacja (LOCATION) – jest to katalog zawierający dane o takim samym zasięgu, układzie współrzędnych i – w przypadku rastrów – rozdzielczości. Wszelkie dane, które mają się znaleźć w lokacji, muszą być transformowane do jednego układu! Nie ma tutaj możliwości transformacji „w locie”, tak jak w przypadku współczesnych programów GIS. Rozdzielczość rastra musi być ustawiona według tej warstwy, która ma piksel najmniejszy. Powoduje to, że chcąc używać jednocześnie ortofotomapy lotniczej (piksel 25 cm) oraz modelu wysokości SRTM (piksel 90 m) – musimy zapisać ten drugi zupełnie bezproduktywnie z 25-centymetrową rozdzielczością…

MAPSET – jest podzbiorem lokacji, opisywany jako „kolekcja map dla jednego terytorium lub projektu”. Innymi słowy jest to jakiś wyodrębniony zestaw warstw, znajdujących się w jednej lokacji (a więc o tym samym zasięgu, układzie i rozdzielczości). Możemy też osobnych MAPSETów nie używać i trzymać wszystkie dane w jednym, domyślnie tworzonym „PERMANENT”.

Paskudne, nieprawdaż? Na pocieszenie dodam, że zupełnie jak w przypadku ARC/INFO Coverage – wektory zapisywane są w modelu topologicznym, co jest zupełnie niemożliwe w przypadku plików Shapefile. Czyli każda granica np. działki jest zapisywana tylko raz, nie ma problemu z nieprzylegającymi czy nakładającymi się poligonami i tak dalej. Sam import, a następnie eksport z GRASSa pozwala pozbyć się problemów z topologią w naszych danych.

O tym, jak używać GRASSa w praktyce i do czego może się on przydać – w następnych wpisach!

Do poczytania:

http://grass.fbk.eu/ – oficjalna strona projektu

http://www.wgug.org/ – Wrocławska Grupa Użytkowników GRASS

Różne oblicza GRASS GIS

Jeśli zdecydujemy się wykorzystać GRASS w praktyce, możemy to zrobić na kilka sposobów. Pakiet ten – w odróżnieniu od większości dostępnego oprogramowania GIS – posiada bowiem kilka interfejsów. Każdy z nich ma swoją specyfikę, swoje wady i zalety.

Jeśli wpiszemy w oknie terminala komendę „grass”, zostaniemy najpierw poproszeni o wybór lokacji i mapsetu (o nich mowa była w poprzednim wpisie). W tym miejscu można też utworzyć nową lokację, jeśli jeszcze nie mamy żadnej – definiując jedynie układ współrzędnych. Na określenie zasięgu i rozdzielczości rastra będzie jeszcze czas. Następnie ujrzymy trzy okienka…

Najbardziej rzucającym się w oczy jest „Menadżer warstw GRASS GIS”. To swoiste centrum dowodzenia – tutaj dodajemy warstwy do wyświetlenia i wybieramy funkcje analiz przestrzennych. Drugie okienko – to „GRASS GIS Map Display” (nie ma to jak niekompletne tłumaczenie…), które służy do wizualizacji, pomiarów odległości/powierzchni, generowania profili itd. Można tu dostrzec pewne podobieństwo do znanego i lubianego (albo przeklinanego) GIMP’a, który również lubuje się w mnożeniu okien… A całość prezentuje się tak:

grassgis

Omawiany interfejs nosi nazwę wxPython GUI. Zastępuje on poprzednią wersję, eliminując kilka poważnych minusów (na przykład zlikwidowano przycisk „odśwież” w oknie wizualizacji, który trzeba było kliknąć po każdej zmianie w Menadżerze – okropność!), ale nie jest jeszcze w 100% gotowy. Stąd też różne komunikaty o błędach, pojawiające się… no właśnie – gdzie?

W konsoli.

Tak – konsola GRASS, ta żywa skamielina, wciąż jest dostępna. Powróćmy na chwilę do okna terminala…

Konsola GRASS

I ukaże się naszym oczom oryginalny interfejs GRASSa, towarzyszący mu od samego początku. Czarne tło, białe litery i tak dalej. W konsoli tej możemy wpisywać komendy odpowiadające poszczególnym funkcjom analizy. Po co w ogóle zaprzątać sobie tym głowę?

  • bo czasami można szybciej wpisać komendę, niż grzebać w menu lub
  • napisać skrypt, który zautomatyzuje nasze działania.

No bo kto by chciał np. powtarzać tą samą operację dla wielu warstw? Kilka arkuszy mapy można jeszcze od biedy przerobić w ten sposób. A jakby tak trafiła nam się długa seria czasowa danych z satelity o krótkim czasie rewizyty? Siąść i płakać, albo właśnie napisać skrypt. Do tego celu potrzebna jest właśnie znajomość składni komend GRASS.

wxPython i konsola to jednak nie wszystko. Można jeszcze podpiąć GRASS do Quantum GIS. Wówczas praca z pakietem staje się znacznie łatwiejsza, bo po zaimportowaniu danych do lokacji można korzystać z niego zupełnie jak z ArcToolbox – wystarczy kliknąć ikonę „Narzędzia GRASS”, a pojawi się coś do złudzenia przypominającego właśnie Toolboxa. W porównaniu do ArcGIS 10 nawet lepsze, bo z możliwością wyszukiwania funkcji 🙂 Obecnie każda wersja QGIS posiada wbudowaną obsługę GRASS. Niestety, jest i poważna wada takiego rozwiązania: brak niektórych funkcji i parametrów. Wówczas pozostaje otworzyć konsolę (Narzędzia GRASS -> shell) i wpisać pożądaną komendę, lub użyć wxPython.

I tak oto pokrótce prezentują się możliwości skorzystania z dobrodziejstw GRASS GIS. Najłatwiejszy wydaje się sposób ostatni, jednak trzeba pamiętać o jego ograniczeniach. Tak czy siak, składnię warto znać – albo przynajmniej mieć dokumentację pod ręką. Przyda się  w najmniej oczekiwanym momencie!

Kalibracja map Messtischblatt w QGIS

Stare mapy może i nie zastąpią wehikułu czasu, ale i tak ich przydatność jest ogromna. Poszukiwanie śladów dawnych fabryk, kolei, fortyfikacji, grodzisk ukrytych w lesie czy też zmian w użytkowaniu i pokryciu terenu 😉 – wszystko to wymaga posiadania archiwalnej mapy. Na szczęście w dobie internetu nie trzeba już szukać ich w bibliotekach i ryzykować zniszczenia zabytku – na ogół wszystko, co trzeba, znajduje się już w sieci. Jest jednak pewne „ale”…

Zwykle wraz z mapą na różnych serwerach dostępne są pliki kalibracyjne z rozszerzeniem .map. Jakość tej kalibracji jest lepsza lub gorsza, zawsze jednak będzie działać jedynie z OziExplorerem. Użycie takiego pliku w standardowym programie GIS skończy się porażką, bo jak większość neogeograficznych wynalazków jest zgodny jedynie sam ze sobą. Pozostaje więc zabrać się za kalibracje samemu.

Tym razem zajmę się niemieckimi mapami Messtischblatt w skali 1:25 000, pokrywającymi tereny włączone do Polski po II wojnie światowej. Pozyskać je można np. ze strony Archiwum Map Zachodniej Polski. Ich kalibracja jest o tyle łatwiejsza od obejmujących tereny II RP map WIG, że parametry odwzorowania, są na 100% pewne – mało tego, znajdują się w bazie EPSG!

W Messtischblattach zastosowano odwzorowanie zwane w krajach anglosaskich Transverse Mercator, a u nas – Gaussa-Krügera. Za model Ziemi posłużyła elipsoida Bessela. Terytorium III Rzeszy podzielono na 6 stref odwzorowawczych o szerokości 3 stopni, przy czym dla obszaru dzisiejszej Polski są to strefy 5 i 6. Granica pomiędzy nimi przebiega wzdłuż południka 16,44 E (w układzie WGS84). Dla strefy 5 mamy gotową definicję, którą można przywołać kodem EPSG: 31469. Tereny położone dalej na wschód wymagają wpisania własnej definicji strefy 6:

+proj=tmerc +lat_0=0 +lon_0=18 +k=1 +x_0=6500000 +y_0=0 +ellps=bessel +datum=potsdam +units=m +no_defs

Czasami zdarza się arkusz leżący w dwóch strefach. Poznamy to po załamaniu siatki oraz napisie „Ostgrenze des Gitterstreifes 15 | Westgrenze des Gitterstreifens 18” nad ramką. Wówczas oczywiście należy używać wyłącznie punktów kalibracyjnych w obrębie jednej strefy.

I tym sposobem możemy zabierać się za kalibrację, korzystając z oryginalnej siatki topograficznej. W QGIS służy do tego narzędzie Georeferencer, umieszczone w menu Raster (może być konieczne wcześniejsze włączenie w Zarządzaj wtyczkami). Pracę zaczynamy od wczytania surowego skanu – służy do tego ikona Wczytaj skan. Następnie należy powiększyć obraz tak, by zobaczyć ramkę i móc odczytać współrzędne. Nowe punkty wpasowania dodajemy ikoną Dodaj punkt , pojawi się okno z możliwością wpisania współrzędnych lub pobrania ich z istniejącej mapy:

Wprowadzanie punktów GCP

I tak do skutku, to znaczy – do wpisania odpowiedniej liczby punktów wpasowania. Pamiętać należy przy tym, że współrzędne siatki podane są w kilometrach – należy więc dopisać do nich na końcu 000. Jeśli mapa jest w dobrym stanie i prawidłowo zeskanowana, to właściwie wystarczą 4 punkty, dobrze jednak jest mieć ich więcej. Na koniec należy ustawić parametry transformacji:

Ustawienia transformacji

W większości przypadków wystarczy wielomian 1 stopnia, dla zniszczonych map trzeba użyć stopnia wyższego. Ustawiamy układ współrzędnych (strefa 5 – z kodu EPSG, strefa 6 – wklejając definicję), plik wyjściowy…

Teraz można by już uruchomić kalibrację, ale na wszelki wypadek zapiszmy punkty wpasowania – żeby nie zaczynać od początku w razie padnięcia QGISa.

Na zakończenie warto otrzymany raster transformować do jakiegoś współczesnego układu (opcja Raster – Zmień odwzorowanie) oraz odchudzić paletę kolorów (Raster – RGB na PCT) – wszak oryginał drukowano w 3 kolorach i absolutnie nie ma sensu marnować miejsca na zapis 24-bitowy.

„OpenLayers 2.10 Beginners Guide” Erik Hazzard

OpenLayers 2.10 Beginners Guide – dla wszystkich, którzy chcą zacząć przygodę z WebGIS. Więcej o OpenLayers.

„PostGIS in Action” Regina O. Obe, Leo S. Hsu

PostGIS in action” Jedyna książka od PostGIS, która rodziła się w bólach od jakiegoś czasu, w końcu ujrzała światło dzienne. Napisana bardzo przystępnym językiem. Recenzja (po angielsku) znajduje się tutaj.

WMS, Web Map Service. Co to jest? Jak tego używać?

Do napisania tego artykułu zobowiązałem się podczas przemiłej rozmowy w leśniczówce pod Białowieżą. Rozmawialiśmy o geoportal.gov.pl i najnowszej aktualizacji zdjęć lotniczych (KOMUNIKAT NR 31 Z DNIA 25.05.2011). Na końcu komunikatu zawarte zostało zdanie, iż:

Do momentu wygenerowania „kafelków” ortofotomapy będą dostępne poprzez usługę WMS.

„Świetnie, ale co to znaczy? Szukałem informacji o tym WMS, ale z tego co znalazłem – mało zrozumiałem…” – powiedział rozmówca. I faktycznie – nawet definicja z Wikipedii niewiele powie komuś, kto z geoinformacją miał mało wspólnego. Dominująca wyszukiwarka też niczego przystępnego nie pozycjonuje w czołówce wyników…

Co to jest WMS?

Jest to usługa przeglądania danych przestrzennych przez sieć Internet.

a teraz po ludzku…:)

Zbiory danych przestrzennych np. ortofotomapy, mają tę wadę, że zajmują mnóstwo pamięci (ważą tysiące gigabajtów). Przechowywane są na „centralnych serwerach”. Żeby wyświetlić ortofotomapę na swoim monitorze, trzeba ją fizycznie przesłać z serwera do komputera. Gdyby przesyłać je w oryginalnej formie, zajęłoby to wieki, przeciążyło serwery, łącza i nie miałoby większego sensu.

I w tym momencie używamy WMS. (Poniższy rysunek czytamy od prawej do lewej i z powrotem)

Surfując po geoportal.gov.pl (czyli kliencie), przy każdej zmianie widoku mapy (przybliżenie, oddalenie, przesunięcie), geoportal automatycznie wysyła żądanie do serwera WMS przez protokół HTTP: „Chcę zobaczyć konkretny wycinek ortofotomapy, w konkretnej skali” (Np. skala 1: 50 000, obszar ograniczony przez ramkę widoku mapy) Serwer WMS przetwarza zapytanie, z surowych danych tworzy „kafelki” (małe pliki PNG lub JPG – przeważnie 256 x 256 pikseli, z których każdy waży ok. 100 kB) i wysyła je do geoportalu, który wyświetla je na ekranie monitora. Zamiast przesłać setki megabajtów prawdziwej ortofotomapy, dostajemy zestaw małych plików, z których geoportal składa obraz. Proces powtarza się za każdym razem kiedy zmienimy parametry wyświetlania (przybliżenie, oddalenie, przesunięcie lub zmiana warstwy np. na mapy topo).

(Trochę skłamałem, żeby uprościć i wyjaśnić zasadę działania na geoportal.gov.pl. Korzysta on z trochę innego rozwiązania. Na serwerze czekają stworzone wcześniej kafelki, omija się proces ich generowania „na zamówienie” co nieco skraca czas oczekiwania i zmniejsza obciążenie serwerów)

O WMS nie byłoby tak głośno, gdyby ich użycie ograniczało się tylko do geoportal.gov.pl. W poprzednim akapicie użyłem stwierdzenia „klient”. Klientem może być inna strona internetowa lub, co ważniejsze, program komputerowy np. QGIS. Dane udostępniane przez WMS możemy wczytać do swojego oprogramowania GIS (np. jako podkład mapowy) lub dodać  jako warstwę aplikacji mapowej.

Dzięki temu, że zapytania i odpowiedzi są wysyłane poprzez protokół HTTP, czyli ten sam dzięki któremu wyświetlane są strony WWW, każda usługa WMS ma swój prosty adres WWW. Ortofortomapa z geoportalu ma adres:

http://sdi.geoportal.gov.pl/WMS_ORTO/WMService.aspx?version=1.1.1

Wpisanie tego adresu w wyszukiwarkę zwróci nam plik XML, z którym niewiele możemy z nim zrobić. Magia zaczyna się w momencie użycia oprogramowania GIS.

Otwieramy QGIS. W panelu dodawania danych jest przycisk , klikamy „Nowa”, wpisujemy dowolna nazwę, wyżej podany adres WWW  i klikamy OK.

Następnie z paska dodanych usług wybieramy „geoportal ortofotomapa” lub jeśli nazwaliśmy inaczej to inaczej, klikamy „połącz”. QGIS może coś krzyczeć, ale ignorujemy to, wybieramy warstwę, dostosowujemy układ współrzędnych (musimy wybrać spośród tych, które ustanowił dostawca usługi) i klikamy dodaj.

I już. Warstwa z ortofotomapą dodana. Teraz na przykład mogę obejrzeć trasę wycieczki rowerowej na podkładzie ortfotomapy… (Wyświetlanie jest uzależnione od skali. Jeżeli jest zbyt mała to zobaczycie tylko logo geoportalu. Ortofotomapa wyświetla się w skali od 1:10 do ok 1:130000)

…lub po dodaniu adresu http://sdi.geoportal.gov.pl/wms_topo/wmservice.aspx?version=1.1.1 na podstawie mapy topograficznej.

No dobrze. Już wiemy jak to działa. Takich serwisów, pozwalających wyświetlić w prosty i przystępny sposób dane z wielu różnych źródeł, jest na świecie kilka tysięcy, w Polsce kilkadziesiąt. Uaktualniana lista serwisów WMS jest tu.

Na koniec krótkie podsumowanie:

Zalety:

1) Takie usługi istnieją – jest ich coraz więcej.

2) Pozwalają wygodnie popatrzyć na dane, wyświetlić je w ulubionym oprogramowaniu, sprawdzić poprawność swoich danych i wiele innych.

Wady:

1) Pozwalają tylko popatrzyć…

2) Nie zawsze działają poprawnie – szczególnie usługi WMS geoportal.gov.pl są wyjątkowo kapryśne,

3) Mimo wszystko działają wolno…

Generalnie „gisowcy” psioczą na WMS, ponieważ pozwala im on „polizać dane przez szybę”. Nie nadają się do żadnych dalszych analiz. Dodatkowym ograniczeniem są często niejasne licencje na dane udostępniane przez WMS. Zwektoryzowanie miejscowego planu zagospodarowania przestrzennego udostępnionego przez WMS przez gminę może być nielegalne (zwektoryzowanie budynków z TBD z geoportalu na pewno jest nielegalne). Trzeba mapę mimo wszystko kupić…

Jest to wygodne rozwiązanie, kiedy chcemy „udostępnić dane, ale nie do końca”. Jest to szczególnie praktykowane przez urzędników, którzy często sami nie wiedzą co i jak mogą upublicznić. Na koniec dodam, że z tej samej rodziny są jeszcze: WFS, WCS, WPS, ale o nich kiedy indziej…

Value Tool

W większości aplikacji GIS mamy dostępne narzędzie do sprawdzania wartości pikseli rastra. QGIS nie jest wyjątkiem i został w taką funkcję wyposażony – nazywa się Informacje o obiekcie. Niestety posiada ono dwie wady: by odczytać wartość innego piksela, należy każdorazowo kliknąć, ponadto pokazywane są informacje jedynie o warstwie aktywnej.

Problemy te rozwiązuje instalacja wtyczki autorstwa Ghislaina Picarda z repozytorium QGIS Contributed o nazwie Value Tool.

Po uaktywnieniu wtyczki (menu Widok – Panele – Value Tool), pod drzewem warstw pojawi się panel informacyjny. Jeśli tylko zaznaczona jest opcja Active – w panelu zobaczymy wartość piksela, na którym aktualnie znajduje się kursor myszki.

sprawdzanie wartości jednego rastra

Możliwe jest również śledzenie wartości w rastrach wielokanałowych:

sprawdzanie wartości obrazu wielokanałowego

Czasem od poznania konkretnych wartości ważniejsze są relacje między kanałami – wówczas warto kliknąć opcję Graph. Jej użycie wymaga instalacji modułu Pythona o nazwie Qwt5 (potrzebny jest on zresztą do wielu innych wtyczek, zatem warto go mieć).

wykres wartości wielu kanałów w ValueTool

Wreszcie – wtyczka posiada możliwość odczytu wartości pikseli ze wszystkich wczytanych rastrów, nie tylko warstwy aktywnej:

sprawdzanie wartości wielu rastrów

Image Boundary

Przy pracy z dużą liczbą przylegających do siebie warstw rastrowych – np. arkuszy map topograficznych, albo kafli modelu terenu – bardzo pomocne jest posiadanie skorowidza. Dzięki niemu odnalezienie właściwego numeru arkusza będzie bezproblemowe. W QGIS możemy się w tym celu posłużyć wtyczką Image Boundary.

Wtyczkę instalujemy z repozytorium QGIS Contributed Repository, autorem jest Luiz Motta. Po instalacji pojawia się w menu Wtyczki. Aby z niej skorzystać, nie trzeba dodawać rastrów do widoku mapy – ale powinny być umieszczone w jednym katalogu. Ścieżkę dostępu do niego wybieramy, klikając naIkona wyboru folderu . Można również zdefiniować konkretny format spośród obsługiwanych przez GDAL.

Po wybraniu katalogu pojawi się lista znalezionych rastrów. Jeśli wszystko się zgadza, kolejnym krokiem powinno być kliknięcie na  . Trzeba się jeszcze zdecydować, czy chcemy aby granice były tworzone według zasięgu macierzy rastrowej (Extent) czy też pikseli zawierających dane (Valid pixels). Potem można już kliknąć na  i wybrać nazwę pliku oraz jego format (do wyboru jest Shapefile albo KML). Wygenerowany skorowidz może zostać od razu dodany do widoku.

W tabeli atrybutowej skorowidza znajdą się następujące dane:

– Image – nazwa pliku,

– Path – ścieżka dostępu,

– Driver – format pliku,

– XYSize – rozmiar rastra,

– Proj4 – definicja układu współrzędnych w formacie PROJ.4,

– NumBands – liczba kanałów,

– BandTypes – liczba bitów na kanał,

– ResSpatial – rozdzielczość przestrzenna.

Odróżnia to wtyczkę Image Boundary od podobnego narzędzia gdaltindex (dostępny w menu Raster – Indeks kafli), który również potrafi wygenerować skorowidz – ale zapisuje w atrybutach jedynie ścieżkę dostępu, bez metadanych.