Datenbankschema für OpenStreetMap-Daten

Im ersten Teil soll es darum gehen die Openstreetmap-Daten in eine MySQL-Datenbank einzulesen. Später wird eine Möglichkeit gezeigt, aus den Daten einen gerichteten Graphen z.B. für eine Wegsuche zu erstellen, danach wird eine Wegsuche realisiert.

Aber zunächst müssen die Daten eingelesen werden. Benötigt wird:

• Eine funktionierende Installation eines MySQL-Servers (> Version 5.0) mit ordentlich Speicherplatz (Ich rede hier mindestens von Gigabyte-Zahlen für Baden-Württemberg, ganz Deutschland dürfte im Bereich um die 10GB liegen) und Administrations-Umgebung
• Eine funktionierende Java-Installation. Das von mir für den Import geschriebene Skript gibt eine SQL-Befehlskette auf der Standardausgabe aus, mit der Bash (Linux-Kommandozeile) lässt sich das direkt in eine MySQL-Verbindung schicken.

Als erstes wollen wir einen Blick auf die Openstreetmap-Daten werfen. Sie liegen im XML-Format vor und können auch auszugsweise z.B. bei Geofabrik heruntergeladen werden. Ich habe mir für das Projekt die Daten von Baden-Württemberg (baden-wuerttemberg.osm) heruntergeladen.

Wenn man die knapp 80MB große bz2-Datei entpackt hat, liegen ca.1 GB Daten auf der Festplatte. In die kann man mal reinschauen (aber bitte mit einem Tool, das Zeilenweise liest, z.B. “less”). Eine Analyse dieser Datei und ein Blick auf diese zwar veraltete, aber für diesen Zweck ausreichende Wikiseite führte mich zum Datenbankschema, wie in der Grafik.

Hier ist die zugehörige MySQL-Import-Datei.

Nachdem man eine Datenbank angelegt hat kann das oben gezeigte Schema erzeugt werden. Jetzt fehlt natürlich noch der Datenimport. Dafür entstand nach mehreren Versuchen ein Java-Programm, das aus einer *.osm-Datei einen entsprechenden Import herstellt.

Der Quellcode des Java-Programms lässt sich hier herunterladen. Seine Benutzung ist einfach. Das Programm erwartet einen Parameter mit dem Pfad/Dateinamen einer *.osm-Datei und erzeugt daraus einen MySQL-Input auf dem Std-Out. Nach dem Kompilieren von osm2sql sollte sich (zumindest auf der Linux-Bash) mit einem entsprechend angepassten Befehl der Art

java osm2sql baden-wuerttemberg.osm | mysql --host=localhost --database=osm --user=osm --password=abc

die Datenbank füllen lassen. Jetzt kann man normalerweise erst mal einen Tee kochen gehen. Ein wenig Zeit sollte man dem Datenbankserver schon gönnen.

Kommentare und Hinweise zum Thema sind hier nicht nur erlaubt, sondern ausdrücklich erwünscht.

Ähnliche Artikel:

1. HowTo: OpenStreetMap-Daten in MySQL-Datenbank importieren
2. OpenStreetMap-Daten nach MySQL (Die Zweite)
3. OpenStreetMap-Projekt: Teil2 – Von den Rohdaten zum gerichteten Graphen

Heute haben wir uns mal dem Zeit-Problem bei der Entfernungsberechnung zwischen zwei Städten gewidmet. Wir haben mit 10 bis 20 Sekunden pro Abfrage begonnen. Fritsch hat dann heute Mittag beschlossen, die Indizes auf ein anderes Format zu ändern. Weg von BTREE hin zu HASH. Auch wenn das laut MySQL 5.0-Referenz gar nicht geht, hat uns das etwa eine Vervierfachung der Geschwindigkeit gebracht auf etwa 4 Sekunden.

Bisher hatten wurde ein View eingesetzt, der für alle Stadt-Kombinationen den Abstand berechnen konnte. Die Städte wurden dann per WHERE in der Abfrage eingeschränkt. Dumm nur, das die Abstandsberechnung recht aufwändig ist, weil sie 6 trigonometrische Funktionen auf einmal durchführt. Offenbar wurden die für jede Zeile berechnet, auch wenn die Zeile am Ende nicht ausgegeben wurde.

Deshalb habe ich mich heute abend nach fritschs “Ich waterboarde mich selbst”-Aktion nochmal hingesetzt und eine Stored Procedure geschrieben, die zunächst 2 Tabellen erzeugt, in denen jeweils die Daten zu den beiden eingegebenen Städten stehen und erst dann eine Berechnung durchführt. Damit bin ich jetzt auf unter 0,5 Sekunden runter, was durchaus akzeptabel ist. Interessanterweise macht es auch praktisch keinen zeitlichen Unterschied, ob ich mir die Entfernungen von Bremen nach Heidelberg ausgeben lasse oder alle Entfernungen von Bre* nach Hei*. Obwohl das 125 Zeilen mehr ergibt.

Ein paar Probleme gibts aber doch noch:

• Bisher habe ich das Thema Encoding noch nicht betrachtet. Auf der Kommandozeile mit mysql werden Unicode-Zeichen fehlerhaft ausgegeben und auch die Eingabe ebensolcher Namen funktioniert nicht.
• PhpMyAdmin scheint nicht mit Stored Procedures umgehen zu können.
• Eine Stored Procedure ist einfach keine Tabelle und kein View und unkomfortabler zu nutzen.

P.S.: Wie man Stored Procedures in MySQL schreibt, habe ich mir in diesem Tutorial angeeignet.

Ähnliche Artikel:

1. OpenStreetMap-Projekt: Teil2 – Von den Rohdaten zum gerichteten Graphen
2. Es scheint zu funktionieren
3. Der Durchbruch

Nach genau 2 Zeilen in der Import-Datei und damit auch 2 Zeilen im osm2sql ist der Import jetzt etwa um Faktor 40 schneller.

Es geht um die Zeile
SET AUTOCOMMIT=0;
ganz am Anfang und die Zeile
COMMIT;
ganz am Schluss. Die sorgen

1. für Datenkonsistenz, weil ohne erfolgreichem COMMIT die ganze Transaktion ein Rollback bekommt, also danach wie nicht ausgeführt aussieht und
2. für Tempo, weil nicht jede Zeile einzeln committed wird.

Jetzt kann ich beruhigt ins Bett gehen, denn auch der Import von Dateien im zweistelligen Gigabyte-Bereich dürfte in halbwegs realistischer Zeit erfolgen. Ein Nachteil ist, dass diese Funktion bei MySql nur mit der Datenbank-Engine InnoDB funktioniert.

Fehlt noch der Export der jetzt installierten Fremdschlüssel, die erstaunlicherweise alle sofort funktioniert haben, in eine Schema-Datei, dann werd ich wohl mal ein großes Planet-File auf die DB loslassen.

Ähnliche Artikel:

1. OpenStreetMap-Projekt: Teil1 – Openstreetmap-Daten in MySQL-Datenbank einlesen
2. Abstandsmessung optimieren
3. HowTo: OpenStreetMap-Daten in MySQL-Datenbank importieren

Was sagt uns obige Ausgabe?

Richtig, der Datenimport hat nicht geklappt und der tödliche Fehler trat kurz vor Schluss auf. Nachdem ich jetzt ein wenig danach geschaut habe, ärgert er mich echt… Der Fehler besteht aus einem falschen Spaltennamen – Tippfehler.

Ein anderer Fehler ist auch noch passiert, da wurde ein falscher Tabellenname genutzt. Die ganzen Fehler sind korrigiert und das Spiel kann von neuem starten. – Wird wohl bis heute Abend dauern.

Ähnliche Artikel:

1. OpenStreetMap-Daten nach MySQL (Die Zweite)
2. Der Durchbruch
3. OpenStreetMap-Projekt: Teil1 – Openstreetmap-Daten in MySQL-Datenbank einlesen

Im letzten Artikel haben wir festgestellt, dass das Datenbankschema, das von “osmosis” erzeugt wird, nicht so der Bringer ist, deshalb habe ich mir erlaubt mit großer Hilfe und Sachverstand meines Freundes fritsch ein eigenes Datenbankschema zu entwerfen und natürlich auch gleich noch den dazu fälligen Parser zu schreiben.

Ich habe heute viel dabei gelernt (nur kein EZT – Gruß an tacco):

1. Versuche niemals selbst XML zu parsen. Es sieht ganz einfach aus und endet im Desaster.
2. Versuchs wirklich nicht!
3. Benutze lieber einen fertigen Parser, dem du mitgibst, was er mit den Tags anfangen soll.

Vor ein paar Tagen haben wir festgestellt, dass 400MB XML mit Xalan etwa 3 GB RAM brauchen, wenn sie zu einem DOM-Baum aufgebaut werden. Ein kleiner Test mit einer Perl-XML-Klasse, die eben dieses macht, hat heute fritschs neuerdings 8GB RAM in Sekundenschnelle komplett gefüllt. Deshalb bleibt nur sequentielles Lesen der Daten übrig. Java bietet dafür einen Sax-Parser, mit dem das ganz gut ging.

Mit etwas Quellcode war dann auch recht zügig eine SQL-Ausgabe erzeugt. Das Debugging dauerte aber Stunden, denn wenn in Zeile 1.500.745 des SQL-Imports ein Fehler auftaucht, merkt das MySQL erst nach etwa 1 Stunde. Eigentlich brauch ichs gar nicht zu erwähnen, es ist mehrfach passiert. Man braucht dann auch echt lustige Konstrukte:

elementstring.replaceAll("\\\\","\\\\\\\\").replaceAll("'","\\\\'")

Das kommt vom doppelt escapen. Einmal für den Java-String, und einmal für den RegExp. So bedeuten 4 Backslashes genau einen Backslash im zu durchsuchenden String.

Jetzt ist unser Server im dritten Durchgang beschäftigt und irritiert uns mit äußerst ungenauen Größenangaben der Tabellen. Mal sehen an welcher Stelle der 7.078.487 Zeilen er heute Nacht rausfliegt. Aktuell sind wir etwa bei Zeile 1.000.000.

Ähnliche Artikel:

1. OpenStreetMap-Projekt: Teil1 – Openstreetmap-Daten in MySQL-Datenbank einlesen
2. HowTo: OpenStreetMap-Daten in MySQL-Datenbank importieren
3. Rechner an der Grenze