OSM-Daten in PostGIS und QGIS – Nachtrag

Im ersten Artikel OSM-Daten in PostGIS und QGIS habe ich beschrieben, wie man OSM-Daten via osm2pgsql in eine PostGIS-Datenbank importiert und mit QGIS darstellen kann. Dabei habe ich darauf hingewiesen, dass der Import in Postgis auch mit OSMOSIS geschehen kann. Leider habe ich das zu diesem Zeitpunkt noch nicht genauer beschreiben können. Mittlerweile habe ich das aber ausprobiert und bin recht schnell auf die Unterschiede aufmerksam geworden.

Was sind die Gemeinsamkeiten?

Grundsätzlich erledigen osm2pgsql und osmosis die gleichen Arbeit: importieren von OSM-Daten (in Form einer osm-Datei aus der XAPI 0.6). Damit ist es aber auch schon vorbei mit den Gemeinsamkeiten.

Was sind die Unterschiede?

OSM2PGSQL erstellt vier Tabellen, in denen Linien, Punkte, Polygone und Straßen getrennt enthalten sind. Die Tabellen sind 54 bzw. 55 Spalten breit!! Die meisten Attribute (keys bzw. tags) sind in jeder Tabelle enthalten, ganz gleich, ob diese benutzt werden oder nicht. Die Tabellen können direkt an QGIS angebunden werden und damit auch dargestellt werden. Abfragen nach Straßennamen und anderen Attributen sind möglich. So weit, so gut.

OSMOSIS erzeugt stolze 10 Tabellen, was auf den ersten Blick auf eine stärkere Normalisierung der Daten hinweist. In der Tat werden z. B. die Attribute (keys bzw. tags) von den eigentlichen Geometrien mit den — nennen wir sie mal — administrativen Daten (z. B. Version, User-ID, Timestamp, Changeset) getrennt und per OSM-Objekt-ID miteinander verknüpft. Vorteil ist, die Tabellen sind übersichtlicher. Nachteil ist, man muss die Tabellen per JOIN verknüpfen, um z. B. den Namen zu einer Straße zu bekommen. Mit ein bisschen SQL ist das aber z. B. im PGAdminIII kein Problem.

Erstes Fazit

Was ich bei der OSM2PGSQL-Version besser finde, ist die oberflächliche Art mit den Daten umzugehen. Man sucht allerdings vergeblich nach einem Timestamp oder dem User, der die Daten ursprünglich erzeugt hat. Wer mit anonymisierten Daten ohne Zeitbezug hinkommt, ist mit dieser Version bestens bedient. Bei OSMOSIS habe ich die komplette Struktur der Daten verfügbar. Durch leichte Modifikationen an den Tabellen (Details dazu in einem anderen Artikel) kann ich eine Historie aufbauen und mir den Stand der Erfassung zu bestimmten Stichtagen (sagen wir z. B. innerhalb eines bestimmten Jahres) ansehen. Das ist z. B. der Grund, warum ich wohl eher zu OSMOSIS greifen werde. Einen Haken hat das Ganze aber doch: ich kann die OSMOSIS-Daten nicht direkt an QGIS anhängen! Wo ein Wille ist, ist aber auch ein Weg. Das Problem liegt im Primärschlüssel, der in PostGIS angelegt wird. OSMOSIS erzeugt für die Geometrietabellen eine ID als BIGINT — QGIS erlaubt derzeit aber nur INTEGER als Primärschlüssel (Hinweis: OSMOSIS erzeugt auch keine OIDs!). Momentan kommt man aber noch mit Integerwerten für die IDs aus, weshalb man einfach die Tabellenstruktur ändern kann und das Feld ID in den Tabellen ways und nodes von BIGINT in INTEGER ändert — das wars (siehe weiter unten)!

Da ich die ganze Prozedur für OSM2PGSQL schonmal beschrieben habe (siehe hier) setze ich jetzt die Installation von Postgresql, PostGIS und QGIS einfach voraus. Wir steigen dort ein, wo wir die OSM-Daten in einem Verzeichnis per wget abgelegt haben (nach dem Absatz “Her mit den OSM-Daten …“). OSM2PGSQL muss für dieses Beispiel nicht installiert sein, kann es aber.

Zuerst muss OSMOSIS installiert werden. Dazu laden Sie sich bitte die letzte Version in ein Verzeichnis Ihrer Wahl (Download OSMOSIS) und installieren es nach der Anleitung auf der Downloadseite (Subpage Installation, rechts oben in dem Kasten). In der Verzeichnisstruktur von OSMOSIS gibt es jetzt einen Ordner script, in dem sich ein Skript befindet, mit dem man die grundlegende Datenbankstruktur anlegen kann (pgsql_simple_schema_0.6.sql). Wechseln Sie zunächst in diesen Ordner (das hängt davon ab, wo Sie das OSMOSIS-Archiv entpackt haben).

In der Datenbank muss zunächst das Tabellenschema erzeugt werden. Mit dem folgenden Befehl kann man das Skript zur Erstellung der Datenbankstruktur ausführen: psql -d meingis -f ./pgsql_simple_schema_0.6.sql . Jetzt wechseln Sie bitte in das Verzeichnis mit der OSM-Datei. Alles, was Sie jetzt noch tun müssen ist, die Daten in die Datenbank zu importieren. Dazu benutzen Sie bitte den Befehl: <Pfad zu OSMOSIS>/bin/osmosis –read-xml file=“./data.osm“ –write-pgsql user=“gisadmin“ database=“meingis“ password=<ihr Passwort> . Hinweis des Autors: ich hatte keinen Erfolg, meine Daten zu importieren, solange ich kein Passwort vergeben hatte — was man bei lokalen Testinstallationen ja nicht immer macht :) .

Jetzt sollten Sie zunächst den PGAdminIII öffnen und sich mit der Datenbank meingis verbinden. In den Tabellen nodes und ways ändern sie den Typ der Spalten ID von BIGINT zu INTEGER (Doppelklick auf den Feldnamen, Typ INTEGER auswählen und mit OK bestätigen). Mit ein bisschen Zeit, werde ich mir allerdings noch die Skripts zur Erstellung der Datenbankstruktur ansehen und diese so ändern, dass man sofort eine QGIS-kompatible Struktur bekommt. Dazu später mehr …

In bekannter Weise kann man jetzt in PGAdminIII oder QGIS auf die Daten zugreifen (siehe hier). Die Darstellung in QGIS ist allerdings recht simpel (keine direkte Unterscheidung der Straßentypen oder Nodes möglich), was aber Zugunsten der Datenstruktur für mich in Ordnung geht. Auch hier werde ich mich nochmal vertiefend einarbeiten, um die Attribute mit den Geometrien zu verknüpfen und damit eine differenzierte Darstellung in QGIS zu erlauben. Dazu muss man dann wohl einen VIEW oder eine ganz neue Tabelle in PostGIS erstellen. Bei VIEWs werden die notwendigen Primärschlüssel nicht erkannt. OIDs könnten hier Abhilfe schaffen. Auch dazu dann später mehr …

Und jetzt?

Wenn bis hierhin alles geklappt hat, werden sich sicher noch weitere Fragen zu speziellen Anwendungen ergeben. Die OSM-Daten sind teilweise besser, als man denkt. Ich wiederhole mich eigentlich nur ungerne, aber bitte beschweren Sie sich nicht bei mir, wenn gerade in Ihrem Bereich der Karte noch Informationen fehlen: warum haben Sie die denn noch nicht erfasst? OpenStreetMap ist ein offenes Projekt für jeden, der Daten dazu beitragen kann!
Bitte richten Sie Ihre Fragen doch einfach per EMail an mich (siehe Kontaktformular). Entweder kann ich diesen Artikel fortsetzen oder individuelle Antworten geben bzw. meine Unterstützung anbieten.

Werbung