HowTo: OpenStreetMap-Daten in MySQL-Datenbank importieren

Nachdem der letzte Versuch mit OpenStreetMap-Daten an ihrer schieren Menge gescheitert ist, kommen wir jetzt auf eine Alternativ-Idee zurück:

Alle Daten in eine Datenbank importieren und mit geschickten Joins nur die interessanten Daten ausgeben. Um den Import der Daten in die MySQL-Datenbank soll es jetzt gehen.

1. Schritt: Anlegen eines Datenbankbenutzers und einer Datenbank, die ihm gehört.

Ich erstelle der Einfachkeit halber einen Benutzer “osm” und seine Datenbank “osm” mit PhpMyAdmin. Passwort bleibt leer, host ist “localhost”.

2. Schritt: Anlegen der Tabellen-Struktur für den Import der Daten.

Eine einfache SQL-Import-Datei gibt es hier: http://gweb.bretth.com/osm_schema_latest.sql
Dieses Schema kann z.B. mit PhpMyAdmin nach Wahl der Datenbank mit dem Reiter Import erstellt werden werden.

3. Schritt: Download und Installation des Tools Osmosis.

Ich nutze in diesem Fall die vorkompilierte Version:

wget http://gweb.bretth.com/osmosis-latest.tar.gz
tar xvfz osmosis-latest.tar.gz
cd osmosis-0.29
bin/osmosis

4. Schritt: Importieren der planet.osm-Datei oder eines Auszuges von ihr

Ich wähle in diesem Fall wieder die baden-wuerttemberg.osm aus dem letzten Artikel:

bin/osmosis --read-xml ../baden-wuerttemberg.osm --write-mysql host="localhost" database="osm" user="osm"

Jetzt laaaange warten. Nach einiger Zeit liegen dann 1,1 GiB Daten in der Datenbank. – Aus ursprünglich 386MB im XML-file. Dafür ist der Zugriff jetzt im Vergleich rasend schnell.

Nur doof, dass die Daten kein ordentliches Schema haben, dass es keinen Fremdschlüssel gibt. fritsch hat sichs angeguckt und nur geschimpft. :-)

Kommentare

4 Kommentare zu “HowTo: OpenStreetMap-Daten in MySQL-Datenbank importieren”

  1. Peter am September 26th, 2008 11:06

    Das Schema ist schlichtweg “scheisse”.

    Aus folgendem Gründen.
    Datenhaltung / Konsistenz
    – Keine Fremdschlüssel in der Datenbank zu semantischen Abhängigkeiten
    – Keine Datenintegrität erforderlich. Subnodes ohne nodes ohne weiteres möglich, weil nicht durch FKs in der DB abgesichert.

    Verständnis

    – Nur wer wirklich weiss, wie die Zusammenhänge sind, der kann diese aus dem Schema zurückholen

    Dabei ist es so einfach:
    – Ein Baum besteht aus Knoten und Blättern. Die Besonderheit bei diesem DOM Baum ist folgende, dass es eigentlich nur “Knoten” gibt, diese Knoten enthalten auch die eigentlichen Werte. Das heisst ein Knoten hat eine Doppelfunktion – was aber egal ist erstmal.

    – Die Verbindung eines Vaterknotens zu seinem Sohnknoten ist graphisch durch eine Linie gegeben. Diese Linie gilt es “mit abzubilden” und schon ist der Zusammenhang für immer fest und eindeutig.

    Wie macht man das?
    – Was im Baum eine Verbindung war (Zeiger), wird jetzt sehr einfach durch einen Foreignkey abgebildet. Dieser Foreignkey ist sagen wir mal “bidirektional”, aka der Vater weiss wer sein Kind ist und das Kind wer sein Vater ist.

    Als Tipp zum Einfügen in die Datenbank:
    – Definiere den FK auf dem Kind
    – Füge erst alle Väter ein (in der jeweiligen Höhe h des Baums)
    – dann die Kinder auf der Ebene h+1

    Gedanken machen sollte man sich allerdings noch über den Primärschlüssel, dieser könnte “einfach gedacht” ein zusammengesetzter Schlüssel aus Längengrad und Breitengrad sein – aber mal kurz überlegen, wenn über der örtlichen Batteriesammelstelle noch ein gelber Briefkasten hängt ;-).

    Lösung könnte sein, da wir für die FKs eh innodb Tabellen verwenden müssen (isam kann das noch nicht), dass man für diese Tabellen eine AutoIncrement spalte einführt. (Beim Insert einfach auf NULL lassen, mysql macht das schon).

    Für Oracle könnte ein workaround eine Sequenz sein (die können noch kein AutoIncrement)

  2. OpenStreetMap-Daten nach MySQL (Die zweite) | goblor grübelt am September 28th, 2008 01:44

    […] letzten Artikel haben wir festgestellt, dass das Datenbankschema, das von “osmosis” erzeugt wird, nicht […]

  3. OpenStreetMap-Projekt: Teil1 – Openstreetmap-Daten in MySQL-Datenbank einlesen | goblor grübelt am October 16th, 2009 21:12

    […] Damals ging es um das Einlesen der Daten in eine eigene Datenbank und es gab schonmal ein HowTo, dessen Datenbankschema sich aber recht schnell als unnötig groß herausgestellt hat. Wirklich […]

  4. Sharky am April 19th, 2011 01:45

    cylSwp Great tihnnikg! That really breaks the mold!

Schreibe einen Kommentar