x

Re: Reverter mit Override von Konflikten


Geschrieben von SunCobalt (Gast) am 18. Oktober 2012 20:16:18: [flux]

Als Antwort auf: Reverter mit Override von Konflikten geschrieben von SunCobalt (Gast) am 14. Oktober 2012 20:12:

woodpeck wrote:

...
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);

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)

RELATION OBJECT CREATED
no previous version
Current - Version: 1 : #<OSM::Relation id="2501315" user="SunCobalt" timestamp="2012-10-15T17:36:27Z" visible="true">
-> Tags testcase=1
-> Relation Members -> 1967126839(node) 186014534(way)
Last - Version: 2 : #<OSM::Relation id="2501315" user="SunCobalt" timestamp="2012-10-15T17:39:59Z" visible="false">
-> Tags
-> Relation Members ->
WARNING OBJECT HAS BEEN MODIFIED AFTER THIS CHANGESET - VERSION CONFLICT
no revert required, previous object version equals last object version

passt also

woodpeck wrote:

  • 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,

yep, das ist sowieso klar

woodpeck wrote:

und bei zyklisch verlinkten Relationen ist es besonders fies 😉

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.