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.
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.
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
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.
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 !!
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
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)
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
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! )
Klarer Fall von Spitzenreiter (bislang
Ciao,
Frank
Ist unter Linux in der Regel das gleiche resp. ein Link.
Obwohl, LVVM/Clang soll ja im Kommen sein
Doppelpost
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