Webgis


QGIS – praca w wiele osób nad jednym projektem.

Na pewno większość z Was zmierzyła się z problemem edytowania jednej warstwy (Shapefile) w kilka osób… Na pewno dzieliliście się terytorialnie, wykonywaliście swoją prace, przesyłaliście pliki e-mailem, łączyliście i… problemy dopiero się zaczynały. Kolejna edycja oznaczała nowy plik, który trzeba przesłać i dołączyć do pliku głównego (ale jak to zrobić, skoro część danych jest nowa, a część stara) itd, itp… Kończy się to przeważnie tym, że po chwili jest kilkanaście wersji tych samych plików, nikt nie wie, który jest aktualny, najnowszy i pewny, wszyscy są zdenerwowani, a bałagan jest coraz większy…

Czytaj całość

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.

 

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ę.

Zmniejszanie rozmiaru OpenLayers

Biblioteka OpenLayers bywa często krytykowana za duży rozmiar. Istotnie, prawie 1 MB kodu JavaScript robi wrażenie – dla porównania Leaflet-js „waży“ 92 kB, a Polymaps  zaledwie 32 kB. Nie wolno jednak zapominać o tym, że różnice te nie biorą się z niczego. Liczba dostępnych funkcji oraz akceptowanych formatów danych jest dużo dłuższa właśnie w OpenLayers i często są one niezbędne do zbudowania aplikacji spełniającej wszystkie oczekiwania.

Nie znaczy to jednak, że jesteśmy skazani na ładowanie tak obszernej biblioteki za każdym razem. Poniżej opiszę kilka sposobów, które pozwalają na ograniczenie ilości pobieranych danych przy zachowaniu pełnej wymaganej funkcjonalności.

Użycie nowej wersji

Czytaj całość

Instalacja i konfiguracja QGIS Server

Wprowadzenie

Najczęściej, rozważając wybór serwera WMS dostępnego na wolnej licencji, ma się na myśli jeden z dwóch projektów: UMN MapServer albo GeoServer. Obydwa mają już za sobą długą historię, liczną społeczność oraz wielu użytkowników. Mają jednak również swoje wady, w tym jedną największą: wszelkich ustawień wizualizacji danych dokonuje się tekstowo. Szczególnie dokuczliwy w tym zakresie jest GeoServer, wykorzystujący język SLD z jego nadmiernie rozbudowaną składnią. W przypadku chęci stworzenia bardziej rozbudowanej symbolizacji, staje się to poważnym problemem.

Na szczęście pojawiła się interesująca alternatywa dla tych programów – QGIS Server. Dzięki niemu możemy opublikować w postaci usługi WMS projekty stworzone w QGIS Desktop, z użyciem graficznego interfejsu użytkownika i bogatych opcji wizualizacji danych. 

Ponieważ uruchomienie QGIS Server na komputerze lokalnym nie przedstawia większych trudności, skupię się zatem na tym, jak dokonać tego na zewnętrznym serwerze. 

Dalszy opis zakłada, że dysponujemy serwerem VPS lub dedykowanym, z zainstalowanym systemem Debian/Ubuntu, do którego mamy dostęp przez SSH i uprawnienia superużytkownika.

Instalacja 

Instalację zaczniemy od zalogowania się na serwer jako użytkownik z uprawnieniami administracyjnymi, lub jeśli konfiguracja nie dopuszcza takiego logowania bezpośrednio przez SSH – wydajemy komendę sudo su, dzięki czemu nie trzeba będzie wpisywać „sudo“ przed każdą kolejną.

Wersja stabilna 1.7, niestety, nie nadaje się do użycia jako serwer – każde skierowane do niego zapytanie skończy się komunikatem błędu 500 Internal Server Error. Jest to spowodowane błędem programistycznym, wykrytym już po opublikowaniu wydania. Konieczne jest zatem skorzystanie z usług wersji Master. Na stronie http://hub.qgis.org/projects/quantum-gis/wiki/Download#Master odnajdziemy repozytorium odpowiednie dla naszej dystrybucji. Otwieramy do edycji plik /etc/apt/sources.list i wklejamy właściwe linie, na przykład dla Ubuntu 11.10 będą one następujące:

deb     http://qgis.org/debian-nightly oneiric main
deb-src http://qgis.org/debian-nightly oneiric main

W kolejnym kroku wydajemy komendy:

apt-get update
apt-get install qgis-mapserver libapache2-mod-fcgid

Jeśli wszystko poszło dobrze, QGIS Server powinien zostać zainstalowany w katalogu /usr/lib/cgi-bin/qgis_mapserv.fcgi . Jeśli jednak zdecydujemy się teraz skierować do niego zapytanie, odpowiedź będzie brzmiała Internal Server Error – brak jest bowiem dostępnych plików projektu.

Przygotowanie projektu 

W QGIS Desktop

W oknie Właściwości projektu znajduje się zakładka o nazwie Serwer WMS, która odpowiada za ustawienia związane z publikacją projektu w sieci. Najważniejszym z nich jest sekcja „Tylko te układy współrzędnych“ – trzeba koniecznie ją zaznaczyć i wybrać rzeczywiście przydatne, w przeciwnym wypadku serwer zwróci w odpowiedzi na GetCapabilities wszystkie dostępne, włącznie z bardzo egzotycznymi.

Oprócz tego konieczne jest ustawienie zapisu bezwzględnych ścieżek dostępu.

Symbole SVG 

Wszystkie niestandardowe symbole SVG muszą zostać przekopiowane na serwer. Domyślnie odczytywane są one z katalogu /usr/share/qgis/svg.

Symbole stworzone innymi metodami – poprzez złożenie czcionek, kształtów i kolorów – są zapisywane w pliku .qgs, zatem nie trzeba się nimi przejmować.

Ścieżki dostępu

Najbardziej komfortowa sytuacja ma miejsce wtedy, gdy komputer używany do pracy nad projektem ma identyczny system operacyjny i konfigurację, co serwer – w takim wypadku można już przystąpić do kopiowania danych i pliku projektu. Jeśli jednak jest inaczej, trzeba będzie dokonać pewnych zmian w pliku projektu przy pomocy edytora tekstu – najlepiej, żeby był dostosowany do edycji dokumentów XML.

Żeby projekt stworzony w QGIS Desktop zadziałał prawidłowo na serwerze, wszystkie ścieżki dostępu muszą się zgadzać. W przypadku przenoszenia projektu z systemu Windows należy zwrócić szczególną uwagę na katalog domowy (Windows  używa C:/Users/nazwa, natomiast Linux – /home/nazwa). Dla przykładu porównanie definicji warstwy Shapefile dla Linux i Windows:

Linux

              _home_admin_punkty_shp20120227210555964
            /home/admin/punkty.shp
            
            
            /home/admin/punkty.shp

Windows

              _Users_admin_punkty_shp20120227210555964
            C:/Users/admin/punkty.shp
            
            
            C:/Users/admin/punkty.shp

W przypadku danych przechowywanych w bazie PostGIS trzeba sprawdzić parametry połączenia – te są na szczęście zapisywane identycznie niezależnie od systemu.

Kopiowanie plików

Dane umieszczamy w katalogach zgodnie z podanymi w pliku projektu ścieżkami, pamiętając o tym, żeby mogły być odczytane przez wszystkich (chmod 644 albo chmod a+r).

Jeśli chodzi zaś o plik projektu, to istnieje kilka możliwości:

  • umieszczenie w katalogu domowym użytkownika. Jest to najprostsze rozwiązanie, ale i mało eleganckie: adres serwera WMS będzie miał postać http://domena.pl/cgi-bin/qgis_mapserv.fcgi?map=/home/admin/projekt.qgs 
  • umieszczenie w katalogu /usr/lib/cgi-bin. Najlepsze rozwiązanie, gdy publikowany jest tylko jeden projekt – adres będzie miał postać http://domena.pl/cgi-bin/qgis_mapserv.fcgi
  • utworzenie dla każdego projektu podkatalogu w /usr/lib/cgi-bin, oraz przekopiowanie tam plików qgis_mapserv.fcgi, wms_metadata.xml i admin.sld. Wówczas adres przyjmie postać http://domena.pl/cgi-bin/projekt1/qgis_mapserv.fcgi

Teraz wystarczy już tylko zrestartować serwer HTTP:

/etc/init.d/apache2 restart

i można dokonać próby połączenia.

Pierwsze zapytanie będzie przetwarzane dość długo, gdyż serwer będzie potrzebował czasu na przetworzenie pliku projektu. Kolejne powinny być przetworzone już dużo szybciej.

TileCache – przyspieszenie dla WMS

Wprowadzenie

Nie ulega wątpliwości, że usługa WMS była ogromnym krokiem naprzód w udostępnianiu informacji geograficznej. Ma ona jednak jedną podstawową wadę: nie nadaje się do szybkiej obsługi dużej liczby użytkowników. Konieczność generowania nowego obrazu mapy na każde, choćby drobne przesunięcie szybko doprowadzi do przeciążenia najmocniejszego nawet serwera, jeśli tylko jednoczesnych użytkowników będzie wielu. Dodatkowo znikający nawet na pojedyncze sekundy obraz mapy mocno pogarsza komfort korzystania.

Czytaj całość

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

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)

Czytaj całość

GIS SUPPORT sp. z o.o.


SZKOLIMY

z QGIS oraz innego otwartego oprogramowania GIS.

zobacz ofertę szkoleń


WSPIERAMY

świadczymy komercyjne wsparcie dla oprogramowania open source GIS w Polsce. Wdrażamy i pomagamy w migracji na otwarte oprogramowanie

dowiedz się więcej


PROGRAMUJEMY

mamy bardzo duże doświadczenie w tworzeniu aplikacji GIS oraz geoportali w oparciu o komponenty open source GIS

dowiedz się więcej