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ć.
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.:
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.
Pakiet Google Maps API składa się z dwóch podstawowych komponetów:
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.
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.
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.
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.
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.
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.
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.
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.
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).
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.