osmconvert schreibt PBF

icke!

kellerma wrote:

icke!

Oha, aus Preußen? ;-)

Habs grad die Beta als Version 0.3P hochgeladen:
m.m.i24.cc/osmconvert_pbf.c

Übersetzen wie üblich mit
cc osmconvert_pbf.c -lz -o osmconvert

Bitte noch nicht in einer produktiven Umgebung einsetzen. Zwar waren meine Tests erfolgreich (bremen.osm und germany.osm), aber die Version ist noch seeehr neu.
Ach ja, neue Option: --out-pbf

Marqqs wrote:

kellerma wrote:

icke!

Oha, aus Preußen? ;-)

Habs grad die Beta als Version 0.3P hochgeladen:
m.m.i24.cc/osmconvert_pbf.c

Übersetzen wie üblich mit
cc osmconvert_pbf.c -lz -o osmconvert

Bitte noch nicht in einer produktiven Umgebung einsetzen. Zwar waren meine Tests erfolgreich (bremen.osm und germany.osm), aber die Version ist noch seeehr neu.
Ach ja, neue Option: --out-pbf

Kurze Frage, wie kann man die Intigrität der erzeugten PBF testen? Ich meine nur lesen und schreiben ist ja das eine. Die Frage ist wie man Fehler entdeckt. Ich würde dann unter Windows auch ein paar Durchläufe machen. Schickst mir die Version am Besten übersetzt und dann jage ich das mal durch.

viw wrote:

Kurze Frage, wie kann man die Intigrität der erzeugten PBF testen? Ich meine nur lesen und schreiben ist ja das eine. Die Frage ist wie man Fehler entdeckt. Ich würde dann unter Windows auch ein paar Durchläufe machen. Schickst mir die Version am Besten übersetzt und dann jage ich das mal durch.

Hallo auch!
Hab eine Windows-Testversion grad hochgeladen: m.m.i24.cc/osmconvert_pbf.exe
Wie man die Integrität testen kann, weiß ich nicht genau. Ich hab bei meinen Tests einfach umgewandelt:
Zuerst das Original-PBF besorgt (z.B. bremen.osm.pbf von Geofabrik), dann per osmconvert in .osm umgewandelt.
Dieses .osm dann in .pbf umgewandelt und wieder zurück in (ein anderes) .osm.
Anschließend hab ich das erste und das zweite .osm verglichen.

Hoffentlich war das jetzt nicht zu wirr... :-)

Marqqs wrote:

Hallo auch!
Hab eine Windows-Testversion grad hochgeladen: m.m.i24.cc/osmconvert_pbf.exe
Wie man die Integrität testen kann, weiß ich nicht genau. Ich hab bei meinen Tests einfach umgewandelt:
Zuerst das Original-PBF besorgt (z.B. bremen.osm.pbf von Geofabrik), dann per osmconvert in .osm umgewandelt.
Dieses .osm dann in .pbf umgewandelt und wieder zurück in (ein anderes) .osm.
Anschließend hab ich das erste und das zweite .osm verglichen.

Hoffentlich war das jetzt nicht zu wirr... :-)

Also es scheint zu funktionieren unter Windows7 mit Sachsen erfolgreich getestet. Allerdings ist mir beim Umwandeln aufgefallen, dass der 4 Kern Prozessor nur zu 25% ausgelastet ist. Eventuell gibt es hier Optimierungsmöglichkeiten für die Geschwindigkeit. Wichtig ist vielleicht dabei, dass kein Prozessorkern um die 100% rennt und auch die Festplattenlampe flackert immer wieder. Eventuell kann man in einem Prozess in Den arbeitsspeicher lesen und mit einem weiteren Prozess im Speicher umwandeln während der erste Prozess einen weiteren Bereich liest und dann schreibt er die Daten des ersten Schrittes weg, während der zweite Teil im Speicher bearbeitet wird.
Klingt total kompliziert und ich weiß nicht ob es was bringen könnte.

M:\>osmconvert_pbf␣-v␣europe.osm.pbf␣>europe1.osm
osmconvert:␣Verbose␣mode.
osmfilter␣Parameter:␣europe.osm.pbf
osmconvert:␣Last␣processed:␣relation␣1769936.

M:\>osmconvert_pbf␣-v␣europe1.osm␣--out-pbf␣>europe1.osm
osmconvert:␣Verbose␣mode.
osmfilter␣Parameter:␣europe1.osm
osmfilter␣Parameter:␣--out-pbf
osmconvert␣Error:␣file␣empty:␣europe1.osm
osmconvert␣Exit:␣5

Das Europe file war nicht ganz aktuell. Es ist noch vom 30.9.11

Wäre es nicht sinnvoll zu schauen, ob bspw. osmosis mit dem erstellten pbf klar kommt?

Bspw. osm laden, dann zu pbf dann mit osmosis zu osm und schauen, ob es dann noch geht.

aighes wrote:

Wäre es nicht sinnvoll zu schauen, ob bspw. osmosis mit dem erstellten pbf klar kommt?

Bspw. osm laden, dann zu pbf dann mit osmosis zu osm und schauen, ob es dann noch geht.

Das Problem ist, dass OSmosis einen anderen OSM Dialekt spricht. das heißt die Dateien am Ende sind nicht identisch. Daher ist es dann auch nicht einfach festzustellen ob es einen Fehler gab.

Du lädst dir ein osm von der Geofabrik (von osmosis erstellt=Referenz), dann mit osmconvert nach pbf und das dann mit osmosis wieder zu osm. Dann hast du den gleichen "Dialekt" zum vergleichen.

viw wrote:

Also es scheint zu funktionieren unter Windows7 mit Sachsen erfolgreich getestet. Allerdings ist mir beim Umwandeln aufgefallen, dass der 4 Kern Prozessor nur zu 25% ausgelastet ist. Eventuell gibt es hier Optimierungsmöglichkeiten für die Geschwindigkeit. Wichtig ist vielleicht dabei, dass kein Prozessorkern um die 100% rennt und auch die Festplattenlampe flackert immer wieder. Eventuell kann man in einem Prozess in Den arbeitsspeicher lesen und mit einem weiteren Prozess im Speicher umwandeln während der erste Prozess einen weiteren Bereich liest und dann schreibt er die Daten des ersten Schrittes weg, während der zweite Teil im Speicher bearbeitet wird.
Klingt total kompliziert und ich weiß nicht ob es was bringen könnte.

Nein, nicht kompliziert, sondern sicher eine gute Idee. Ob es den Programmieraufwand lohnt, weiß ich noch nicht. Mal schauen, zuerst muss der Programm korrekt arbeiten, das ist viel wichtiger als Geschwindigkeitsoptimierungen.

"osmfilter Parameter:" - das ist noch ein Bug. Natürlich müsste da "osmconvert" stehen.

"file empty: europe1.osm" - ist die Datei wirklich leer? Nein, oder? Wie ist die genaue Größe? Vielleicht gibts ein Problem mit der 2-GB-Grenze. Oder ist es gepackt? Eine ungepackte .osm-Datei ist ja riesengroß...

@aighes:

Ja, ganz sicher sinnvoll! Mit germany.osm hab ich es schon probiert. Die von Osmosis erzeugte .pbf-Datei kann man aber nicht direkt mit der von osmconvert erzeugten vergleichen. Osmosis beherrscht zwar mehr Optionen (z.B. mit und ohne Kompression, Densenodes oder nicht), nutzt das .pbf-Format aber nicht vollständig aus. Das heißt, es gibt schon Unterschiede in der Dateigröße.

Jetzt könnte man natürlich die Osmosis-PBF und die osmconvert-PBF jeweils wieder in eine .osm-Datei umwandeln und die beiden .osm-Dateien vergleichen. Leider packt "diff" so große Dateien nicht. Ach ja, ein Unterschied ist mir trotzdem aufgefallen: In der .osm-Datei, die aus der Osmosis-PBF erzeugt wurde, ist immer wieder mal uid="0" und user="" zu finden. Aus meiner Sicht ist das nicht korrekt, bin mir noch nicht sicher, ob das ein Bug in Osmosis ist.

Also es sollte solche uid="0" geben. Das sind anonyme Einträge...war irgendwann mal möglich.

aighes wrote:

Du lädst dir ein osm von der Geofabrik (von osmosis erstellt=Referenz), dann mit osmconvert nach pbf und das dann mit osmosis wieder zu osm. Dann hast du den gleichen "Dialekt" zum vergleichen.

Guter Plan, klappt so leider nicht ganz:

$␣bzcat␣bremen.osm.bz2␣|head
<?xml␣version='1.0'␣encoding='UTF-8'?>
<osm␣version="0.6"␣generator="pbf2osm">
<node␣id="125799"␣lat="53.0749415"␣lon="8.7868047"␣version="6"␣changeset="7711393"␣user="UScha"␣uid="45445"␣timestamp="2011-03-29T21:43:10Z"/>

Anscheinend werden die .osm-Dateien bei Geofabrik mit pbf2osm erstellt.

aighes wrote:

Also es sollte solche uid="0" geben. Das sind anonyme Einträge...war irgendwann mal möglich.

Ja, das Editieren war mal anonym möglich. Aber in dem Fall darf die XML weder uid noch user enthalten. Jedenfalls hab ich bisher uid="0" noch nie woanders gesehen. Aber von einem echten Standard kann man ja nicht reden, insofern ist es wohl auch kein Bug. :-)

Marqqs wrote:

"file empty: europe1.osm" - ist die Datei wirklich leer? Nein, oder? Wie ist die genaue Größe? Vielleicht gibts ein Problem mit der 2-GB-Grenze. Oder ist es gepackt? Eine ungepackte .osm-Datei ist ja riesengroß...

Ähm doch natürlich sie hat exakt 0kb. Auf NTFS Laufwerken gibt es doch keine 2GB Grenze. Oder wo steckt die? Ich hatte einfach die Idee Europa auszupacken und dann wieder einzupacken und schon die PBF Datei ist ja 6Gb groß. OsmConvert hat sich redlich gemüht. Ergebnis war aber ohne Fehlermeldung 0kb.

Also ich habe den Osmosis test auch mal gemacht. Dafür habe ich mir die Sachsen.osm.pbf geladen und mit Osmosis --rb sachsen.osm.pbf --rx sachsen1.osm erzeugt.
Dann habe ich mit Osmconvert das in ein Pbf gesteckt und mit Osmosis daraus wieder ein xml gemacht. Die beiden Datein verglichen und sie sind anders! wenn man sich aber die ersten Zeilen anschaut, dann sind dort sinnlose Dinge verschieden. Welche gar nicht die Daten betreffen.
Also nochmal die zweite Osm Version in Pbf gepackt und mit Osmosis wieder ausgepackt und jetzt sind die Dateien identisch. Ob jetzt allerdings beim ersten konvertieren Daten verloren gegangen sind und wie man das gegebenfalls prüft weiß ich nicht. Aber das Pbf von Osmconvert versteht osmosis und übersetzt es wieder auf die gleiche Art.

Hallo viw,
das mit dem europe.pbf werd ich heute Abend auch mal testen.

Bezüglich des Formats: vielleicht hilft beim Erzeugen einer XML-Datei mit osmconvert die Option --emulate-osmosis ein wenig. Sie ist zwar nicht perfekt, aber vielleicht werden die Unterschiede dann weniger.

viw -- code wrote:

M:\>osmconvert_pbf -v europe1.osm --out-pbf >europe1.osm
osmconvert: Verbose mode.
osmfilter Parameter: europe1.osm
osmfilter Parameter: --out-pbf
osmconvert Error: file empty: europe1.osm
osmconvert Exit: 5

Marqqs wrote:

"file empty: europe1.osm" - ist die Datei wirklich leer? Nein, oder? Wie ist die genaue Größe? Vielleicht gibts ein Problem mit der 2-GB-Grenze. Oder ist es gepackt? Eine ungepackte .osm-Datei ist ja riesengroß...

Spontane Vermutung: Mit einer Pipe die zu lesende Datei zu schreiben, funktioniert nicht. 😉 Dann ist klar, dass sie leer ist, denn sobald die Pipe angelegt wird, sollte die Datei eigentlich im write-Modus geöffnet sein.
Oder habe ich da irgendwas verpasst?

E-Malte wrote:

Spontane Vermutung: Mit einer Pipe die zu lesende Datei zu schreiben, funktioniert nicht. 😉 Dann ist klar, dass sie leer ist, denn sobald die Pipe angelegt wird, sollte die Datei eigentlich im write-Modus geöffnet sein.
Oder habe ich da irgendwas verpasst?

Äh ja - das hab ich gar nicht gesehen! :-)
Die zu lesende Datei und die zu schreibende sind identisch. Das kann natürlich nicht klappen...

Marqqs wrote:

"osmfilter Parameter:" - das ist noch ein Bug. Natürlich müsste da "osmconvert" stehen.

]
These formats can be written:
.osm (default) .osc .osh .o5m .o5c

das ist noch ein Bug. Natürlich müsste da
.osm (default) .osc .osh .o5m .o5c .pbf
stehen.

😉

E-Malte wrote:

Spontane Vermutung: Mit einer Pipe die zu lesende Datei zu schreiben, funktioniert nicht. 😉 Dann ist klar, dass sie leer ist, denn sobald die Pipe angelegt wird, sollte die Datei eigentlich im write-Modus geöffnet sein.
Oder habe ich da irgendwas verpasst?

Du hast mich überzeugt. Ich werde jetzt also nochmals das Europa durch jagen.

@marqs mir fällt auf das er sehr sparsam mit Hauptspeicher umgeht. Aber wenn es das Programm irgendwie beschleunigt und der Speicher da steht, kann man den auch nutzen. Vielleicht wie bei osm2pgsql mittels Parameter.

lang hat es gedauert, aber seit heute kann osmconvert auch PBF-Dateien schreiben.

Wofür soll das gut sein?

Es wäre sinnvoller, wenn mkgmap dieses o5m Format endlich unterstützen würde!!!

@kellerma:
Stimmt. :-) Hab vorhin u.a. den Hilfetext überarbeitet und aufgesplittet in einen kurzen (-h) und einen langen (--help). Wenn ich die Zeit finde, bau ich noch eine ganz primitive Text-Oberfläche für diejenigen unter den User, die noch gar nicht wissen, was eine Kommandozeile ist und es nur bis zum Doppelklick schaffen.

@viw:
Naja, ein paar hundert MB braucht das Programm schon. Mehr Speicher würde bei der jetzigen Programmstruktur nicht helfen. Warten wir mal, bis es stabil läuft. :-) Schneller als andere Programme ist es möglicherweise sowieso schon. Hab allerdings noch keine brauchbaren Vergleichtests laufen lassen.

Marqqs wrote:

@viw:
Naja, ein paar hundert MB braucht das Programm schon. Mehr Speicher würde bei der jetzigen Programmstruktur nicht helfen. Warten wir mal, bis es stabil läuft. :-) Schneller als andere Programme ist es möglicherweise sowieso schon. Hab allerdings noch keine brauchbaren Vergleichtests laufen lassen.

Der Prozess nimmt sich von 8GB Hauptspeicher gerade einmal 330 MB. Aber ich gebe zu die längste Zeit wartet es warscheinlich auf die Schreibarbeiten der Festplatte. Europa ist 125Gb groß geworden als OsmDatei.
Die Vergleichstests sind auch schwer! Allerdings könntest du ja in die nächste Version die Zeitmessung in ms einbauen. Dann ist es direkt mit osmosis und ohne Stopuhr vergleichbar.

M:\>osmconvert_pbf␣-v2␣europe.osm␣--out-pbf␣>europe1.pbf
osmconvert:␣Verbose␣mode␣2.
osmfilter␣Parameter:␣europe.osm
Read-opening:␣europe.osm
Read-opening:␣increasing␣gzbuffer.
osmfilter␣Parameter:␣--out-pbf
Tempfiles:␣osmconvert_tempfile.2240.*
osmconvert␣Error:␣PBF␣write:␣string␣table␣memory␣overflow.
osmconvert␣Error:␣PBF␣write:␣string␣table␣memory␣overflow.
osmconvert␣Error:␣PBF␣write:␣string␣table␣memory␣overflow.
osmconvert␣Error:␣PBF␣write:␣string␣memory␣overflow.
osmconvert␣Error:␣PBF␣write:␣string␣memory␣overflow.
osmconvert␣Error:␣PBF␣write:␣string␣memory␣overflow.
osmconvert␣Error:␣PBF␣write:␣string␣table␣overflow.
osmconvert␣Error:␣PBF␣write:␣string␣table␣overflow.
osmconvert␣Error:␣PBF␣write:␣string␣table␣overflow.
Read-closing:␣europe.osm
osmconvert:␣Number␣of␣bytes␣read:␣128489105172
osmconvert:␣Last␣processed:␣relation␣1769936.

Leider scheint das umwandeln von Europa in pbf noch nicht zu funktionieren. Ich hatte extra den erweiterten Reportmodus genommen nachdem beim erstenmal der Fehler aufgetaucht ist, aber auch hier ist nicht vielmehr zu erkennen. Könnte es sich dabei um Kyrilische Schriftzeichen handeln, welche nur selten vorkommen? Wie kann man der Sache weiter auf den Grund gehen? Derzeit belegt der Prozess um die 330 MB Haupspeicher das Gesamtsystem unter 2GB von 8GB auf der Festplatte stehen noch 300GB speicher zur Verfügng.

viw wrote:

Die Vergleichstests sind auch schwer! Allerdings könntest du ja in die nächste Version die Zeitmessung in ms einbauen. Dann ist es direkt mit osmosis und ohne Stopuhr vergleichbar.

Du könntest unter Linux mal

time␣osmconvert

und unter Windows

timeit␣osmconvert

ausprobieren.

Dann solltest du eigentlich auch die Zeit ausgegeben bekommen...

So nach dem ich jetzt das pbf wieder zurück in osm wandeln wollte um so durch einen Vergleich die Fehlerhaften Stellen zu finden, ereilte mich nach diesen Fehlern der Programmabsturz:

M:\>osmconvert_pbf␣-v2␣europe1.pbf␣>europe2.osm
osmconvert:␣Verbose␣mode␣2.
osmfilter␣Parameter:␣europe1.pbf
Read-opening:␣europe1.pbf
Read-opening:␣increasing␣gzbuffer.
Tempfiles:␣osmconvert_tempfile.4900.*
osmconvert␣Warning:␣node␣340392673␣user␣string␣index␣overflow:␣1>=0
osmconvert␣Error:␣node␣key␣string␣index␣overflow:␣2,3>=0
osmconvert␣Warning:␣node␣340392674␣user␣string␣index␣overflow:␣3>=0
osmconvert␣Warning:␣node␣340392675␣user␣string␣index␣overflow:␣4294967293>=0
osmconvert␣Error:␣node␣key␣string␣index␣overflow:␣2,3>=0
osmconvert␣Error:␣node␣key␣string␣index␣overflow:␣2,3>=0

E-Malte wrote:

viw wrote:

Die Vergleichstests sind auch schwer! Allerdings könntest du ja in die nächste Version die Zeitmessung in ms einbauen. Dann ist es direkt mit osmosis und ohne Stopuhr vergleichbar.

Du könntest unter Linux mal

time␣osmconvert

und unter Windows

timeit␣osmconvert

ausprobieren.

Dann solltest du eigentlich auch die Zeit ausgegeben bekommen...

Also ich habe keine Ahnung was timeit bewirken soll, aber unter Windows7 findet er es nicht. Bei time macht er das zwar, aber es dauert sehr viel länger!
Edit: Es dauert nicht länger, aber er macht nichts! Weil der Befehl time benutzt auch den Schalter ">"
Edit2: time versucht offenbar der Datei einen anderen Zeitstempel oder sowas zu geben.

Also der Testvergleich zwischen Osmosis und Osmconvert hat für Sachsen ergeben:
Osmconvert schreibt aus sachsen.osm nach sachsen.pbf in ca. 23 Sekunden
Osmosis braucht für die gleiche Datei 44 Sekunden.
Die osmdatei wurde aber zuvor mit osmconvert erstellt und provoziert bei osmosis eine Reihe von Warnungen:

WARNUNG:␣Attention:␣Data␣being␣output␣lacks␣metadata.␣Please␣use␣omitmetadata=tr
ue
15.10.2011␣11:08:50␣crosby.binary.osmosis.OsmosisSerializer$Prim␣serializeMetada
taDense
WARNUNG:␣Attention:␣Data␣being␣output␣lacks␣metadata.␣Please␣use␣omitmetadata=tr
ue
15.10.2011␣11:08:50␣crosby.binary.osmosis.OsmosisSerializer$Prim␣serializeMetada
taDense
WARNUNG:␣Attention:␣Data␣being␣output␣lacks␣metadata.␣Please␣use␣omitmetadata=tr
ue

time ist ein kleines Prograemchen, welches sich auf fast jedem Linux befindet und die Ausfuehrungszeit des nachgestellten Befehls misst, aufgeteilt im System- und User-Zeit.

Aehnliches gab es wohl mal auch fuer Windows (bzw. auf dem Resource Kit) als timeit.exe.
Aber da selbst telnet auf win 7 disabled ist wundert mich gar nix mehr 😉

Back to topic:

italy.osm war bisher das groesste, was ich getestet habe. germany.osm koennt' ich noch testen,
dann ist aber Schluss.
Hat bislang unter Debian 6 funktionokelt.

viw wrote:

Also der Testvergleich zwischen Osmosis und Osmconvert hat für Sachsen ergeben:
Osmconvert schreibt aus sachsen.osm nach sachsen.pbf in ca. 23 Sekunden
Osmosis braucht für die gleiche Datei 44 Sekunden.
Die osmdatei wurde aber zuvor mit osmconvert erstellt und provoziert bei osmosis eine Reihe von Warnungen:

WARNUNG:␣Attention:␣Data␣being␣output␣lacks␣metadata.␣Please␣use␣omitmetadata=tr
ue
15.10.2011␣11:08:50␣crosby.binary.osmosis.OsmosisSerializer$Prim␣serializeMetada
taDense
WARNUNG:␣Attention:␣Data␣being␣output␣lacks␣metadata.␣Please␣use␣omitmetadata=tr
ue
15.10.2011␣11:08:50␣crosby.binary.osmosis.OsmosisSerializer$Prim␣serializeMetada
taDense
WARNUNG:␣Attention:␣Data␣being␣output␣lacks␣metadata.␣Please␣use␣omitmetadata=tr
ue

Moin!
Das ist ein "false positive" von Osmosis. Diese Warnung ist eher als Hinweis zu verstehen, dass die Metadaten nicht vollständig sind. Die gleiche Meldung kommt auch, wenn du die "originale" .osm-Datei von Geofabrik mit Osmosis umwandelst. Ich vermute, dass sich Osmosis bei anonymen Edits am Fehlen von uid und user stört. Auswirkungen hat das meines Wissens aber nicht, es ist eher ein Hinweis (such mal nach dieser Meldung im Internet).

time und so...

Das time-Kommando gibt es auch unter Windows, es hat aber eine andere Funktion. Trotzdem kann man es verwenden - wenn auch etwas umständlich:

echo␣-␣|␣time␣&␣HIER␣DAS␣KOMMANDO␣&␣echo␣-␣|␣time

Ausgegeben werden dann die Start- und die Ende-Uhrzeit, einschließlich Syntaxfehlermeldungen, die sich anscheinend nicht vermeiden lassen. Aber man kann damit arbeiten. Nun zu den Fehlermeldungen:

osmconvert␣Warning:␣node␣340392673␣user␣string␣index␣overflow:␣1>=0

Das ist ein Folgefehler, weil versucht wurde, eine nicht korrekt geschriebene .pbf-Datei zu lesen. Der Fehler, der beim Schreiben aufgetreten ist, war dieser hier:

osmconvert␣Error:␣PBF␣write:␣string␣table␣memory␣overflow.

Die Tabelle war im Programm zu klein dimensioniert - da bin ich selber Schuld, sorry. Es gibt anscheinend manchmal mehr als 500.000 unterschiedliche (!) Strings in einem 32-MB-Datenblock. Die Grenze hab ich nun auf 1.000.000 erhöht (Version 0.3R).

---

> Euch allen vielen Dank für die Tests und die Geduld !!

viw wrote:

Also der Testvergleich zwischen Osmosis und Osmconvert hat für Sachsen ergeben:
Osmconvert schreibt aus sachsen.osm nach sachsen.pbf in ca. 23 Sekunden
Osmosis braucht für die gleiche Datei 44 Sekunden.

Wow, da sieht man mal, wie langsam mein netbook ist, welches für Mittelfranken (= 0.5*Sachsen)

$␣time␣../osmosis-SNAPSHOT-r26715/bin/osmosis␣--rx␣mittelfranken.osm␣--wb␣mittelfranken.osm.pbf

real␣␣␣␣2m47.813s
user␣␣␣␣2m59.283s
sys␣␣␣␣␣0m3.688s

benötigt. Dafür ist der "gain" bei osmconvert (0.3T, 64 Bit, -O3) größer 😉

$␣time␣osmconvert␣mittelfranken.osm␣--out-pbf␣>␣mittelfranken1.osm.pbf

real␣␣␣␣0m44.321s
user␣␣␣␣0m23.705s
sys␣␣␣␣␣0m2.216s

Wow, bei 23 Sekunden für ganz Sachsen muss die Maschine echt wahnsinnig schnell sein!

Mit Geschwindigkeitstests kann ich grad nicht dienen, denn mein lokaler Rechner hat keinen Platz für die 128 GB europe.osm. Ich verwende deswegen einen Server. Der hat zwar noch viel Platz, aber nebenher laufen 5 Prozesse zum Rendern von Tiles für die openptmap.org, das Testergebnis wäre also nicht verlässlich. Vielleicht mal später am Abend, wenn er mit dem täglichen Rendern durch ist...

Einen Fehler hab ich noch gefunden:
Vorzeichenbehaftete Zahlen werden nur im positiven Bereich korrekt geschrieben, im negativen Bereich entstehen Fehler, wenn der Betrag 2^32 überschreitet.
Was hat das für Auswirkungen? Fast keine. So große Zahlen werden normalerweise nicht verwendet. Aufgefallen ist es mir im Header, denn der Wert für 'minlon' wurde falsch gespeichert. Das PBF-Format verwendet dafür ein Festkommaformat mit dem Faktor 10^-9. Für alles andere wird 10^-7 verwendet, so dass die Koordinaten dann im 32-Bit-Bereich bleiben und keine Fehler entstehen.

Aktuelle Version: 0.3U

Marqqs wrote:

Übersetzen wie üblich mit
cc osmconvert_pbf.c -lz -o osmconvert

Ein Tipp an die Tester:
Wenn die Option -O3 verwendet wird, dann läuft das Programm nachher nochmal ein ganzes Stück schneller.

Also so:
cc osmconvert_pbf.c -O3 -lz -o osmconvert

(ich verwende gcc statt cc)

Marqqs wrote:

Wow, bei 23 Sekunden für ganz Sachsen muss die Maschine echt wahnsinnig schnell sein!

Wahnsinnig schnell? Also mein Gerät ist drei Jahre alt, war damals ein Auslaufmodell und ist schneller. Man darf's halt nicht mit Handy-CPUs vergleichen. ;-)
Allerdings nur schneller mit osmconvert, osmosis ist bei mir langsamer. Also ist mein Gerät vielleicht langsamer, dafür meine Version von osmconvert mittels -O3 besser an meine CPU optimiert?

time␣osmconvert␣sachsen.osm.1␣--out-pbf␣>␣sachsen.osm.pbf.2

real␣␣␣␣0m20.545s
user␣␣␣␣0m18.732s
sys␣␣␣␣0m1.592s

time␣osmosis␣--rx␣sachsen.osm.1␣--wb␣sachsen.osm.pbf.3

real␣␣␣␣1m12.944s
user␣␣␣␣1m17.202s
sys␣␣␣␣0m2.143s

Meine CPU:

cat␣/proc/cpuinfo␣|␣grep␣name

model␣name␣␣␣␣:␣AMD␣Athlon(tm)␣X2␣Dual␣Core␣Processor␣BE-2400

wicking wrote:

Allerdings nur schneller mit osmconvert, osmosis ist bei mir langsamer. Also ist mein Gerät vielleicht langsamer, dafür meine Version von osmconvert mittels -O3 besser an meine CPU optimiert?

Bei den Datenmengen darf man die Platte auch nicht mehr ausser Acht lassen.

VIW hat von Markus hoechstwahrscheinlich "nur" ein 32 Bit-Kompilat ohne "-O3" bekommen fuer
Windows ueber den mingw-compiler.

64 Bit zu 32 Bit macht bei mir 1 Sek. aus und
"-O3" zu unoptimiert 10 Sekunden ( bei 53 Sekunden Grsamtlaufzeit! )

time␣osmconvert␣sachsen.osm.1␣--out-pbf␣>␣sachsen.osm.pbf.2

real␣␣␣␣0m20.545s
user␣␣␣␣0m18.732s
sys␣␣␣␣0m1.592s

Klarer Fall von Spitzenreiter (bislang 😉

Ciao,
Frank

wicking wrote:

(ich verwende gcc statt cc)

Ist unter Linux in der Regel das gleiche resp. ein Link.

Obwohl, LVVM/Clang soll ja im Kommen sein 😉

Doppelpost

kellerma wrote:

VIW hat von Markus hoechstwahrscheinlich "nur" ein 32 Bit-Kompilat ohne "-O3" bekommen fuer
Windows ueber den mingw-compiler.

Ich würde ja auch mal eine selbstübersetzte Version testen. Allerdings scheitert es an zlib.h. Den Mingwcompiler habe ich inzwischen schon geladen.

Hi,
Kleine Unschönheit beim Umwandeln von pbf in osm:
Die erste Zeile wird mit ' , der Rest mit " als Quotezeichen geschrieben.

<?xml␣version='1.0'␣encoding='UTF-8'?>
<osm␣version="0.6"␣generator="osmconvert␣0.3A">
<bounds␣minlat="50.31071"␣minlon="5.512685"␣maxlat="52.5397"␣maxlon="9.468311"/>
<node␣id="145849"␣lat="52.317903"␣lon="7.9574663"␣version="4"

Chris

Ich habe jetzt mal Iran als Testgebiet gewählt. Ist schön klein und enthält „exotische" (für Amerikaner!) Zeichen.

iran.osm.1 wurde mittels osmconvert aus dem Geofabrikextrakt iran.osm.pbf erstellt.

Wandeln zu PBF mit osmconvert:

time␣osmconvert␣iran.osm.1␣--out-pbf␣>␣iran.osm.pbf.2

real␣␣␣␣0m4.457s
user␣␣␣␣0m3.630s
sys␣␣␣␣0m0.775s

Wandeln zu PBF mit osmosis:

time␣osmosis␣--rx␣iran.osm.1␣--wb␣iran.osm.pbf.3

real␣␣␣␣0m21.002s
user␣␣␣␣0m25.081s
sys␣␣␣␣0m1.264s

Größenvergleich der erzeugten Dateien und der Originaldatei von Geofabrik:

9162030␣iran.osm.pbf.2␣←␣osmconvert
9419369␣iran.osm.pbf.3␣←␣osmosis
9421651␣iran.osm.pbf␣␣␣←␣geofabrik

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.

chris66 wrote:

Hi,
Kleine Unschönheit beim Umwandeln von pbf in osm:
Die erste Zeile wird mit ' , der Rest mit " als Quotezeichen geschrieben.

<?xml␣version='1.0'␣encoding='UTF-8'?>
<osm␣version="0.6"␣generator="osmconvert␣0.3A">
<bounds␣minlat="50.31071"␣minlon="5.512685"␣maxlat="52.5397"␣maxlon="9.468311"/>
<node␣id="145849"␣lat="52.317903"␣lon="7.9574663"␣version="4"

Chris

Das macht Osmosis auch. Soll wohl schick sein. :-) Wäre doch langweilig alles gleich.

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.

kellerma wrote:

Bei den Datenmengen darf man die Platte auch nicht mehr ausser Acht lassen.

VIW hat von Markus hoechstwahrscheinlich "nur" ein 32 Bit-Kompilat ohne "-O3" bekommen fuer
Windows ueber den mingw-compiler.

Korrekt! Beides. :-)
Ich wollte mögliche Kompatibilitätsprobleme von vornherein ausschließen. Die, die das Letzte rauskitzeln wollen, werden das Programm sowieso selber übersetzen.

viw wrote:

Ich würde ja auch mal eine selbstübersetzte Version testen. Allerdings scheitert es an zlib.h. Den Mingwcompiler habe ich inzwischen schon geladen.

Genau das Problem hatte ich am Anfang auch. PA94 hat mir mit einem Tipp weitergeholfen:
http://forum.openstreetmap.org/viewtopi … 40#p162140
Das MinGW-Paket, das du dort findest, hat alle möglichen Bibliotheken schon an Bord.

chris66 wrote:

Hi,
Kleine Unschönheit beim Umwandeln von pbf in osm:
Die erste Zeile wird mit ' , der Rest mit " als Quotezeichen geschrieben.

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: '

viw wrote:

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.

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. :-)

Hallo Marqs,
kann osmupdate dann auch eine pbf-Datei aktualisieren?

aighes wrote:

Hallo Marqs,
kann osmupdate dann auch eine pbf-Datei aktualisieren?

Hallo Henning, du kannst Fragen fragen... :-)

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.

Marqqs wrote:

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.

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.

Marqqs wrote:

chris66 wrote:

Hi,
Kleine Unschönheit beim Umwandeln von pbf in osm:
Die erste Zeile wird mit ' , der Rest mit " als Quotezeichen geschrieben.

Du hast Recht, das schaut doof aus, aber praktisch alle anderen Programme machen es genauso.

Sicher? Muss dann aber eine OSM-Eigenheit sein.
Wenn ich mir die xml-Dateien auf meiner Debian-Büchse anschaue, beginnen die meisten mit

<?xml␣version="1.0"␣encoding="UTF-8"?>

Von Redhat kenn' ich's auch so, richtig gezählt hab' ich's nicht 😉

Marqqs wrote:

viw wrote:

Ich würde ja auch mal eine selbstübersetzte Version testen. Allerdings scheitert es an zlib.h. Den Mingwcompiler habe ich inzwischen schon geladen.

Genau das Problem hatte ich am Anfang auch. PA94 hat mir mit einem Tipp weitergeholfen:
http://forum.openstreetmap.org/viewtopi … 40#p162140
Das MinGW-Paket, das du dort findest, hat alle möglichen Bibliotheken schon an Bord.

Der Tipp löst das Problem mit zlib.h sofort. Allerdings kann ich immer noch nicht übersetzen:

C:\Users\username\AppData\Local\Temp\ccugBhh8.s:26852:␣Error:␣invalid␣instruction␣suffix␣for␣`pop'

Die Konsole ist leider so voll mit deartigen Meldungen, dass ich dir nichts näheres dazu sagen kann.

kellerma wrote:

Sicher? Muss dann aber eine OSM-Eigenheit sein.
Wenn ich mir die xml-Dateien auf meiner Debian-Büchse anschaue, beginnen die meisten mit

<?xml␣version="1.0"␣encoding="UTF-8"?>

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 … mestamp.3F
(hochgeladen als Version 0.3W)

Das heißt, ich muss osmupdate das erste mal mit

osmupdate.exe planet.osm.pbf <TimeStamp> --out-pbf planet_new.osm.pbf

aufrufen und ab dem zweiten mal geht es dann ohne den <TimeStamp>?

aighes wrote:

Das heißt, ich muss osmupdate das erste mal mit

osmupdate.exe planet.osm.pbf <TimeStamp> --out-pbf planet_new.osm.pbf

aufrufen und ab dem zweiten mal geht es dann ohne den <TimeStamp>?

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:

osmupdate␣-B=nrw.poly␣nrw_alt.pbf␣nrw_neu.pbf

na, ick bin bejeistert!

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.

Klar das das noch beta ist 😉 Danke für den Hinweis mit dem Polygon, bei mir ist es aber wirklich der gesamte Planet.

Mal schauen, wann ich zum testen komme, ich melde mich dann mit Ergebnissen.

aighes wrote:

Klar das das noch beta ist 😉 Danke für den Hinweis mit dem Polygon, bei mir ist es aber wirklich der gesamte Planet.

Mal schauen, wann ich zum testen komme, ich melde mich dann mit Ergebnissen.

Wär super! Danke schon mal im Voraus. :-)

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.

Kurze Ergänzung:

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.

kellerma wrote:

na, ick bin bejeistert!

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.

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

mkfifo bla{1,2}
für((i=1; i<=1000; i++)); tue
(kopf -n -DM((100*DMi)) | kopf -n 100 > bla1) &
(kopf -n -DM((100*DMi)) | kopf -n 100 > bla2) &
farbdiff bla1 bla2
fertig

edwin-ldbg wrote:

mkfifo bla{1,2}
für((i=1; i<=1000; i++)); tue
(kopf -n -DM((100*DMi)) DATEI1 | kopf -n 100 > bla1) &
(kopf -n -DM((100*DMi)) DATEI2 | kopf -n 100 > bla2) &
farbdiff bla1 bla2
fertig

Wenn, dann richtig. mkfifo ist ja „make first in–first out", folglich „erstelle zuerst rein–zuerst raus", abgekürzt könnte es sein: erznzs.
Und diff steht für „difference". Also „Unterschied", abgekürzt „untd".

Das Ganze mit Euro, denn für DM gibt es ja nicht EIN Zeichen:

erznzs␣bla{1,2}
für((i=1;␣i<=1000;␣i++));␣tue
(kopf␣-n␣-€((100*€i))␣DATEI1␣|␣kopf␣-n␣100␣>␣bla1)␣&
(kopf␣-n␣-€((100*€i))␣DATEI2␣|␣kopf␣-n␣100␣>␣bla2)␣&
farbuntd␣bla1␣bla2
fertig

Super Sache. Warum schreibst Du nicht 'ne eigene Programmiersprache? Eigentlich musst Du nur mal eine komplett übersetzen. Findet sicher Anhänger, alleine weil's so komisch ist.

wicking wrote:

Also etwa so:

mkfifo␣bla{1,2}
for␣((i=1;␣i<=1000;␣i++));␣do
(head␣-n␣-$((100*$i))␣|␣head␣-n␣100␣>␣bla␣1)␣&
(head␣-n␣-$((100*$i))␣|␣head␣-n␣100␣>␣bla2)␣&
colordiff␣bla1␣bla2
done

Interessantes Konzept, da fehlen wohl noch die Dateien, also z. B.

␣(head␣-n␣-$((100*$i))␣iran.oc.osm␣|␣head␣-n␣100␣>␣bla1)␣&
(head␣-n␣-$((100*$i))␣iran.om.osm␣|␣head␣-n␣100␣>␣bla2)␣&

Und damit kommen wir schon zur Kernfrage: Was willst Du denn vergleichen?

Für die aufeindander generierten pbf von osmconvert genügt md5sum, denn wenn sich die hashes unterscheiden,
liegt bereits ein Fehler vor.

Die pbf von osmosis mit den pbf von osmconvert: Hat Markus schon erklärt, dass sie unterschiedlich "gepackt" werden.

Die osm von osmosis mit den osm von osmconvert: Hier zeigen schon die ersten 4 Zeilen, dass die unterschiedlich sind:
a) osmconvert hat einen anderen "generator="String
b) osmconvert benutzt Tabs statt zweier Leerzeichen beim osmosis
c) Die Abfolge der key/values innerhalb der node/way/relation ist unterschiedlich
=> Alle Zeilen (außer der ersten) sind unterschiedlich.

Du muesstest erst die Inhalte normalisieren und kann (color)diff nicht leisten.

kellerma wrote:

Interessantes Konzept, da fehlen wohl noch die Dateien, also z. B.

(head␣-n␣-$((100*$i))␣iran.oc.osm␣|␣head␣-n␣100␣>␣bla1)␣&
(head␣-n␣-$((100*$i))␣iran.om.osm␣|␣head␣-n␣100␣>␣bla2)␣&

Ja, die habe ich vergessen.

Und damit kommen wir schon zur Kernfrage: Was willst Du denn vergleichen?
=> Alle Zeilen (außer der ersten) sind unterschiedlich.
Du muesstest erst die Inhalte normalisieren und kann (color)diff nicht leisten.

Genau. Ich will die OSM-Dateien vergleichen, um fehlende oder falsch übersetzte Elemente zu finden. Dazu muss man sie normalisieren, was mit sed (oder perl) ganz fix geht. Ergebnisse folgen.

Meine Programmiersprache nenne ich E+³ 4D

Genau. Ich will die OSM-Dateien vergleichen,

Hast keinen Drucker?

Edwin, denk doch an die armen Bäume...

Weiter geht's mit der Analyse.

Da ich die Binärdaten nicht lesen kann (war zu kurz in der Matrix, oder so) nur die OSM-Dateien.

Die OSM-Dateien aus Osmosis verwenden Tabs (= 1 Byte) zur Einrückung. Die aus osmconvert je zwei Leerzeichen (= 2 Byte) statt einem Tab. Somit könnten die OSM-Dateien aus osmconvert größer sein, sind sie aber nicht.

Außerdem stehen bei Osmosis die Angaben für lat=… lon=… ganz am Ende, bei osmconvert ganz am Anfang nach der id. Bei osmosis ist die Reihenfolge uid, user, changeset, bei osmconvert aber changeset, uid, user.

Dann gibt's auch noch ein paar wenige Sonderzeichen, die osmosis als benannte Entitäten (z.B. &quot;) ausgibt, osmconvert aber als dezimale Entitäten (z.B. &#34;).

Seltsamerweise gibt osmconvert im Gegensatz zu osmosis natürliche Zahlen mit einem abschließenden Punkt an. So:
„34."
statt nur
„34"

Das alles kann man rausfiltern bzw. umstellen, die Dateien also „normieren". Dann sind sich die Dateien schon viel ähnlicher und eher vergleichbar. Habe das mit sed gemacht.

for␣i␣in␣iran.osm.{1,2,3,4};␣do
sed␣-i␣-e␣'s%\␣\␣%%g'␣-e␣'s%\t%%g'␣-e␣'s%\␣uid="0"\␣user=""%%'␣-e␣'s%\(.*\␣\)\(id="[0-9]\+"\)\(.*\)\(\␣lat="[0-9\.]\+"\␣lon="[0-9\.]\+"\)\(.*\)%\1\2\4\3\5%'␣-e␣'s%\(.*\␣id="[0-9\.]\+"\)\(.*\)\(\␣changeset="[0-9]\+"\)\(.*\)%\1\3\2\4%'␣-e␣'s%\&%\&%g'␣-e␣'s%\'%\'%g'␣-e␣'s%\"%\"%g'␣-e␣'s%\>%\>%g'␣-e␣'s%\<%\<%g'␣-e␣'s%\
%\
%g'␣-e␣'s%\
%\
%g'␣-e␣'s%\(.*l[ao][tn]="[0-9]\+\)\(\."\)\(.*\)%\1"\3%g'␣$i
done

Dabei ist mir aufgefallen, das ziemlich häufig CarriageReturn und LineFeed in Werten vorkommt. Schrecklich! Das muss wohl versehentlich (copy&paste) passiert sein, sollte aber mal durch einen Bot behoben werden. Da verschluckt sich doch sicher so manches Programm dran. Naja, kann man auch einfach als Leerzeichen interpretieren, und wenn's ein Bot repariert, sind die Fehler sicher bald eh wieder irgendwo drin.

Als Ergebnis erhalte ich, dass alle vier Dateien iran.osm.{1,2,3,4} bis auf die Zeilen 2 und 3 identisch sind. In Zeile 2 steht der Name des erstellenden Programms, in Zeile 3 stehen die Außenränder („bounding box"), welche Unterschiedlich angegeben sind.

Jetzt gilt es andere Bereiche oder gleich die ganze Welt zu vergleichen. Und dann noch Boundingboxes, Boundingpolygone und andere komplexe Dinge zu vergleichen. Dies könnte das osmconvert ebenfalls aus dem Tritt bringen.

wicking wrote:

Die OSM-Dateien aus Osmosis verwenden Tabs (= 1 Byte) zur Einrückung. Die aus osmconvert je zwei Leerzeichen (= 2 Byte) statt einem Tab. Somit könnten die OSM-Dateien aus osmconvert größer sein, sind sie aber nicht.

Nö, es ist genau umgekehrt:
osm-Dateien - von osmconvert generiert - benutzen zur Einrückung je einen Tabstop,
osm-Dateien - von osmosis - hingegen 2 spaces pro Einrückungstiefe
=> (hauptsächlich) deshalb sind die osm@osmosis-Dateien auch größer.

Der Datenvergleich geht auch Quick 'n' Dirty:
osm2pgsql -s iran.osmconvert.osm
pg_dump gis > iran.osmconvert.osm.sql
osm2pgsql -s iran.osmosis.osm
pg_dump gis > iran.om.osmosis.sql
md5sum *.sql

Ciao,
Frank

kellerma wrote:

Nö, es ist genau umgekehrt:
osm-Dateien - von osmconvert generiert - benutzen zur Einrückung je einen Tabstop,
osm-Dateien - von osmosis - hingegen 2 spaces pro Einrückungstiefe
=> (hauptsächlich) deshalb sind die osm@osmosis-Dateien auch größer.

Stimmt. Das war mit ein Grund, warum ich bei der Tab-Variante geblieben bin.

Hat einer von euch mal die osmconvert-Option --emulate-osmosis probiert? Zwar ist die nicht perfekt, aber die dann noch notwendigen Nacharbeiten wären sicher viel einfacher.

So...osmupdate ist gerade durchgelaufen:

Fallstrick: PATH-Variable brauchte einen Eintrag für osmconvert wurde übersprungen 😉

Das Verhalten von viw kann ich bestätigen. Ein Kern ist voll ausgelastet, HDD und RAM hätten noch Platz. Da die Reihenfolge der Objekte an sich ja egal ist, könnte man mehrere Threads machen, die nach einander ein Objekt einlesen und an einem Schreibe-Thread übergeben. Evtl. könnte man das packen der Blöcke auch in einen Thread auslagern.

Ein planet-update-race mach ich dann, mal später.

Noch eine Anmerkung zu osmupdate: Wäre es möglich den Update-Server einzustellen?

Noch eine Anmerkung zur Ausgabe der Timestamps: Ich fände es recht sinnvoll, die Zeit in der lokalen Zeit zu haben, weiß aber nicht ob sich das plattformübergreifend lösen lässt. Ansonsten evtl. der Hinweis, dass es UTC ist.

Ich hab mir MinGW von nuwen geholt, damit hat das -o3 leider nicht geklappt. Hat jemand eine Idee, woran das liegen könnte?

aighes wrote:

Noch eine Anmerkung zur Ausgabe der Timestamps: Ich fände es recht sinnvoll, die Zeit in der lokalen Zeit zu haben, weiß aber nicht ob sich das plattformübergreifend lösen lässt. Ansonsten evtl. der Hinweis, dass es UTC ist.

Steht doch dabei 😉
osmupdate: timestamp of Nürnberg.osm: 2011-10-07T19:29:52Z

Z steht für Zulu was UTC ist.

aighes wrote:

Ich hab mir MinGW von nuwen geholt, damit hat das -o3 leider nicht geklappt. Hat jemand eine Idee, woran das liegen könnte?

Klar. Klarer Fall von falschem OS 😉
Mit Linux wäre Dir das nicht passiert, da könntest Du -O7 sogar nehmen 🙂

Ciao,
Frank

PS
"-O7" bringt ober nix

Tatsache....das Z hatte ich übersehen...

Gibts denn etwas alternatives für Windows?

Mittlerweile haben sich splitter und mkgmap durch die Daten gewuselt. Leider mit sehr mäßigem Erfolg. Das was aus dem Splitter kommt ist deutlich zu klein, er lief aber ohne Fehlermeldung durch. dementsprechend fehlen in der Karte dann auch sehr viele Objekte.

Hallo Henning,

hast Du es für splitter & mkgmap mal mit der Option "--emulate-osmosis" probiert?
(Hab' die proggies selbst nicht und kann sie deshalb auch nicht testen)

Das osm2pgsql hat jedenfalls anstandlos alles geschluckt.

Ciao,
Frank

EDIT:
Der "--emulate-osmosis" hat noch seine Tücken:
$ diff Nürnberg.osmosis.osm Nürnberg.osmconvert-emulate-osmosis.osm
3d2
< <bound box="0.00000,0.00000,0.00000,0.00000" origin="0.39"/>
1308487c1308486
< <member type="node" ref="31165489" role="location_hint &#x9;"/>

---

<member type="node" ref="31165489" role="location_hint &#9;"/>

1353401a1353401

<!--End of emulated output.-->

aighes wrote:

Noch eine Anmerkung zu osmupdate: Wäre es möglich den Update-Server einzustellen?

Kennst du einen Mirror, der genauso aktuell ist wie der originale Server? Einbauen könnte man das sicherlich.

aighes wrote:

Ich hab mir MinGW von nuwen geholt, damit hat das -o3 leider nicht geklappt. Hat jemand eine Idee, woran das liegen könnte?

Fast alle Linux-lastigen Programme unterscheiden zwischen Groß- und Kleinbuchstaben. Probierst bitte mal mit -O3

gwdg ist nur ein paar Stunden hinterher....das würde mir schon reichen von.

Ich hab mit O3 und o3 probiert...

kellerma wrote:

< <member type="node" ref="31165489" role="location_hint &#x9;"/>

<member type="node" ref="31165489" role="location_hint &#9;"/>

Oh, &#x9; und &#9; ist jedenfalls was ganz unterschiedliches. Das ist ja ein echt schwerer Fehler. Also entweder diese Emulationsvariante ganz entfernen, oder richtig machen. :-)

Oh, keine Sorge, ich hab' noch mehr:

< <bound box="48.83289,9.90665,49.78804,11.60161" origin="http://www.openstreetmap.org/api/0.6"/>

---

<bounds minlat="48.83289" minlon="9.906651" maxlat="49.78804" maxlon="11.60161"/>

< <node id="581196" version="1" timestamp="2006-02-24T18:14:32Z" uid="0" user="" changeset="2537" lat="49.56439" lon="10.948005"/>

---

<node id="581196" version="1" timestamp="2006-02-24T18:14:32Z" changeset="2537" lat="49.56439" lon="10.948005"/>

< <node id="433389442" version="2" timestamp="2009-07-06T21:55:45Z" uid="23040" user="trompeter" changeset="1757191" lat="49.6405149" lon="11"/>

---

<node id="433389442" version="2" timestamp="2009-07-06T21:55:45Z" uid="23040" user="trompeter" changeset="1757191" lat="49.6405149" lon="11."/>

< <tag k="source" v="Bing"/>

---

<tag k="source" v="&#127;Bing"/>

aighes wrote:

gwdg ist nur ein paar Stunden hinterher....das würde mir schon reichen von.

Gib mir bitte mal den Link, ich find ihn nicht mehr. :-(

Der schlimmste Fehler ist, dass diese OSM Dateien alle in Englisch sind.

[link:ftp://ftp5.gwdg.de/pub/misc/openstreetmap/planet.openstreetmap.org/ ftp://ftp5.gwdg.de/pub/misc/openstreetm … etmap.org/]

Hi,

ich schneide Nürnberg aus Mittelfranken aus, einmal "direkt":
$ osmconvert -B=polygon.62780.poly mittelfranken.osm.pbf > Nürnberg.osm
und einmal "via pbf":
$ osmconvert -B=polygon.62780.poly mittelfranken.osm.pbf --out-pbf > Nürnberg.pbf
$ osmconvert Nürnberg.pbf > Nürnberg.pbf.osm

Scheinbar bleiben aber bei der "pbf-Varianet" die BBOX von Mittelfranken erhalten:
$ diff Nürnberg.pbf.osm Nürnberg.osm
3c3
< <bounds minlat="48.83289" minlon="9.906651" maxlat="49.78804" maxlon="11.60161"/>
---
> <bounds minlat="49.33142" minlon="10.98824" maxlat="49.5418" maxlon="11.28253"/>

Ciao,
Frank

aighes wrote:

[link:ftp://ftp5.gwdg.de/pub/misc/openstreetmap/planet.openstreetmap.org/ ftp://ftp5.gwdg.de/pub/misc/openstreetm … etmap.org/]

Danke! Mit osmupdate Version 0.2A nun erledigt. Die Option heißt "--planet-url=" und ist im Hilfetext beschrieben. Mit "--planet-url=mirror" kriegst du den gwdg.de-Mirror.
Leider ist der nur eingeschränkt zu empfehlen. Ich weiß nicht, wann dort der Updateprozess läuft, die Sync-Reihenfolge der einzelnen Dateien ist jedenfalls ungünstig. Beispiel:

[link:ftp://ftp5.gwdg.de/pub/misc/openstreetmap/planet.openstreetmap.org/hour-replicate/state.txt ftp://ftp5.gwdg.de/pub/misc/openstreetm … /state.txt]

Dort steht, dass das die neueste hourly-Datei die Sequenz-Nummer 16731 hat. Diese Datei wird von osmupdate aber nicht gefunden, weil sie nicht existiert. Die tatsächlich vorhandene neueste Datei hat die Nummer 16730.

kellerma wrote:

Hi,

ich schneide Nürnberg aus Mittelfranken aus, einmal "direkt":
$ osmconvert -B=polygon.62780.poly mittelfranken.osm.pbf > Nürnberg.osm
und einmal "via pbf":
$ osmconvert -B=polygon.62780.poly mittelfranken.osm.pbf --out-pbf > Nürnberg.pbf
$ osmconvert Nürnberg.pbf > Nürnberg.pbf.osm

Scheinbar bleiben aber bei der "pbf-Varianet" die BBOX von Mittelfranken erhalten:
$ diff Nürnberg.pbf.osm Nürnberg.osm
3c3
< <bounds minlat="48.83289" minlon="9.906651" maxlat="49.78804" maxlon="11.60161"/>
---
> <bounds minlat="49.33142" minlon="10.98824" maxlat="49.5418" maxlon="11.28253"/>

Ciao,
Frank

Wow, was dir alles auffällt. Danke! Das hatte ich echt übersehen. Gefixt mit Version 0.4A, grad hochgeladen.

Hallo,

Ich konnte jetzt nichts genaues finden im Thread hier ...

Wie sind bisher die Testergebnisse zum pbf Format ?

Bei mir funktioniert es nicht. Ich verwende allerdings nicht osm2pgsql sondern imposm zum Einlesen der pbf Datei in die DB.

osm2pgsql liest die mit osmconvert erstellte pbf Datei, imposm allerdings nicht.

Wenn ich die mit osmconvert erstellte pbf Datei wieder mit osmosis konvertiere mit

osmosis --rb test.pbf --wb test-neu.pbf

dann kann imposm die Datei lesen.

Beim Konvertieren ist dann die osmosis pbf Datei etwas größer als die osmconvert pbf Datei.

Update: ich kenne mich leider mit dem pbf Format nicht so aus, es scheint aber mit der granularity zu tun zu haben.
osmosis schreibt wohl einen default Wert von 100 in die pbf Datei und dieses Wert sucht imposm dann.

Bei der osmconvert pbf Datei scheint imposm diesen granularity Wert nicht zu finden.

misterboo wrote:

Wie sind bisher die Testergebnisse zum pbf Format ?

Bei mir funktioniert es nicht. Ich verwende allerdings nicht osm2pgsql sondern imposm zum Einlesen der pbf Datei in die DB.

osm2pgsql liest die mit osmconvert erstellte pbf Datei, imposm allerdings nicht.

Hallo!

Bis jetzt gibt es noch nicht viele Feldversuche mit den von osmconvert erzeugten .pbf-Dateien. Nach allem, was ich bisher sagen kann, entsprechen die .pbf-Dateien aber genau dem Standard, der auf der OSM-Wiki-Seite https://wiki.openstreetmap.org/wiki/PBF definiert ist. Das heißt, ich würde einen Fehler in der Importschnittstelle von Imposm nicht ausschließen. Ebenso wenig kann ich natürlich einen Fehler in osmconvert ausschließen. :-)

Welche Fehlermeldung gibt denn Imposm aus?

ich habe mein Post gerade upgedatet, kannst du damit was anfangen (granularity Wert)

misterboo wrote:

Update: ich kenne mich leider mit dem pbf Format nicht so aus, es scheint aber mit der granularity zu tun zu haben.
osmosis schreibt wohl einen default Wert von 100 in die pbf Datei und dieses Wert sucht imposm dann.

Bei der osmconvert pbf Datei scheint imposm diesen granularity Wert nicht zu finden.

Das ist richtig, osmconvert schreibt diesen Wert nicht. Es handelt sich um einen DEFAULT-Wert, Imposm sollte sich also nicht darauf verlassen, dass der optionale Wert auch in der Datei enthalten ist. Aus der PBF-Formatdefinition:

␣//␣Granularity,␣units␣of␣nanodegrees,␣used␣to␣store␣coordinates␣in␣this␣block
optional␣int32␣granularity␣=␣17␣[default=100];

Hast du Kontakt zu den Imposm-Entwicklern? Der Fehler ist sicher relativ leicht zu beheben.

Marqqs wrote:

misterboo wrote:

Update: ich kenne mich leider mit dem pbf Format nicht so aus, es scheint aber mit der granularity zu tun zu haben.
osmosis schreibt wohl einen default Wert von 100 in die pbf Datei und dieses Wert sucht imposm dann.

Bei der osmconvert pbf Datei scheint imposm diesen granularity Wert nicht zu finden.

Das ist richtig, osmconvert schreibt diesen Wert nicht. Es handelt sich um einen DEFAULT-Wert, Imposm sollte sich also nicht darauf verlassen, dass der optionale Wert auch in der Datei enthalten ist. Aus der PBF-Formatdefinition:

␣//␣Granularity,␣units␣of␣nanodegrees,␣used␣to␣store␣coordinates␣in␣this␣block
optional␣int32␣granularity␣=␣17␣[default=100];

Hast du Kontakt zu den Imposm-Entwicklern? Der Fehler ist sicher relativ leicht zu beheben.

Nein ... ich werde aber mal einen Bug Report erstellen auf der imposm Seite

Den Fehler behoben habe ich schon in imposm, indem ich einfach die betreffende Abfrage nach dem granularity Wert geändert habe und nun der default Wert von 100 genommen wird falls kein anderer Wert in der pbf Datei angegeben ist.

misterboo wrote:

ich habe mein Post gerade upgedatet

Sag doch einfach „aktualisiert", „angepasst", „ergänzt", „verbessert"

Es gibt so viele bessere Worte als Dein schreckliches Denglisch.