Hat das einer mal ausprobiert, taugt das was? Die Idee find ich ja nicht doof, OSM-Daten nach sqlite zu importieren, grad so für schlanke Website-Lösungen: http://www.reisenetzwerk.net/importosm2sqlite/
Klar taugt das was. Ich habs ja geschrieben 
Bin aktuell dabei, testweise einen Import von Deutschland (16GB XML = ca. 4GB sqlite DB) zu machen.
Es könnte performanter sein.
Die ersten 2GB XML haben rund 8 Stunden gedauert, allerdings auf meinem alten 2GHz 1 Core Entwicklungsrechner mit 1GB RAM unter FreeBSD.
Wenn der Konverter was taugt, wo könnte man gut einen Verweis im OSM-Wiki anbringen?
Hmmm…ich habs als 0.0.1 released. Soll man das jetzt schon offiziell machen?
Ich würde dann vorher auch den Namen nochmal ändern wollen, da man sehr simpel den Import auf MySQL, Oracle und MS SQL Server umbauen kann, indem man einfach den Connect-String ändert.
Im wesentlichen habe ich ja nur einen eigenen XML Parser geschrieben - die Datenbank hinten raus ist offen. Alles was Perl kann, kann auch mein Tool.
Meine Skripte unterstützten leider auch immer nur XML, aber PBF bringt sicherlich noch mal ordentlich Schwung in die Verarbeitungspipelin
Ich würde gerne PBF auch importieren aber ich habe noch keine mir verständliche Dokumentation gefunden - das leidige Problem bei OSM.
Ich habe dann eben Version 0.0.2 released. Die Importgeschwindigkeit ist jetzt drastisch erhöht worden. Das Script verarbeitet nun rund 4000 Zeilen XML Datei pro Sekunde oder 4 Sekunden pro MB oder rund 18 Stunden für das 16 GB Deutschland XML (hochgerechnet). Ich habe keine Vergleichsdaten aber ich glaube jetzt einfach, dass ich bei der jetzigen Geschwindigkeit schon mit den grossen mitspielen kann.
Umbennen werde ich es nicht, wie oben geschrieben. Da mache ich dann lieber ein ImportOSM2mysql und ein ImportOSM2sql fuer einen SQL Textexport).
Sonst wird die Bedienung wieder zu kompliziert
Habe eben nochmal ein Release gemacht, 0.0.3.
Dies sollte jetzt bis auf weiteres das letzte sein.
Der Datenimport für ein aktuelles 16GB Deutschlandfile hat inkl. anlegen der Indezes rund 17 Stunden gedauert.
1.000 wahllose Abfragen der nachher 5GB grossen sqlite Datenbank mittels
$LatMin = rand(6)+47;
$LatMax = rand(6)+51;
$LonMin = rand(6)+1;
$LonMax = rand(8)+7;
$SQL = “SELECT * FROM Nodes WHERE Lat > $LatMin AND Lat < $LatMax AND Lon > $LonMin AND Lon < $LonMax LIMIT 0,1000”;
$res2 = $dbh->prepare($SQL);
$res2->execute();
while ( $ret2 = $res2->fetchrow_hashref())
{
$ID = $ret2->{‘ID’};
print “Node-ID: $ID\n”;
$SQL = “SELECT * FROM Attr WHERE ID=$ID”;
$res = $dbh->prepare($SQL);
$res->execute();
while ( $ret = $res->fetchrow_hashref())
{
print $ret->{‘ID’} . “,” . $ret->{‘k’} . “,” . $ret->{‘v’} . “\n”;
}
}
zeigen folgendes Laufzeitverhalten:
Versuch 1:
real 0m0.673s
user 0m0.396s
sys 0m0.041s
Versuch 2:
real 0m1.291s
user 0m0.440s
sys 0m0.021s
Versuch 3:
real 0m0.697s
user 0m0.402s
sys 0m0.044s
0,7 - 1.3 Sekunden für 1.000 zufällige Abfragen auf 76.297.417 Datensätze und Abfrage auf Abhängigkeiten von 8.640.710 Datensätzen - ich glaube nicht, dass ich das besser hinbekomme.
Bei 10.000 Datensätzen zeigt das Laufzeitverhalten
Versuch 1:
real 0m6.251s
user 0m3.545s
sys 0m0.259s
Versuch 2:
real 0m7.108s
user 0m3.607s
sys 0m0.375s
Versuch 3:
real 0m6.069s
user 0m3.465s
sys 0m0.339s