Konwersja danych OpenStreetMap do formatów GIS

Po pobraniu części lub całości danych stajemy przed kolejnym problemem: jak ich użyć w środowisku GIS? Ze względu na specyficzny model danych, są one dla większości standardowych narzędzi zupełnie niestrawne. Istnieje szereg konwerterów, z których omówię trzy: wtyczkę QGIS, osm2pgsql oraz Imposm.

[important]Poniżej opiszę sposoby konwersji danych,które są zoptymalizowane pod kątem wizualizacji. Innych narzędzi trzeba będzie użyć w celu zbudowania topologii sieci, albo stworzenia bazy punktów adresowych.[/important]

 1. OpenStreetMap Plugin

Jest to standardowo instalowana wtyczka do QGIS – wystarczy ją włączyć.

Oprócz pobierania danych z API, posiada również funkcję wczytywania plików .osm pozyskanych innymi sposobami. Dużą wadą tego rozwiązania jest ograniczenie liczby dostępnych kolumn atrybutów do 9 predefiniowanych – wobec mnogości tagów jest to o wiele za mało, oraz brak obsługi plików skompresowanych bzip2. Po wczytaniu do widoku QGIS powstaną 3 warstwy – po jednej na obiekty punktowe, liniowe i powierzchniowe. Następnie można je zamienić na pliki Shapefile, przez klik prawym klawiszem myszy i „Zapisz jako…”.

2. Osm2pgsql

Konwerter ten służy do importu danych OSM do bazy PostGIS. Umożliwia import plików .osm, .pbf i .osm.bzip2, a także aktualizację bazy przy pomocy diffów. W systemie Linux można go zainstalować z pakietów (w Ubuntu znajduje się w standardowym repozytorium), bądź skompilować ze źródeł. Dla Windows najnowszą wersję trzeba skompilować samemu, natomiast starsze są dostępne jako jeden z elementów pakietu Hotosm.

Narzędzie obsługuje się z linii komend. Dostępnych jest wiele parametrów, których lista wyświetli się po wykonaniu komendy osm2pgsql -h. Baza danych tworzona przez osm2pgsql składa się z trzech tabel przestrzennych: planet_osm_point, planet_osm_line i planet_osm_polygon. Liczba kolumn, tworzonych na podstawie kluczy tagów, jest zależna od użytkownika – ustala się ją za pomocą pliku .style (można stworzyć swój od zera lub edytować domyślny default.style, w Ubuntu zlokalizowany jest w katalogu /usr/share/osm2pgsql).

Import danych może zostać dokonany w trybie standardowym – wówczas wszystkie dane OSM zostaną załadowane do pamięci RAM, lub w tzw. slim mode. Istotą tego drugiego jest utworzenie tymczasowych, nieprzestrzennych tabel, służących jako magazyn. Umożliwia to przetwarzanie plików większych niż rozmiar RAMu.

Baza utworzona przez osm2pgsql jest wyjątkowo mało przyjazna w korzystaniu, głównie za sprawą ogromnej liczby kolumn. Nowe wersje pozwalają nieco ograniczyć ten problem, korzystając z zapisu wszystkich tagów w jednej kolumnie typu hstore. Schemat podziału danych na trzy tabele jest sztywny – jedyne, na co mamy wpływ, to ilość kolumn. Głównym zadaniem tego narzędzia jest przygotowanie bazy dla wizualizacji za pomocą biblioteki Mapnik.

3. Imposm

Jest to stosunkowo nowy konwerter importujący dane OSM do bazy PostGIS, wymyślony i rozwijany przez firmę Omniscale. Napisano go w języku Python. Zamiast pamięci RAM lub tymczasowych nieprzestrzennych tabel PostgreSQL – Imposm wykorzystuje plikową bazę Tokyo Cabinet. Niestety sprawia to, że nie zadziała w systemie Windows. W odróżnieniu od osm2pgsql użytkownik ma znacznie większy wpływ na schemat bazy danych: ilość, nazwy, zawartość, typ geometrii tabel są w pełni konfigurowalne. Możliwe jest skupienie wartości tagów z różnych kluczy (np. pokrycie terenu z kluczy landuse, natural, man_made, leisure, waterway) w jednej kolumnie „type“, co bardzo ułatwia wizualizację, a także ograniczenie importowanych wartości – pomocne przy tworzeniu map tematycznych.

Ponadto, konwerter ten umożliwia automatyczne tworzenie tabel o zgeneralizowanej geometrii (za pomocą funkcji ST_Simplify z PostGIS) dla map w małych skalach i widoków łączących różne dane, np. wszystkie kategorie dróg razem.

Imposm również jest obsługiwany z linii komend. Podstawowe polecenia to:

–read – wczytuje dane OSM z pliku (XML albo PBF) i umieszcza w tymczasowej bazie Tokyo Cabinet,

–write – zapisuje dane z Tokyo Cabinet do PostGIS, zostaną umieszczone w tabelach z przedrostkiem osm-new,

–deploy-production-tables – przenosi dane z tabel osm-new-… do tabel właściwych.

Narzędzie to posiada dwie istotne wady: brak możliwości aktualizacji bazy za pomocą diffów (planowane do implementacji, obecnie trwa pozyskiwanie funduszy na opłacenie zewnętrznych programistów) oraz importu relacji innych niż multipolygon i boundary. W zakresie relacji typu route (np. szlaki turystyczne, linie komunikacji miejskiej, drogi krajowe i wojewódzkie) udało mi się tymczasowo rozwiązać problem, na bitbucket.org jest dostępny fork o nazwie imposm-routes.