Prosa
Ich spiele so ein bisschen mit OSM (OpenStreetMap) rum und mich nervt doch gewaltig, dass es keine wirklich nutzbaren Datenimportwerkzeuge aus den XML Dateien gibt, die funktionieren und nicht den Rechner sprengen.
Schon lange wollte ich ein eigenes Programm schreiben, welches mir die Daten nach sqlite oder MySQL importiert.
Es sollte aber nicht in Java geschrieben sein, nicht hunderte von Paket-Abhängigkeiten erfordern und auch keinen
herkömmlichen XML Parser nutzen, weil meine Versuche alle unbefriedigend waren.
Ich habe nun erstmals ein Programm geschrieben, welches meinen Anforderungen zunächst genüge tut.
Und weil es möglicherweise Leute gibt, die auch so was suchen, veröffentliche ich dieses Programm.
Es ist in Perl geschrieben und erfordert folgende Pakete: utf8, IO, Switch, DBI, sqlite
ImportOSM2sqlite
Der Aufruf erfolgt folgendermassen: ./ImportOSM2sqlite myOSMfile.osm
Lauffähig ist das Programm auf jedem Betriebssystem, für das es Perl gibt. Also Unix, Linux, Mac OSX, MS Windows (Active Perl for Windows)
Performance:
Die Performance lässt sich nicht so einfach messen, weil der Flaschenhals beim Datenimport die Festplatte ist und beim anlegen des Inhaltsverzeichnisses die CPU.
Auf meinen Testrechnern konnte ich beim Datenimport zwischen 4MB/Sekunde (Standard IDE) bis 16MB/Sekunde (SATA) erreichen.
Weitere Programme im Archiv
Ab Version 0.0.4 wird ein Programm namens cleanDB.pl mitgeliefert.
Dieses sucht verwaiste Nodes, also Nodes, die keinerlei Bezug zu Attributen, Wegen oder Relationen haben und somit für die Arbeit nutzlos sind und damit nur die Datenbank verstopfen.
cleanDB löscht automatisch diese verwaisten Nodes.
Dies erfordert nochmal, je nach Datenbankgrösse, eine lange Laufzeit, da mehrere Millionen Datenbankabfragen durchgeführt werden. Es ist aber möglich, cleanDB zur Laufzeit mittels CTRL-C abzubrechen und später nochmal neu zu starten. Weil die Datensätze sofort gelöscht werden, macht cleanDB dort weiter, wo es abgebrochen wurde.
Historie:
Donnerstag, 21. Juli 2011: Release 0.0.3
Änderungen: Datenbankindizierungen geändert
Donnerstag, 21. Juli 2011: Release 0.0.2
Änderungen: Datenimport massiv beschleunigt, Datenbank auf UTF-8 umgestellt, Versionierung eingeführt
Dienstag, 19. Juli 2011: Release 0.0.1
Releases:
Download ImportOSM2sqlite, Version 0.0.3
Download ImportOSM2sqlite, Version 0.0.2
Download ImportOSM2sqlite, Version 0.0.1, Datenimport fest nach sqlite, Vorgabe des Datenbanknamens ‚osm.sqlitedb‘, Kompatibel zu OSM API 0.6
FAQ:
- Kann ich auch nach MySQL importieren?
Im Unterverzeichnis ‚Modules‘ musst Du in jedem Modul die Datenbankeinstellungen ändern, dann funktioniert der Datenimport nach MySQL. Oder auch andere Datenbanksysteme - Kann ich bestimmte Tags verhindern zu importieren?
Im Hauptprogramm Importosm2sqlite.pl in den Zeilen um 75 herum (next if ($Zeile =~ ) ) lassen sich diese next if Zeilen erweitern. Alternativ gibt es im Nodes-Modul auch noch in der Funktion SetAttributes einige Filter. - Wie schnell ist der Datenimport?
In Version 0.0.1 benötigt das Programm ca. 18 Sekunden pro MB XML Datei. Dies konnte in Version 0.0.2 auf 4 Sekunden pro MB XML Datei gesenkt werden. In Version 0.0.2 werden ungefaehr 20.000 Zeilen XML Datei pro Sekunde abgearbeitet. - Wie halbiert man die Importdauer innerhalb eines Releases?
Ich habe sämtliche Konsistenz- und Integritätsprüfungen des Datenbanktreibers abgeschaltet. Das bedeutet allerdings, dass man, sollte der Rechner während des Datenimports abstürzen, die Datenbank löschen und von vorne beginnen muss. Allerdings muss man bei einem Rechnerabsturz ja sowieso von vorne beginnen. Daher spielt es gar keine Rolle, ob Integritätsprüfungen gemacht werden oder nicht. In der Massendatenverarbeitung sind solche „Tuningmassnahmen“ üblich, weil ja zunächst einmal mit der ganz grossen Schaufel die Daten verschoben werden. - Warum ist die sqlite Datenbank so sehr viel kleiner als die XML Datei?
XML hat einen riesigen sogenannten Overhead. Zudem werden manche Daten, die uns für die Arbeit mit den Daten als solches auch gar nicht interessieren, wie zum Beispiel die Versionierungsdaten oder der Name des Benutzers, der den Wegpunkt eingetragen hat, nicht mit importiert. - Wie schnell sind die Abfragen in sqlite?
Es kommt darauf an, wie die Abfragen sind. Werden die Abfragen so gemacht, wie man es für ein Navigationssystem nutzen würde, werden folgende Zeiten erreicht:
Die Testdatenbank mit den Daten für Deutschland umfasst etwa 5GB. Eine rein zufällige Abfrage über 1000 Datensätze aus einer zufällig ausgewählten Region benötigt für die Node-ID und den dazu enthaltenen Attributen 0.74 Sekunden. Das heisst, es werden 1.000 Node-IDs mittels Lat und Lon Einschränkung abgefragt, die jeweils 1.000 Abfragen auf die Attribute Tabelle umfassen. Somit handelt es sich genaugenommen um 1.001 einzelne SELECT Abfragen. Die gesamte Laufzeit umfasst dann 0.74 Sekunden.