Scheint so, als hätte osmconvert beim erstellen der osm-Datei Daten weggezaubert, denn die danach wieder erzeugten PBFs mit osmconvert und osmosis sind beide kleiner als das Original. Außerdem komprimiert osmconvert wohl am Besten. Oder vergisst was.
Wieder mit osmosis beide zurückwandeln.
time osmosis --rb iran.osm.pbf.2 --wx iran.osm.2
real 0m20.396s
user 0m19.337s
sys 0m1.536s
time osmosis --rb iran.osm.pbf.3 --wx iran.osm.3
real 0m19.013s
user 0m16.991s
sys 0m1.516s
Ergebnis: Osmosis ist schneller, wenn’s die selbst erstellte PBF-Datei wieder zu OSM konvertieren soll. Die osmconvert-PBF-Datei ist wohl schwerer verständlich für osmosis. Vielleicht, weil die PBF-Datei von osmconvert besser gepackt war.
Direkt das Original mit osmosis zu OSM:
time $OSMI --rb iran.osm.pbf --wx iran.osm.4
real 0m16.738s
user 0m16.911s
sys 0m1.458s
212895192 iran.osm.1 ← erstellt mit osmconvert aus Geofabrikoriginal
217482736 iran.osm.2 ← Kombination osmconvert-osmosis
217482605 iran.osm.3 ← Kombination osmosis-osmosis
217482672 iran.osm.4 ← direkt mit osmosis aus Geofabrikoriginal
Osmosis scheint Daten herbeizuzaubern.
Genaue Analyse des Inhalts der Dateien und deren Unterschiede folgt.
Laufzeitmessung unter windows7 sind mit der Powershell möglich:
Measure-Command {Start-Process test.bat -wait}
test.bat enthält in einer Batchdatei alle wichtigen Aufrufe. Ein direkter Aufruf von osmconvert mit allen Parametern ist mir nicht gelungen.
wo werden eigentlich die Tempdateien von osmcovert gelagert? Kann man darauf einfluss nehmen und wie groß sind die?
Spannend wäre die auf eine Ramdisk oder auf einen USB Stick auszulagern.
Also was die Optimierung angeht, so ist da offenbar noch einiges an Luft drin. Nichteinmal die Festplatte ist wirklich mit ständigen Lese und Schreibzugriffen traktiert worden. Die Auslastung lag hier nur bei durchschnittlich 30-35%.
Der Prozessor läuft zwar mit maximaler Taktfrequenz, aber nur bei 25% Auslastung. (4-Kern Prozessor) 3 Kerne scheinen sich die Arbeit zu teilen. während der 4. fast nichts zu tun hat.
Korrekt! Beides.
Ich wollte mögliche Kompatibilitätsprobleme von vornherein ausschließen. Die, die das Letzte rauskitzeln wollen, werden das Programm sowieso selber übersetzen.
Du hast Recht, das schaut doof aus, aber praktisch alle anderen Programme machen es genauso. Ich wollte vom Syntax her nicht zu sehr abweichen, weil sich möglicherweise manche Software drauf verlässt. Probleme gabs zum Beispiel schon mal mit den FOSM-Downloads; die verwenden durchgehend das einfache Hochkomma: ’
Mit -v oder -v=2 verrät osmconvert zwar den Präfix für die Namen der temporären Dateien, aber beim reinen Umwandeln von .osm nach .pbf wird keine benötigt und deswegen auch keine angelegt. Der gesamte Speicherplatzbedarf dürfte etwas unter einem halben GB liegen und damit für die meisten Systeme unkritisch sein.
Und ja, in osmconvert läuft nur ein einziger Thread. Das ist meist praktisch, weil die Maschine dann nebenher noch anderes erledigen kann, aber wenns um Geschwindigkeitswettbewerbe geht, natürlich noch verbesserungsfähig. Die Frage ist, ob es den Aufwand lohnt, die Programmstruktur auf parallele Verarbeitung umzubauen.
Zur Dateigröße:
Am Anfang hab ich mich auch gewundert, dass die von osmconvert erzeugten .pbf-Dateien kleiner sind als die von Geofabrik. Insbesondre deswegen, weil osmconvert nicht alle Optimierungsmöglichkeiten nutzt. Es werden zum Beispiel die Strings nicht nach Häufigkeit sortiert. Erklären kann ich mir den Unterschied nur mit der Blockgröße. Das PBF-Format speichert die Daten blockweise und erlaubt Blöcke bis zu einer Größe von 32 MiB. osmconvert schöpft diese Größe zur Sicherheit nicht ganz aus, packt aber immer ca. 31 MB in einen Block. Osmosis packt meines Wissens immer genau 8000 Objekte (nodes, ways oder relations) in einen Block, dadurch wird die Blockgröße nicht ausgenutzt.
Größere Blöcke lassen sich besser komprimieren (das PBF-Format sieht blockweise Komprimierung mit dem zlib-Algorithmus vor).
Leerstring-Fehler:
Letzte Nacht habe ich noch einen Fehler entdeckt. Er tritt auf, wenn in den XML-Daten ein Leerstring enthalten ist. Wenn also irgendwo nicht “xyz”=“yes” sondern “”=“yes” steht. Einen solchen Fall gibts in Westengland. Keine Ahnung, wie der Tag dort reingekommen ist, denn eigentlich sollte sowas durch die Editoren abgewiesen werden. In der Folge konnte europe.osm nicht korrekt in eine PBF-Datei umgewandelt werden, die Tags bei manchen Knoten wurden falsch zugeordnet. Eine neue Version (0.3V) lade ich hoch, sobald der Vergleich durchgelaufen ist.
Womit wir beim Thema “Vergleich” wären:
Unter Linux kann man mit dem Befehl “diff” zwei Dateien zeilenweise vergleichen (unter Windows mit “fc” soweit ich mich noch erinnere). Leider geht “diff” mit dem Speicherplatz verschwenderisch um, so dass es nicht möglich ist, Dateien zu vergleichen, die mehrere GB groß sind - schon gar nicht die 128 GB der europe.osm. Für solche Zwecke gibt es aber den Befehl “cmp”. Er ist im Vergleich zu “diff” weit weniger komfortabel, erlaubt aber byteweise Vergleiche von beliebig großen Dateien. Mit dem Parameter “-i” lassen sich die ersten paar Bytes überspringen, so dass man auch Dateien vergleichen kann, die mit unterschiedlichen Programmversionen geschrieben wurden. Beispiel:
cmp -i 100 europe1.osm europe2.osm
So, ich hoffe, ich hab keinen vergessen.
Melde mich wieder, sobald die Version 0.3V online ist.
EDIT:
Version 0.3V ist online: m.m.i24.cc/osmconvert_pbf.c bzw. m.m.i24.cc/osmconvert_pbf.exe
Meinen nächsten Test mache ich mit dem Planet-File. Kann allerdings sein, dass die .osm-Datei dann nicht auf meine Platte passt. Also, Mittester immer willkommen.
Ganz ehrlich: ich weiß es nicht. Erkennen wird osmupdate die Endung “.pbf” bei der Zieldatei nicht, das heißt, man muss dem Programm mit “–out-pbf” auf die Sprünge helfen. “–out-pbf” wird dann direkt an osmconvert übergeben und sollte dafür sorgen, dass die Zieldatei im PBF-Format erstellt wird. Habs aber noch nicht probiert.
Besser wärs natürlich, osmupdate würde das “.pbf” selber erkennen und wissen, was es zu tun hat. Ich sollte das bei Gelegenheit mal einbauen…
EDIT:
Probier bitte mal m.m.i24.cc/osmupdate_pbf.c
PBF-Dateien sind allerdings nicht ideal für regelmäßige Updates. Zum einen beherrscht osmconvert nur das Format der “normalen” gepackten PBF-Dateien, und diese können nur relativ langsam gelesen und geschrieben werden (im Vergleich zu .o5m). Zudem fehlt der PBF-Formatdefinition der Datei-Zeitsrempel, so dass die Ausgangsdatei immer zuerst analysiert werden muss, um festzustellen, von wann die Daten sind.
Auf der Diskussionsseite zu PBF habe ich vor einer Weile vorgeschlagen, einen Zeitstempel einzuführen. Das wird sich aber noch etwas verzögern, weil der Erfinder des Formats eine weitergehende Optimierung des Headers plant. Wann sie realisiert wird, ist leider noch offen. Ich hak da noch einmal nach.
Ich denke wieviel Potential da drin steckt sieht man wenn man sich die beiden Zeiten einmal anschaut. pbf->osm sind 36 Minuten und ein bisschen. die umgedrehte Richtung sind bereits 1h und 6 Minuten. und von osm nach osm (wenn man --out-pbf vergisst) dauert 1h 19 min.
Ferner fällt die Prozessorauslastung bei der Umwandlung von OSM Dateien zu anderen Dateitypen auf, dass die Auslastung unter 25% sinkt. Das passiert zwar auch bei der Verarbeitung von pbf Dateien, aber dort wesentlich seltener, weil das immer dann auftritt, wenn die Aktivität auf der Festplatte zu nimmt. Sprich wenn ein neuer Datenhappen eingelesen wird langweilt sich die CPU. Gleichzeitig langweilt sich die Festplatte während die CPU einiges zu tun hat, aber eben bei weitem nicht ausgelastet ist. Es spricht auch nichts dagegen die CPU Last bei 75% zu belassen oder eine niedrige Prozesspriorität zu wählen um anderen Prozessen den Vorrang zu lassen. Aber wenn das Programm den Prozessor hochtaktet und dann aber nur zu einem viertel braucht ist das schade.
Ja, ist leider eine OSM-Eigenart. Irgendwer hat damit angefangen, und die anderen habens nachgemacht - auch ich. Letztlich ist es aber nur ein Schönheitsproblem, denk ich…
@Henning:
Ich hab beschlossen, nicht auf Nutscrape (Autor des PBF-Formats) zu warten und den Datei-Zeitstempel im Format so zu ergänzen, dass andere Programme ihn verwenden können, aber nicht durcheinanderkommen, wenn sie diese Formatergänzung nicht kennen (Element “optional_features”). http://wiki.openstreetmap.org/wiki/Talk:PBF_Format#File_Timestamp.3F
(hochgeladen als Version 0.3W)
Wenn du die neuesten Versionen von osmupdate und osmconvert verwendest (die mit “_pbf.c” hinten), dann sollte es nun auch ganz regulär funktionieren. Beispiel:
osmupdate alt.pbf neu.pbf
Falls die alte PBF-Datei beim ersten Update keinen Zeitstempel enthält, berechnet osmupdate diesen automatisch; das passiert per Statistik-Funktion von osmconvert. Die Statistik-Funktion liest die gesamte Datei und sucht unter allen Objekten (node, way, relation) den neuesten timestamp. Dieser wird dann als Datei-Zeitstempel verwendet und in Zukunft direkt im Datei-Header gespeichert.
Aber Vorsicht, die entsprechenden PBF-Formaterweiterungen sind erst eine Stunde alt, ausführlich getestet ist das natürlich noch nicht.
EDIT:
Beim Update sollte natürlich das richtige Polygon (bzw. das richtige Rechteck) mit angegeben werden, das hab ich grad vergessen. Beispiel:
PS
Das “cmp” ist schon recht unkomfortabel.
Vielleicht wär’ ja noch eine Alternative, die Datei per
split -l 10000000
(oder ähnlich) aufzuteilen und dann einzeln zu "diff"en, so wie es frühers “bdiff” gemacht hat.
Mein einfacher Planet-Test hat geklappt:
planet-latest.osm.pbf runtergeladen und mit osmconvert in .osm umgewandelt.
Danach das .osm in .pbf und wieder zurück in ein zweites .osm umgewandelt und dann die beiden .osm verglichen. - Kein Unterschied.
Da beide .osm-Dateien gleichzeitig wahrscheinlich nicht ganz beim Server auf die Platte gepasst hätten, hab ich sie schon beim Schreiben mit lzop komprimiert. Witzigerweise waren zwar die .osm.lzo-Dateien unterschiedlich, deren (entpackte) Inhalte aber gleich.
Nachdem die letzten Tests recht positiv verlaufen sind, hab ich mich dazu entschlossen, die Versionen offiziell einzustellen. Aktuell sind also:
osmconvert Version 0.4
osmupdate Version 0.2
Die Testversionen mit “_pbf” hinten sind damit überholt.
So ähnlich habe ich’s gemacht. Allerdings nicht mit split, weil das ja wieder neue riesen Dateien erzeugt, sondern mit head und einer for-Schleife.
head -n -100 gibt alle Zeilen außer den ersten 100 aus. Wenn man statt 100 was größeres wählt und dann diese Zahl mittels der for-Schleife bei jedem Schritt mit einer Zahl multipliziert, das ganze dann an ein zweites head weiterleitet, dann kann man das Ergebnis „diffen". Allerdings muss man das ganze dann natürlich für beide entsprechenden Dateien machen. Am einfachsten geht das mit benannten Röhren, auch „named Pipes" genannt. Eigentlich schade, dass diff sowas nicht schon eingebaut hat, aber geht ja schnell zu basteln.
Also etwa so:
mkfifo bla{1,2}
for ((i=1; i<=1000; i++)); do
(head -n -$((100*$i)) DATEI1 | head -n 100 > bla1) &
(head -n -$((100*$i)) DATEI2 | head -n 100 > bla2) &
colordiff bla1 bla2
done
Wäre doch langweilig alles gleich.
Danke für den Hinweis mit dem Polygon, bei mir ist es aber wirklich der gesamte Planet.