mit nem gescheiden Rechner, gleiches Set-Up wie oben:
Osmosis: 00:13:40
Pbftoosm: 00:04:13
VG
Sockeye
Danke fürs mitstoppen! 
Bei dieser Gelegenheit:
Die Version 0.4 von pbftoosm hat einen Bug. Wicking hat ihn in echter Kleinarbeit umzingelt (danke!), und ich hab ihn erlegt. Neu als Source gibt es nun die Version 0.5, die Binaries sind noch nicht upgedated.
Der Fehler ist allerdings in den meisten Fällen ohne Bedeutung. Zum Hintergrund:
Alle OSM-Objekte enthalten standardmäßig die History-Information: version, timestamp, changeset, uid, user.
Nun gab es in der Anfangszeit des OSM auch anonyme Edits. Dann entfallen die letzten beiden Elemente. Es bleiben: version, timestamp, changeset.
Die alte Version von pbftoosm kommt bei Relationen (nur bei Relationen) mit anonymen Edits nicht ganz klar und lässt version, timestamp und changeset dann ganz weg, wenn uid fehlt. Der Rest der jeweiligen Relation ist jedoch korrekt. Einige Programme stört das Weglassen dieser Infos nicht, manch andere melden einen Fehler.
Neues Programm osmconvert:
Ganz neu und bisher kaum getestet ist das Programm osmconvert. Es kann das Gleiche wie osmtopbf, ist jedoch ein kleines bisschen langsamer. 
Dafür können damit Changefiles verarbeitet werden. Das Programm unterscheidet sich in dieser Hinsicht nicht viel von dem einigermaßen bekannten osmchange, versteht aber zusätzlich die Formate .pbf und .o5m.
Kann osmconvert auch pbf+osc => pbf?
Ich seh gerade im wiki, dass er pbf nur lesen kann. Wäre cool, wenn er es auch schreiben könnte.
Stimmt, wär gut. Allerdings steckt recht viel Aufwand drin, einen Coder dafür zu programmieren, wenn man nicht die fertigen (und leider langsamen) Bibliotheken verwenden will.
Aber für welchen Zweck? Sowas wie hier?
http://wiki.openstreetmap.org/wiki/Daily_update_an_OSM_XML_file
Da wär das .o5m-Format letztlich eh besser geeignet als das PBF-Format.
Der Zweck wäre das updaten eines pbf-Planet. Die Ausgabe müsste pbf sein, da der splitter.jar (neben dem xml) nur pbf liest.
OK, klingt logisch. Allerdings wärs da einfacher, dem Splitter .o5m beizubringen als dem osmconvert das .pbf-Schreiben. Mal schauen, wozu ich noch komme. Hoffentlich krieg ich das mit dem Filter bald auf dir Reihe.
war nur ein Benchmark um meinen neuen i7 2600k @4,8GHZ zu testen…
…wenn wir schon bei einen Wunschkozert sind…
- .pbf Ausgabeformat wäre SUPER
- das Ausschneiden mehrerer Boxen (analog der Osmosis --tee x Funktion)
- Multi-threading wäre das Sahnehäubchen. (bei meiner Konfig oben, war das Filesystem mit 90 MB/Sec nicht ausgelastet und die 7 restlichen Kerne gelangweilt.)
Bitte nicht falsch verstehen. Mit PbfToOsm ersparst du mir schon jetzt mehrere Stunden Zeit. Vielen Dank nochmal!
VG
Sockeye
Aber klar, wünschen darf jeder.
Ich hängs gern rein, wenn jemand das betreffende Code-Stück in C schreibt. Der Encoder ist leider einiges aufwändiger als der Decoder. Bis dahin bleibt nur, .o5m zu verwenden oder das Tool osm2pbf, um – leider über den .osm-Umweg – eine PBF-Datei zu erzeugen. Oder man nimmt gleich Osmosis.
Geht doch jetzt schon:
./pbftoosm -i=europe.pbf -B=germany.poly >germany.osm & ./pbftoosm -i=europe.pbf -B=austria.poly >austria.osm
OK, nicht direkt das, was du wolltest, aber wahrscheinlich trotzdem recht flott, weil in diesem Fall ja parallele Prozesse laufen.
Siehe oben.
Aber du hast schon Recht, einen Teil des Algorithmus könnte man parallelisieren. Natürlich nicht alles, weil beim Ausschneiden von Extrakten vieles aufeinander aufbaut.
Hallo Marqqs,
Und nun sagt mir mein Bauch: Ich habe die Wette gewonnen, Du schuldest mir ein Bier …
Ich nehme ein dunkles Weizen…
Prost
PA94
Können wir gerne machen. Wo?
Mit deiner Anleitung hab ich es übrigens geschafft, MinGW unter Wine zu installieren. Dort läuft die Compilierung durch, es gibt kein Gemecker wegen fehlender Bibliotheken. Ein Anfangsproblem hatte ich noch, denn das Exe lief unter Windows nicht korrekt, unter Wine schon. Und zwar unabhängig davon, ob ich es unter Wine oder unter echtem Windows übersetzt hab. Das Problem ist aber dank Mithilfe von fx99 gelöst.
Die neue Exe (Version 0.9) ist auch über die Wiki-Seite verlinkt:
http://wiki.openstreetmap.org/wiki/DE:Pbftoosm
Hi,
ich hab jetzt mal aus dem fred von Tippeltappel folgendes beispiel laufen lassen unter WinXP:
pbftoosm.exe -h=1000 < D:\Karten\osm\Geofabrik\Duesseldorf.osm.pbf -b=6.75,51.45,6.85,51.5 --drop-brokenrefs > bbox.osm
Durchlaufen tuts, und das Ergebnis ist so klein, dass es in josm gut reinpasst.
Dabei gibt es dann jede Menge Relationen mit 0 Elementen. Eben jene, deren Mitglieder ausserhalb der bb liegen.
Ist das ein bug oder ein Feature?
Eventuell hängt sich dann der Map Composer von nop oder mkgmap daran auf.
Gruß,
ajoessen
Hallo ajoessen,
das ist weder Bug noch Feature, sondern ein technischer Nachteil wenn man weder Tempfiles noch Direktzugriff erlaubt. Weder Osmosis noch pbftoosm können zaubern. Das, was Osmosis mit Tempfiles erledigt, macht pbftoosm, indem es einen Teil der Eingabedatei mehrfach liest. Das geht aber nicht, wenn man sie über die Standardeingabe in das Programm reinschiebt, sondern man muss Direktzugriff auf eine vorhandene Datei erlauben. Siehe hier, im letzten Absatz des Kapitels:
http://wiki.openstreetmap.org/wiki/DE:Pbftoosm#Anwenden_von_geografischen_Grenzen
Dein Kommando könnte dann so aussehen:
pbftoosm.exe -i=D:\Karten\osm\Geofabrik\Duesseldorf.osm.pbf -b=6.75,51.45,6.85,51.5 --drop-brokenrefs > bbox.osm
Eine Weiterentwicklung des Programms pbftoosm, das recht neue osmconvert, verwendet statt des Direktzugriffs auch wieder temporäre Dateien. Ganz ohne technische Einschränkungen gehts also nicht - außer, man reserviert sich Unmengen an Hauptspeicher.
Da fällt mir auf, ich hab noch gar nicht geschaut, was pbftoosm genau braucht. Werd ich gleich mal machen.
Hallo zusammen
Nun trau ich mich doch mal hier herein.
Mit folgender Kommandozeile habe ich einen neuen Testlauf gemacht:
pbftoosm.exe -i=germany.osm.pbf -b=6.4,6.6,50.5,50.7 --drop-brokenrefs >Wolfgarten.osm
Der mit pbftoosm erzeugte planet-Ausschnitt wurde jetzt so verarbeitet, daß auch mkgmap am Ende Kartendateien erzeugen konnte.
Vordergründig sieht es so aus, als ob die Idee, vereinfachte Koordinaten einzugeben, zum Erfolg geführt hätte.
Da es sich aber um einen völlig anderen Kartenausschnitt handelt, kann es natürlich auch an etwas ganz anderem liegen.
Auch mit der Ergänzung --drop-history erzeugte Composer Kartendaten, aus denen mkgmap anschließend fehlerfrei eine Karte erzeugte.
Irritierend sind allerdings die Dateigrößen und die Berechnungsdauer.
Aus Niedersachsen.osm.pbf mit 85.107 KB errechnete pbftoosm Niedersachsen.osm mit 1.424.938 KB
Die aus germany.osm.pbf gezogenen Ausschnitte ergaben:
- Essen 830.932 KB (unbrauchbar)
- Wolfgarten.osm 7.654.591 KB (Composer und mkgmap fehlerfrei)
- Wolfgarten-h.osm 3.962.200 KB (ohne history - funktioniert ebenfalls - Berechnungsdauer 60 Minuten)
- Meine verschiedenen Wunschgebiete zu einer tippeltappel-polybox kombiniert und von jemanden, der es kann, vermutlich mit OSMOSIS aus dem Europafile ausgeschnitten, ist nur 4.922.895 KB groß (Berechnung mit Composer und mkgmap ca 50 Minuten - dabei sehr merkwürdig: Composer meldet einen mkgmap-Fehler, jedoch finde ich im Windows-Explorer Kartendaten, die sich mit MapsetToolkit problemlos installieren lassen und in MapSource angezeigt werden.
Obwohl das Gebiet von Wolfgarten nur einen winzigen Bruchteil von tippeltappel.osm darstellt, ist die Datei mit --drop-history nur etwa 1/5 kleiner.
Noch krasser: Der winzige Wolfgarten-Ausschnitt ist ca 5 mal so groß wie die Datei von ganz Niedersachsen.
Ich finde das alles sehr merkwürdig. Hinter die Kulissen gucken kann ich nicht. Das müßt Ihr machen.
Ich kann nur berichten, was mir auffällt.
Viele Grüße
tippeltappel
Hallo und Willkommen hier drüben.
Der Faktor 85 MB zu 1,4 GB ist für .pbf/.osm realistisch.
7,6 GB für eine einzelne Gemeinde? Da stimmt etwas nicht. Sicher, dass du dich nicht um den Faktor 1000 verschaut hast?
Falls das wirklich korrekt ist, tippe ich auf ein defektes Polygon. Von der Größe der Datei her ist fast halb Deutschland mit eingeschlossen.
Magst du mir die Polygon-Datei mal schicken? Ich werds dann parallel hier probieren.
EDIT: Ich seh grad, du hast kein Polygon verwendet, sondern eine Box. Ich probiers aus.
HALT, ich seh grad, du hast die Koordinaten vertauscht. Zuerst die südwestliche Ecke, dann die nordöstliche, also:
pbftoosm.exe -i=germany.osm.pbf -b=6.4,50.5,6.6,50.7 --drop-brokenrefs >Wolfgarten.osm
Sonst schließt du halb Europa mit ein, kein Wunder, dass die Datei dann groß wird.
@Marqqs
Wenn ich mit ‘-wall -ansi -pedantic’ bzw. ‘-c99’ kompiliere, bekomme ich noch errors/warnings in der 0.9er.
Bekommst Du die noch weg, so dass sie immer noch fuer Linux und win laeuft?
Danke.
Ciao,
Frank
Aaaah! Ich hatte mich schon selbst über die Reihenfolge der Koordinaten gewundert.
Die hatte ich von irgendwo (wo war das jetzt?) übernommen.
Somit dachte ich, das müsse so sein.
Ok, dann stelle ich das mal um.
Danke
tippeltappel
EDIT
Das war’s!
Die Reihenfolge der Koordinaten hatte ich mit der Reihenfolge in der von ajoessen abgeschriebenen osmosis-Befehlskette verwechselt. Da werden die Koordinaten allerdings durch right= left= bottom= top= eindeutig gemacht.
Das Ausschneiden dauerte 1-2 Minuten,
die anschließende Verarbeitung mit Composer etwa 1 Minute.
Alles läuft sauber ohne Fehlermeldung durch.
Die Karte funktioniert in Mapsource.
Die Koordinateneingabe für Essen war Gestern richtig.
Allerdings hatte ich dort teilweise mehr als eine Nachkommastelle eingegeben.
Also Koordinaten auf 1 Nachkommastelle reduziert … > mkgmap failed
???
Mit -Wall übersetze ich sowieso. Dafür hab ich schon extra den Code an einigen Stellen geändert, damit bestimmte Warnungen nicht erscheinen. - Obwohl der Code vorher völlig korrekt war! Mit -pedantic probier ich es lieber gar nicht. Ich mappe nicht für Renderer und ich programmiere nicht für “pedantische” Compiler.
Trotzdem, wenn du wirkliche Fehler oder Stellen entdeckst, die nicht gemäß C99-Standard sind, interessiert mich das natürlich! Immer her damit.
Freut mich!
Das mit Essen versteh ich allerdings auch nicht. 
@Marqqs
Weitere Testkoordinaten, die funktionierten:
Siegerland: 7.4,50.5,8.2,51.2 --drop-brokenrefs
Diese dagegen funktionierten nicht: (Erweiterung um Essen)
Ruhrgebiet: 6.5,51.1,7.7,51.8 --drop-brokenrefs
Ich werde mir gleich mal ein neues germany.osm.pbf ziehen und weitere Gebiete testen.
@ Marqqs
Was bedeutet das?
Fehlermeldung von pbftoosm:
Reaktion von Composer:
Gruß
tippeltappel