Die “Kritik” richtet sich wohl eher an osmconvert als an josm 
Hi,
die Schwierigkeit beim “sandbox-ähnlichen” Ändern der Daten liegt nicht bei den Programmen, sondern beim Fehlen der vom OSM-Server gemachten Änderungen - widergespiegelt in 2 unterschiedlichen OSM-Files oder einem Diff-File, welche direkt vom Server stammen.
Wie man in der unten aufgefuehrten test_mod_2.osm sehen kann, hat osmconvert
- das mit action=delete markierte Element entfernt
- die action=modify Markierungen entfernt
- die iDs unveraendert gelassen.
Löschen der Elemente mit “action=delete” klappt auf diese Weise. Elemente, die mit “action=modify” markiert sind, können entweder neu erstellt (negative IDs) oder verändert worden sein.
Sind die IDs negativ, müssen freie IDs gesucht und die negativen ersetzt werden. Zudem gehört “version=1” an jedes Element. Veränderte Elemente (positive IDs) dagegen ersetzen komplett die alten Elemente (z.B. alle Nodes in einem Way), wobei bei “version=x” für den Way gilt: new_ver=old_ver+1.
Die Tätigkeit des Servers muss also nachgebildet werden, bevor “action=modify” entfernt werden kann oder weitere Programme auf die Daten angesetzt werden.
Osmosis z.B. interessiert sich nicht für “action=delete”, das Tag kommt weg und die Daten sind noch (bzw. wieder) da.
Grüße
Mario
Edit: So mache ich es beim Coastlinefile für mkgmap
http://wiki.openstreetmap.org/wiki/User:Garmin-User/Sonstiges
jo, mag ein.
gruss
walter
Das kann bei deinem Testfall so nicht klappen. osmconvert geht davon aus, dass die Daten vom OSM-Server stammen und setzt deswegen voraus, dass Objekte mit unterschiedlichem Inhalt auch eine unterschiedliche Versionsnummer haben. Bei deinem Test aber existieren Objekte mit gleicher ID und gleicher Versionsnummer, aber unterschiedlichem Inhalt. Das gibt es normalerweise nicht, deswegen spart sich das Programm den Vergleich Byte für Byte.
Trotzdem kannst du bei osmconvert einen byteweisen Vergleich erzwingen, wenn du statt –diff die Option –diff-contents verwendest. Das Programm läuft dann allerdings ein bisschen länger.
Ein paar Worte dazu stehen in der Hilfe: osmconvert -h und etwas ausführlicher bei osmconvert --help
Ich habe eben mal --diff-contents probiert, dabei aber wieder genau das gleiche Ergebnis erhalten.
Nachtrag: Im Hilfe-Text steht, dass bei --diff-contents die erste Datei im o5m-Format sein muss. Ich werde da mal weiter probieren.
Nachtrag 2: Ich habe aus test.osm und test_mod.osm von oben jetzt mit osmconvert test.o5m und test_mod.o5m erzeugt.
Danach habe ich die folgendne Kommandos probiert.
osmconvert test.o5m test_mod.osm --diff-contents > test_mod_dif3.osc
osmconvert test.o5m test_mod.o5m --diff-contents > test_mod_dif4.osc
Im ersten Fall ist das Loeschen des Knotens verlorengegangen (das action=delete Tag also nicht beruecksichtig worden).
In beiden Faellen ist die Strasse, aus der der eine Knoten geloescht wurde, als nur erstellt aufgefuehrt worden. Die neu erstellten Objekte sind interessanter Weise nur mit modify gekennzeichnet.
Gruss
Torsten
test_mod_dif3.osc:
<?xml version='1.0' encoding='UTF-8'?>test_mod_dif4.osc:
<?xml version='1.0' encoding='UTF-8'?>Könnte daran liegen, dass “action=‘delete’” und nicht “” verwendet wurde, ich bin mir aber nicht sicher. Am besten wärs, wenn der Hilfetest .o5m für beide Dateien fordern würde. Ich kümmer mich drum, danke für den Hinweis!!
Ja, das ist klar, denn die Daten sind nicht vollständig: es fehlt bei manchen Objekten das Versions-Attribut. Das .o5c-Format unterscheidet eh nicht zwischen “create” und “modify”, weil diese Information normalerweise redundant ist. Bei der Umwandlung von .o5c in .osc wird “create” immer dann angenommen, wenn die Versionsnummer 1 ist.
Näheres hier: https://wiki.openstreetmap.org/wiki/O5m#.o5c_as_OSM_Change_Format