Ich hatte vorm Eröffnen des Threads nicht nachgeschaut, aber seit Mai 2013 gibt es einen entsprechenden offenen issue auf Github sowie etliche geschlossene, die auf diesen verweisen. Die bisher hier gemeldeten Fehler habe ich gepostet.
Danke!
Was mir dort unangenehm auffällt: Ich sehe - auch auf den 2. Blick - keine Antwort der Entwicker. Nur ziemlich konstruktive Kritiken, Wünsche und Verbesserungsvorschläge der Anwender. 
Lieg ich da richtig? Dann ist das fast genau so eine Sackgasse wie unser “kleines” Forum.
Bei Josm dagegen - nein, ich will hier nicht wieder die Software vergleichen! - ist die Diskussion mit den Entwickern und auch der Entwickler untereinander deutlich ausgeprägter. Liegt das möglicherweise daran, dass iD ein One Man Project ist? Bin mir da aber nicht sicher.
Gruss
walter
Dass der Hauptentwickler von dem Issue Kenntnis hat kannst du daran sehen, dass er zumindest einen anderen Issue dagegen verlinkt hat.
Wie ich im OP schrieb, müssen wir vermutlich eine Weile sammeln. 
Der Schluss, dass iD keine reine OneMan-Show ist, liegt einen Klick von der von mir verlinkten Seite entfernt.
Alles klar, soo tief bin ich im Git auch net drin. Dan lese ich mir den Thread nochmals durch, da ich jetzt sehen kann, was die Entwickler geschrieben haben.
Gruss
walter
Nachtrag: Naja, da ist nur ein einziger (https://github.com/jfirebaugh) die ganze Zeit dabei und ein anderer (https://github.com/bhousel) hat im Herbst auch noch sichtbare Spuren hinterlassen. Für mich also jetzt ein “Two Man Procect”.
Und wenn ich das sichtig sehe, will jemand eine Spende über 15$ (bounty) um das Problem zu fixen? Ist auch ne Methode, die Community zu integrieren
Stimmt, der angesprochene Bug-Report ist ein gutes Beispiel wie so etwas nicht auszusehen hat (zumindest der zweizeilige Ausgangpost). Am ehesten hat mir noch ftrebien Post gefallen.
Vielleicht haben ja ein paar Lust Braimstorming zu machen WIE man es am besten umsetzt, dann kann man das vorschlagen. Folgende Zitate von den Entwicklern:
Also folgendes ist unerwünscht:
- Aktionen (z.B. Löschen) ganz sperren
- Bestätigunsdialoge ö.ä. zum Fortfahren
- Zu lange und zu detailierte Fehlermeldungen
- Popups/Modals
Ich denke mal das Minimum ist, dass man zumindest beim Speichern warnt, wenn ein Relationsmember gelöscht wurde, dass etwas kaputt gehen kann. Wie das dann beim Zusammenführen/Teilen von Wegen aussehen kann, muss man mal überlegen. Was ich mir vorstellen könnte wäre eine Art Tooltip/Hint am rechten, unteren Rand, der aufpoppt. Bei JOSM gibt es doch auch ein ähnliches Element oder verwechsel ich da gerade was? Dann könnte man sagen, was problematisch ist, einen Link “Was bedeutet das konkret” und vielleicht ein “Rückgängig machen” (okay der wäre dann doppelt zu finden, aber soll verdeutlichen, dass esmpfohlen wird diese Aktion rückgängig zu machen).
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.
-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 
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