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.
In diesem Fall schreibt entweder osmconvert das benötigte Reset-Byte nicht oder o5mfilter übersieht es.
http://wiki.openstreetmap.org/wiki/O5m#Reset
Würde dem auch gern auf den Grund gehen. Bisher hat das nämlich recht gut geklappt…
Hallo Frank
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.
Gib mir einfach einen Tipp, wie ich dir dabei helfen kann. Das Problem mit dem Tempfiles hat sich erfolgreich erledigt.
nicht ich war zu langsam, Du warst zu früh 
Die Datei von heute ist von 04:10, d. h. Du bist sehr früh aufgestanden und hast Du die Datei von gestern erwischt
Ciao,
Frank
Egal was dort steht! Ich bin nicht um 4:00 Uhr schon wach gewesen. Die Datei ist gegen 7 Uhr auf meinen PC gewandert.
Wie auch immer, die md5sums stimmen ueberein und die Aenderungen von gestern sind auch drin.
Werds heut abend mal auf meinem linuxhobel testen, ob der Fehler mit der sachsendatei auch so auftritt.
Ciao,
Frank
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.
Hi,
o5mfilter test.o5m --keep=“route=bus” >oepnv_mf.osm
funktioniert nicht nach:
osmconvert sachsen.osm.pbf -b=13.2,50.5,14.7,51.5 --drop-broken-refs --out-o5m > test.o5m
osmconvert sachsen.osm.pbf -b=13.2,50.5,14.7,51.5 --out-o5m > test.o5m
osmconvert sachsen.osm.pbf --drop-broken-refs --out-o5m > test.o5m
osmconvert mittelfranken.osm.pbf --drop-broken-refs --out-o5m > test.o5m
funkioniert nach:
osmconvert sachsen.osm.pbf --out-o5m > test.o5m
osmconvert mittelfranken.osm.pbf --out-o5m > test.o5m
Ciao,
Frank
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.
Ja er läuft schnell und ohne Probleme durch.
Freut mich. Danke für den Test!
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:
bzcat germany.osm.bz2 | osmconvert - -B=p.poly > dorf.osm
zcat germany.osm.zip | osmconvert - -B=p.poly | gzip > dorf.osm.gz
Geht sicher unter Windows ähnlich.
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:
o5mfilter germany.o5m --keep="all highway=residenital =unclassified =tertiary @user=meinUsername" >editiert_und_noch_aktuell.osm
Ergänzung: in der aktuellen Version (0.1J) sind bei Values Wildcards erlaubt - allerdings nur am Anfang und am Ende. Beispiel:
o5mfilter germany.o5m --keep="all place= name=*dorf" >namen.osm
Holla,
die Entwicklung geht so schnell voran, da kommt man ja kaum mit dem downloaden und compiliern nach 
Danke! 
Ciao,
Frank
Tschuldigung.
Hab in der 0.1K die Statistikfunktion ein bisschen ergänzt. Hier ein paar Beispiele…
Alle Keys inklusive Häufigkeit ausgeben (gabs schon):
o5mfilter bremen.o5m --out-key=
3 _comment_
18 _description_
20 _waypoint_
152 abandoned
1403 access
4914 addr:city
3764 addr:country
35 addr:housename
9841 addr:housenumber
177 addr:interpolation
(...)
Alle Keys sortiert nach Häufigkeit ausgeben (gabs schon):
o5mfilter bremen.o5m --out-count=
26975 created_by
26170 highway
20154 name
12526 building
11665 source
9841 addr:housenumber
9567 addr:street
5283 foot
4914 addr:city
4865 amenity
(...)
Alle Vals eines Keys inklusive Häufigkeit ausgeben (neu):
o5mfilter bremen.o5m --out-key=highway
7 abandoned
5 bridleway
2 bus_guideway
1267 bus_stop
22 construction
132 crossing
2048 cycleway
5 elevator
1 emergency_access_point
4735 footway
(...)
Alle Vals eines Keys sortiert nach Häufigkeit ausgeben (neu):
o5mfilter bremen.o5m --out-count=highway
4735 footway
4648 residential
3778 service
2048 cycleway
1459 unclassified
1267 bus_stop
1178 path
1141 track
898 traffic_signals
852 secondary
720 tertiary
(...)
Im Prinzip nichts anderes als eine Art Offline-Tagwatch. Viel Spaß beim Spielen!
Hi,
hab heut mehrmals festgestellt, dass die temporaere Datei nicht immer geloescht wird am Ende von o5mfilter, vor allem wenn der output ge-piped wird.
Konnte aber leider die genauen Bedingungen nicht ermitteln, wann dies geschieht. Evtl. ein timingproblem.
Ciao,
Frank
Hallo, ja, ist mir auch schon mal aufgefallen. Zunächst: es ist unschädlich, wenn die temporären Dateien stehen bleiben, sie werden beim nächsten Lauf wieder gelöscht. Aber es schaut natürlich doof aus und ist nicht sauber.
Gelöscht werden die Dateien in einer atexit()-Prozedur. Anscheinend wird diese Prozedur nicht aufgerufen, wenn man das Programm nicht normal beendet, sondern abbricht. Das passiert in einer Pipe offenbar automatisch, wenn die nachgelagerten Programme schneller fertig werden als o5mfilter bzw. osmconvert, wenn also nicht bis zum Ende der Pipe gelesen wird. Beispiel: das Kommando “head”.
Im Moment hab ich noch keine Idee, wie ich das ändern kann… ich werd eine Runde drüber nachdenken.
EDIT:
Erledigt (Version 0.1L). Hab einen kleinen Signal-Handler reingehängt, der “SIGPIPE” abfängt, eine Meldung bringt und das Programm ordentlich beendet.
Das Signal “SIGPIPE” wird vom Programm immer dann empfangen, wenn die Output-Pipe gebrochen ist, wenn sich z.B. das nachgeschaltete Programm schon beendet hat.
Hi,
supi, funzt, danke
Ciao,
Frank