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. 
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)
[...] letzten Artikel haben wir festgestellt, dass das Datenbankschema, das von “osmosis” erzeugt wird, nicht [...]
[...] 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 [...]