Bild1: Beispiel-Darstellung von einigen Wegen nach OSM-Schema

In Bild1 ist  Beispielhaft ein Ausschnitt aus einer möglichen Karte aus den Rohdaten zu sehen, die allerdings für eine Wegsuche viele unnötige Knoten enthält und deren Datenstruktur für unsere Zwecke nicht sonderlich praktisch ist. Wir brauchen für die Wegsuche nur die Weglänge zwischen zwei verbundenen End- oder Kreuzungs-Knoten.

Die Knoten 3, 4, 6, 9 und 10 brauchen wir nicht.
Prinzipiell ist auch Knoten 1 nicht notwendig, wenn der rote Weg eine Einbahnstraße ist und der braune jedoch nicht oder auf einer der beiden Straßen eine Geschwindigkeitsbeschränkung gilt, wird er doch wieder gebraucht. In den Open-Streetmap-Daten sind auch Brücken durch einen eigenen Weg eingezeichnet. Damit kosten uns Brücken und Tempobeschränkungen zusätzliche Verbindungen, ich nehme das in diesem Fall aber in Kauf, um später Tempobeschränkungen und Einbahnstraßen berücksichtigen zu können.

Bild2: Optimierte Wegdarstellung durch die Verbindungs-Tabelle

Die Verbindungs-Tabelle enthält also eine Zeile für jeden Startknoten, Endknoten und der Wegstrecke dazwischen, wie in Bild2 (die natürlich notwendige Entfernung zwischen den Knoten fehlt hier). Weil wir Einbahnstraßen berücksichtigen wollen, werden Verbindungen, die keine Einbahnstraßen sind, werden in beide Richtungen einmal abgelegt. Das ist zwar nicht effizient, vereinfacht aber unserer Arbeit. Optimieren können wir auch noch, wenn erst mal alles läuft, wie wir uns das vorstellen.

Zunächst muss die eine Tabelle verbindungen mit diesem SQL-Skript angelegt werden. Zum Erstellen der Verbindungstabelle nutze ich dann eine Stored Procedure. Die arbeitet direkt in der Datenbank und ist deshalb recht schnell. Ihr Ablaufdiagramm ist im Bild3 zu sehen. Zu Beginn wird eine sehr aufwändige Abfrage ausgeführt, die einen Großteil der Informationen ausliest, die später benötigt werden und mit einem Cursor zeilenweise abgearbeitet wird. In ihr wird festgelegt, welche Wege überhaupt berücksichtigt werden. Wenn wir einen Routenplaner für Autos wollen, ist es wohl eher nicht so hilfreich Fußwege und Treppen in der Karte zu haben.

Bild3: Ablaufdiagramm zum Erstellen der Verbindungen

Das hier bereitgestellte Skript berücksichtigt bereits Einbahnstraßen, das macht die Abfrage zu Beginn zwar noch aufwändiger, allerdings ist es für Autofahrer einfach nicht interessant Einbahnstraßen in Gegenrichtung zu befahren.

Mit dem Befehl

CALL erstelleVerbindungen();

kann die Datenbank gefüllt werden. Das dauert wieder ziemlich lange. Alleine das Erstellen der ersten Abfrage nimmt bei mir für Baden-Württemberg bereits über 3 Minuten in Anspruch, aber erst danach werden auch Daten geschrieben. Diese Procedure kann sicherlich noch optimiert werden, ich habe mich damit nicht mehr genauer beschäftigt, als sie in brauchbarer Zeit das gewünschte Ergebnis geliefert hatte.

[Update 24.10.] Ich habe noch einen Fehler im Skript entdeckt, der lustige Fehler produziert hat. Einige Straßen, wie die Europabrücke über den Rhein bei Karlsruhe hatten in Baden-Württemberg nur einen Wegpunkt. Das hatte den Effekt, dass große Strecken mit Entfernung 0 in die Verbindungsliste eingetragen wurden, die eigentlich nicht mal verbunden waren. So lässt sich natürlich keine ordentliche Wegsuche realisieren. Der Fehler ist aber nun behoben.

Ähnliche Artikel:

1. OpenStreetMap-Projekt: Teil1 – Openstreetmap-Daten in MySQL-Datenbank einlesen
2. HowTo: OpenStreetMap-Daten in MySQL-Datenbank importieren
3. Das ist also eine schlechte Soundkarte

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

Manchmal frag ich mich, was für Nerds es auf der Welt noch so gibt. Irgendjemand hat in halb Karlsruhe die Hausnummern aufgenommen. Die Karlsruher Karte ist ohnehin schon beeindruckend genau, die hängt jede Karte ab, die ich bis jetzt von Karlsruhe gesehen habe.

Dafür sind viele Orte auf dem Land noch fast gar nicht gemapped. Von Grosselfingen im Zollernalbkreis gibt es lediglich einen Node, der den Ort benennt. Aber so schlimm ist das auch wieder nicht, sagt man nicht in den Nachbarorten “Liaber gar koin Finger, wie en Grosselfinger”.

Ähnliche Artikel:

1. “Funk-Internet, hämmer sowas?”
2. So müssen Ferienspiele sein
3. WG-Zimmer zu vermieten

Das hätte ich mir allerdings mal früher überlegen sollen. MySQL hat da so ne nette Funktion, die heißt LOAD DATA INFILE und die sorgt jetzt dafür, dass ich mein bisheriges Parsing komplett überarbeiten muss.

Eine Alternative wäre noch LOCK TABLES und UNLOCK TABLES. Das wäre erheblich einfacher, bringt aber wahrscheinlich nicht so viel Geschwindigkeitsvorteil. Ich werde es wohl ausprobieren.

Immerhin habe ich schonmal 2 Views zum Testen erzeugt. Ausgabe aller Städte und die Entfernung in Luftlinie zwischen allen Städten.

Ähnliche Artikel:

1. Datenimport nach 10 Stunden
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

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.

Ähnliche Artikel:

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

Deshalb habe ich mir gestern die Zeit genommen mich mal mit der Datenstruktur des Projekts zu befassen. Alle Kartendaten werden nämlich als XML-Datei zur Verfügung gestellt. Zum Test hatte ich eigentlich vor, eine kleine Umkreissuche zu implementieren, mit der man alle Orte die kleiner einer wählbaren Entfernung von einem Punkt entfernt sind, erhält.

Die Idee war: Schreibe ein XSLT-Stylesheet, das für alle Orte die Information vom Ortstyp (village, town, city), den Namen und den zugehörigen Längen- und Breiteninformation, aus dem planet.osm extrahiert. Auf diesem erheblich kleineren XML könnte dann entweder ein weiteres XSLT arbeiten oder es könnte einfach in eine Datenbank eingelesen werden.

Zum Testen habe ich mir die Daten von Baden-Württemberg geladen, die sind entpackt 386MB groß. Dazu habe ich mir ein kleines Template geschrieben, das die Daten extrahiert. Heute Nacht habe ich die Transformation aber leider nicht mehr durchgeführt bekommen. Mein Rechner mit seinem einen Gigabyte RAM ging sowohl mit Xalan, als auch mit procxslt in die Knie. Selbst der Server im Flur mit 2GB RAM hat es nicht gepackt. Heute hat mein Kumpel fritsch seine Kiste dafür zur Verfügung gestellt. Seine 4GB RAM wurden auch fast komplett genutzt.

Xalan baut einen DOM-Baum, das kostet einfach zu viel Speicher. Eigentlich hätte ich gerne noch Saxon getestet, weil der sequentiell arbeitet, aber leider hat die aktuelle Version wohl einen Bug, der das unmöglich macht. Auf alle Fälle muss eine andere Technik her. Die Ideen gehen vom selbstgebauten Parser, über einen Komplett-Import in eine Datenbank. Das planet.osm mit Daten für den ganzen Planeten ist momentan gepackt etwa 4,4GB groß. Es gibt also noch jede Menge Optimierungsbedarf.

Ähnliche Artikel:

1. HowTo: OpenStreetMap-Daten in MySQL-Datenbank importieren
2. OpenStreetMap-Daten nach MySQL (Die Zweite)
3. Es scheint zu funktionieren