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

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