Reverter mit Override von Konflikten

Hallo,

ich schreibe gerade einen neuen Reverter, da mich die Konflikte in dem bestehenden Reverter in JOSM nerven und die Konfliktlösung in JOSM eine Katastrophe ist. Statt dessen will ich jedes angefasste Objekt in einem Changeset auf den vorherigen Stand zurücksetzen, unabhängig davon, ob es danach noch weitere Bearbeitungen gab. Funktioniert auch, osm-xml sieht gut aus und JOSM lädt die Datei dann auch…nur abgedrückt habe ich noch nicht.
Nun frage ich mich, was ich testen sollte bevor ich das Ding benutze. Momentan plane ich ein paar Test [1], aber vielleicht übersehe ich etwas. Das Programm ist momentan recht gesprächig und gibt viel aus…vielleicht zuviel [2]…evtl sollte ich mich auf die Punkte beschränken, wo es nach dem zu revertendem Changeset noch Bearbeitungen an einem Objekt gab (siehe ganz unten im Test-Log). Und wenn alle evtl Bugs gefixt sind, sollte man den Code in die Öffentlichkeit lassen? Ich schiebe den Revert zwar absichtlich nicht direkt zur API, von wo es die ganzen Changeset und History Informationen bekommt, aber man kann ja niemanden zwingen Logs zu lesen.

[1]
Test 1 | v1: created node, way, relation => revert v1 (i.e. delete)
Test 2 | v1: created node, way, relation → v2: modify node, modify, modify relation => revert v2
Test 3 | v1: created node, way, relation → v2: modify node, modify, modify relation => revert v1
Test 4 | v1: created node, way, relation → v2: modify node, modify, modify relation → v3: delete node, delete way, delete relation => revert to v2
Test 5 | v1: created node, way, relation → v2: modify node, modify, modify relation → v3: delete node, delete way, delete relation => revert to v1

[2] (echte Daten in der OSM DB…zum selber prüfen)


2012-10-14T18:53:17Z
OBJECT CHANGES FOR CHANGESET 13492005
CREATED NODE OSM ID:1964493170 Version:1 Lat:48.7071986 Lon:9.7040827 User:SunCobalt Visible:true Tags:
No previous version
MAX VERSION of this node 1

CREATED NODE OSM ID:1964493180 Version:1 Lat:48.7073419 Lon:9.7044297 User:SunCobalt Visible:true Tags:nada=nix, test=blub
No previous version
MAX VERSION of this node 1

CREATED RELA OSM ID:2495748 Version:1 User:SunCobalt Visible:true
-> Members OSM-ID:1964493180 Type:node Role:node
-> Members OSM-ID:1962552513 Type:node Role:node
-> Members OSM-ID:185607312 Type:way Role:
-> Tags:type=testpolygon
No previous version
MAX VERSION of this relation 2

MODIFIED RELA OSM ID:2474667 Version:2 User:SunCobalt Visible:true
-> Member OSM-ID:1964493180 Type:node Role:
-> Member OSM-ID:1962552513 Type:node Role:outer
-> Member OSM-ID:185607312 Type:way Role:
-> Tags: area=no, note=test relation, type=nix
PREVIOUS RELA OSM ID:2474667 Version:1 User:SunCobalt Visible:true
-> Members OSM-ID:1962552513 Type:node Role:outer
-> Members OSM-ID:185607312 Type:way Role:
-> Tags: note=test relation, type=nix
MAX VERSION of this relation 2

MODIFIED WAY  OSM ID:185607312 Version:2 User:SunCobalt Visible:true Way Nodes 1962552512 1964493170 1962552514 Tags:blub=bla
PREVIOUS WAY  OSM ID:185607312 Version:1 User:SunCobalt Visible:true Way Nodes 1962552512 1962552514 Tags:
MAX VERSION of this way 4
!!! WARNING Revert will override version conflict !!!

Ich würde für die Tests auch http://api06.dev.openstreetmap.org verwenden.

Gruß,
Mondschein

Was die meisten Leute uebersehen, wenn sie Changesets, oder auch Gruppen von Changesets, rueckgaengig machen:

  • dasselbe Objekt kann mehrfach bearbeitet worden sein;
  • es kann sein, dass das Objekt durch eine solche Mehrfachbearbeitung bereits wieder “ok” ist (z.B. in dem Changeset, das ich rueckgaengig machen will, wurde ein Objekt geloescht und danach wieder entloescht - wieso sollte ich also noch was tun, oder: ein Objekt wurde erzeugt und wieder geloescht, auch hier keine Aenderung noetig);
  • das Wiederherstellen von geloeschten Nodes muss vor dem Wiederherstellen von Ways und Relationen geschehen, waehrend das Loeschen von erstellten Nodes erst nach dem Wiederherstellen bzw. Entfernen von Ways und Relationen geschehen darf, da es sonst zu der Situation kommen kann, dass ein Node geloescht wird, der in der noch-nicht-wieder-berichtigten Version eines Ways benutzt wird usw.; fuer Ways und Relationen gibt es aehnliche Anforderungen, und bei zyklisch verlinkten Relationen ist es besonders fies :wink:

Bye
Frederik

OK, das habe ich eingebaut. Wenn ich versuche das Changeset 13508881 zu reverten, bekomme ich das Changeset


<?xml version="1.0" encoding="UTF-8"?>
<osm version='0.6' upload='true' generator='SunCobalt Revert Script'>
</osm>

das ich es schon in diesem Changeset 13508923 revertet habe und das die letzte Version ist. Mein Log sagt bei jeden Object “no revert required, previous object version equals last object version”. Ich vergleiche die letzte Objektversion mit der vorherigen und wenn alles gleich ist (ausser timestamp, user etc), macht es nix. (Auch wenn es keine vorherige Version gibt…revert von V1 Objekten, die bereits gelöscht sind wie in dem Beispiel unten)

passt also

yep, das ist sowieso klar

meinst Du damit geschachtelte Relationen? Damit kommt ich jetzt bis Relation ----member—>Relation —member—> Relation klar. Vom Code her könnte ich recht einfach noch tiefer gehen.
Problem ist nur, dass JOSM das nicht unterstützt und die Ordnung der Datei wieder durcheinander bringt.
Mein Changeset löscht von “oben”, also die Top-Parent- Relation 2511140 zuerst, dann die mittlere Relation 2510940 und dann die ganz unten 2501379. Undelete genau andersrum


<?xml version="1.0" encoding="UTF-8"?>
<osm version='0.6' upload='true' generator='SunCobalt Revert Script'>
    <relation id="2511140" action="delete" visible="true" version="3">
      <member type="node"  ref="1967216493" role=""/>
      <member type="relation"  ref="2510940" role="topparent"/>
    </relation>
    <relation id="2510940" action="delete" visible="true" version="5">
      <member type="relation"  ref="2501379" role="parent"/>
    </relation>
    <relation id="2501379" action="delete" visible="true" version="14">
      <member type="way"  ref="186023220" role="way"/>
      <member type="node"  ref="1967216493" role="node"/>
    </relation>
.............

JOSM will aber trotzdem die 2501379 vor der 2510940 löschen. Das ist mMn ein Bug, da das auch durch manuelles Arbeiten passieren kann

Also muss ich es wohl doch direkt zur API schieben, was ich eigentlich gar nicht will.