osmconvert sachsen.osm.pbf -b=13.2,50.5,14.7,51.5 --drop-broken-refs > test.osm
o5mfilter test.osm --keep="route=bus" >oepnv.osm
del osmconvert_tempfile.1
del osmconvert_tempfile.0
del o5mfilter_tempfile.0
Die Löschversuche der drei Datein schlagen fehl. Zugriff verweigert.
Interessant ist auch, dass wenn diese Dateien nicht gelöscht werden beim nächsten Aufruf der mangelnde Zugriff auf osmconvert_tempfile.1 bzw. o5mfilter_tempfile.0 festgestellt wird und die Programme dann abgebrochen werden.
Diese Dateien lassen sich aber im Explorer problemlos löschen. Sie haben lediglich eine Besonderheit. Das Attribut “Schreibgeschützt” ist gesetzt. Entfernt man dieses, können beide Programme auch problemlos mit bereits existierenden Dateien umgehen.
Dies kann man mit folgendem Code erreichen:
Die erste Zeile wird rasend schnell abgearbeitet. Die resultierende o5m Datei ist auch nur noch ein Zehntel so groß wie die osm Datei.
Doch o5mfilter verweigert die Arbeit. “o5mfilter Error: no .o5m reset tag befor first relation”
Das die Datei test.o5m nicht ernsthaft beschädigt ist, kann man herausfinden, wenn man diese dann wieder mit osmconvert in osm zurückverwandelt. Das lässt zwar das Datenvolumen um 30-40 MB größer werden gegenüber dem ursprünglichen Ergebniss, aber dann meckert o5mfilter nicht mehr.
also unter Linux (Debian 64Bit) hab’ ich mit beiden Programme bisher keine Probleme gehabt.
Und ja, o5m geht viel schneller zum filtern
Hast Du “sachsen.osm.pbf” von der Geofabrik? Könntest Du noch sagen von wann und vielleicht auch die md5sum?
Sachsen von heute von der Geofabrik
4F96482F7B0BAE5058DBC1DF897840C6 sachsen.osm.pbf
Der Stand ist jedoch bei der Geofabrik etwas älter. Die Änderungen von gestern sind leider nicht enthalten gewesen.
Wie gesagt wenn man pbf in osm wandelt mit OSM Convert und dann osm filtert kein Problem.
Wenn man aber in o5m wandelt scheitert das Filtern.
Wenn man in o5m schneidet und dann in osm wandelt wird die Datei 30 MB größer läßt sich dann aber wieder problemlos filtern.
Stimmt, das war echt ein bescheuerter Fehler. Manchmal sieht man den Wald vor lauter Bäumen nicht, sorry.
osmconvert 0.0P und o5mfilter 0.0M sollten nun sauber sein.
du warst einfach zu langsam. Ich habe jetzt nochmals den Download angeworfen und siehe da die MD5 stimmen überein. Und auch die Änderungen sind jetzt enthalten. War also nur zu früh heute morgen.
Ich hab grad sachsen.osm.pbf runtergeladen und genau den Fall nachgestellt. der Fehler zeigt sich auch bei mir (Linux, 32 bit), und das ist gut so! Mit anderen Dateien ist mir das nämlich noch nicht passiert.
Werde mir das heute Abend auf alle Fälle genauer anschauen.
Danke! Sehr gute Analyse. Ich könnte jetzt ergänzen:
funktioniert nach dieser Kombination:
osmconvert sachsen.osm.pbf -b=13.2,50.5,14.7,51.5 --drop-broken-refs --out-o5m > test_temp.o5m
osmconvert test_temp.o5m --out-o5m > test.o5m
Das war dann auch das Entscheidende dran. Es hat immer dann funktioniert, wenn mit osmconvert keine komplexen Umwandlungen durchgeführt wurden, wenn also keine temporäre Datei geschrieben werden musste. Denn beim Umschalten der Ausgabe in die temporäre Datei und wieder zurück ging das Reset-Byte verloren.
Sollte in Version 0.0R nicht mehr passieren. Jedenfalls lief es bei mir grad anstandslos durch.
Danke für eure Geduld.
Zur Info:
Das o5m-Datenformat muss leicht geändert werden. Natürlich wäre es möglich, osmchange und auch o5mfilter auch zum alten Format kompatibel zu halten, aber wenn ich die Lage richtig einschätze, existieren noch keine großen Datenmengen in diesem Format, so dass ein harter Schnitt auch in Ordnung ist.
Zum Hintergrund:
.osc soll in Zukunft in vollem Umfang unterstützt werden. Das heißt, indirekt muss auch die Information der Action-Tags gespeichert werden: create, modify, delete. Ebenso soll die Versionsnummer nun zum Standard gehören, das heißt, sie wird mit der Option --drop-history nicht gelöscht.
Die neuen Programmversionen bekommen Nummern ab “0.1”. Ich hoffe, dass sich durch die Format-Änderungen keine Bugs einschleichen. Wird schon gutgehen und lohnt sich ja auch.
Aus meiner Sicht spricht nichts dagegen, da ich ja die o5m Dateien aus den pbf Dateien erzeuge. Ob sich da jetzt das zwischenformat ändert oder nicht ist eigentlich unerheblich.
Die Frage ist ob irgendwann o5m Downloads angeboten werden.
Könntest du dir vorstellen, dass deine Programme auch o5m.bz2 oder in anderer gepackter Form verarbeiten können? So wie dies heute beispielsweise mit dem osm.bz2 der Fall ist.
Wär sicher nett, aber bleiben wir bitte auf dem Teppich. Das .pbf-Format hat sich gut etabliert und ist für die Downloads sicher gut geeignet.
Auch, wenn ein gepacktes .o5m um ca. 10% kleiner wäre als ein .pbf.
o5mfilter: Nein. Das Programm braucht Direktzugriff auf die Eingabedatei, weil es Teile davon mehrfach lesen muss. Dafür ist das (ungepackte) .o5m-Format ideal.
osmconvert: Einen Packer will ich nicht integrieren, weil die extern angewendeten Programme meist besser auf das jeweilige Betriebssystem abgestimmt und damit auch schneller sind.
Du kannst recht einfach ein externes Programm zum Auspacken verwenden (hier für Linux). Beispiele:
Das Packen bringt bei .o5m übrigens lang nicht so viel wie man es z.B. von .osm (XML) gewohnt ist. Bei .pbf wirds kurios, weil das Format intern komprimiert ist. Wenn man es nochmal packt, wird die Datei oft größer.
Kurze Info - falls jemand sowas braucht: Man kann jetzt auch nach User-ID und User-Name filtern. Dazu wird den betreffenden Keys ein @ vorangestellt (@uid, @user). Beispiel:
