iD und kaputte Relationen

Eine Meldung erst beim Speichern halte ich für ungünstig:

  • es ist schwer den Zusammenhang zwischen der destruktiven Aktion (eine Viertelstunde vorher) und der Meldung herzustellen
  • es können beliebig viele problematische Aktionen zusammenkommen sein
  • es ist nicht mehr möglich, als Reaktion einfach vorsichtshalber “Undo” zu verwenden

Wenn dann müßte ein begleitendes Popup sofort erscheinen, so daß der Zusammenhang klar ist und man sich mit “Undo” behelfen kann.

bye, Nop

Ja seh ich genau so, aber es wäre ein erster Schritt. Genau so macht es JOSM ja auch (Popup nach der Aktion + Warnung vor dem Hochladen).
Da Popups kategorisch ausgeschlossen werden, kann man entweder über Alternativen diskutieren oder feststellen, dass dies der einzige Weg ist und damit auch sachlich argumentieren.

iD 1.6.2 Änderungssatz 27938908: Landuse-MP #2635220 durch löschen des outer-ways verstümmelt.

-snip- vertan

Der Webdienst von user:tyrasd zur Darstellung von Änderungssätzen innerhalb der letzten 7 Tage http://tyrasd.github.io/latest-changes/

bietet auch seit neuestem :wink: für jeden Änderungssatz einen Link zu dem weiteren Webdienst http://wiki.openstreetmap.org/wiki/Achavi … (wie schon die beiden who-did-it Webdienste es tun)

Dort werden die tatsächlichen Änderungen zu einem Satz grafisch sehr brauchbar dargestellt.

Vielleicht hilft das ja bei der Bewertung bestimmter Änderungssätze via iD-Editor laut diesem Thread …

Latest-changes zeigt aber keine gelöschten Objekte und listet auch keine Änderungssätze, die nur Löschungen beinhalten. Da die meisten bisher gesammelten Fälle gelöschte Wege sind, halte ich es für diesen Anwendungsfall weniger geeignet.

Dafür ist ja dann vielleicht doch der Link zu Achavi hilfreich, denn dort werden gelöschte Objekte dargestellt, oder?

Ja, ich meine nur, dass für eine gezieltere Suche nach solchen Fällen latest-changes keine Hinweise gibt, welche Änderungssätze man sich genauer anschauen könnte. Das geht mit Whodidit oder einem Monitoring gleich mit Achavi besser, weil Löschungen angezeigt werden.

Aber ich will latest-changes nicht generell schlecht machen, das hat durch das schnellere, unkomplizierte Laden und die interaktive Auflistung der Changesets mit Kommentaren schon auch seine Vorteile.

Änderungssatz 28025148

Was ein unbeabsichtigtes Löschen an strategisch ungünstiger Stelle bewirken kann, läßt sich derzeitig im OSMI-Layer Multipolygone besichtigen.

iD 1.6.2 - Changeset 27767580 gelöschter Weg #88170786, der Bestandteil einer Grenzrelation war. (nur ein Beispiel, derjenige hat in seinen 20 Changesets bisher einiges mehr an Grenzrelationen beschädigt)

Ich hätte beinahe geschrieben “The German community expects you to fix this open issue. It has been open for almost two years.” (Die deutsche Community erwartet, dass dieser Bug gefixt wird. Er ist schon seit fast zwei Jahren offen.) Ich habe mich aber zurückgehalten.

iD 1.6.2: mehrere Pfade die Teil einer Wanderwegrelation waren gelöscht, hier ein paar Beispielchangesets:
https://www.openstreetmap.org/changeset/27771827
https://www.openstreetmap.org/changeset/27790997

iD 1.6.2: Changeset #28410448 Weg #169707074 gelöscht der Teil einer Admin-Relation war
(anderer User) iD 1.6.2: Changeset #28539851 Weg #34733073 gelöscht der Teil einer Admin-Relation war

iD 1.6.2: Changeset #28706773, Weg #54582818 gelöscht, der Teil einer Admin-Relation war.

Eure letzten Meldungen (Danke dafür) habe ich wieder nach github kopiert.

Moin,

auf Talk hat sich jemand massiv über die Probleme mit iD beschwert: http://gis.19327.n5.nabble.com/this-has-to-stop-iD-user-mistakes-all-over-the-place-tp5833126.html.

Gruss
walter

Wir sind nicht allein. Mindestens einem brasilianischen Mapper geht dieser iD-Bug auf den Sxxx. Er schreibt als Kommentar zur Github-Issue (von mir ins Deutsche übersetzt, Hervborhebung von mir):

Nachdem das Thema gestern und heute auf der Talk-Liste hochgekocht ist, hat Richard Fairhurst ein Pull-Request eingereicht, der dieses Problem lösen sollte.

Künftig soll es nicht mehr möglich sein, ein Objekt zu löschen, das Teil einer Relation ist. Stattdessen muss der User zuerst das Objekt aus der Relation entfernen.

@Nakaner: Ich lese es eher so, dass der User bestätigen muss, dass er ein Mitglied einer Relation löschen will.

Wir werden auch weiterhin dieses Problem haben. Im Changeset 28762684 wurde ein Node in zwei Nodes aufgeteilt (wie wenn man in JOSM einen Node markiert und G drückt). Deshalb wurde ein invalides Multipolygon hochgeladen.