Editor iD verunstaltet Landflächenumrisse

habe es wie folgt geschafft:

  • Änderungsatz mit Reverterplugin in leere JOSM - Ebene laden
  • Abspeichern als .OSM - file
  • Editieren des gespeicherten .OSM-file wie folgt:
    • den nicht benötigten anderen way entfernt
    • die Referenzen für den benötigten way aus der XML-History vor der Löschung mit copy und paste eingefügt und Datei abgespeichert
    • editiertes File als neue Ebene in Josm laden, nicht benötigte Punkte entfernen
    • Hochladen und Konflikte lösen…

//edit typo

Hallo,

hier mal eine kurze Statistik, welche Fehler dieser oder verwandter Art mir in den letzten zwei Wochen hauptsächlich in der nördlichen Hälfte Deutschlads begegnet sind:

  • etwa dreimal rechteckig-machen durch iD (in einem Fall hat ein Mapper, der viele Reparaturen von OSMI-Meldungen macht, nur die kreuzenden Linien der Landfläche korrigiert und nicht den Rest. Ich habe ihn darauf angeschrieben, ihm den Sachverhalt erklärt und ihm auch einen Link zu diesem Faden geschickt)

  • einmal rechteckig-machen durch JOSM

  • einmal kreisförmig-machen durch iD (das war dann ein Zwölfeck - das schon jemand begonnen hatte zu reparieren) (iD kann vermutlich nur Kreise mit 12 Ecken machen)

Franz

Hallo,

in den letzten beiden Wochen habe ich mich gezielt auf die Suche nach mittels iD rechteckig gemachten Landflächenumrissen (meist Ortsumrisse) gemacht - auch im angrenzenden Europa. In Deutschland habe ich bis gestern 21 Fälle bearbeitet, darunter auch ein kreisförmiger (seit Anfang August noch 6 mehr - darunter auch eine Fläche, die mit JOSM recheckig gemacht wurde). Heute, nachdem ich gesehen hatte, dass der OSMI ein neues Datum anzeigte und gründlicherer Suche durch ganz Deutschland habe ich noch 7 weitere Orte korrigiert.

Im europäischen Ausland steht Frankreich mit 12 Fällen hinter Deutschland (hier gabe es zwei kreisförmig veränderte Orte). Je drei Fälle hatte ich in Belgien, Rumänien und Bosnien Herzegowina bearbeitet und in elf weiteren Ländern ein oder zwei rechteckige Orte.

In einigen Fällen sah ich weitere Reparaturversuche vom selben Mapper, die aber die rechteckig gemachten und hochgeladenen Daten in iD nicht rückgängig machen konnten.

Franz

Lob , Lob :wink:

hast du da eine bestimme Strategie/Vorgehensweise? Es wurde ja schon versucht, diese Fälle automatisch zu finden aber das ist dann wohl eingeschlafen.

Gruss
walter

Hallo Walter,

ich suche mittels dem OSM-Inspector - Bereich: Geometrie. Da stören natürlich die anderen Fehler überschneidender Landflächen oder Gebäude. Deshalb bin ich heute Vormittag durch ganz Deutschland, um auch die meisten anderen Fehler zu beheben, um beim nächsten Update des Geometrie-View deutlich weniger rote Kreuze zu erwarten (ab Zoom 10) - bei niedrigeren Zoom fehlen alle einzelnen Fehler (wenn da nur ein Kreuz ab Zoom 10 ist) - die werden vermutlich von Clustering für das andere Symbol (bestehend aus den drei Linien ähnlich dem Buchstaben N) nicht erfasst.

Franz

Falls Du damit mich bzw. mein entsprechendes Vorhaben meinst: das ist nicht eingeschlafen, wird aber noch dauern. Dies habe ich aber von Anfang an gesagt:

Ein Ansatz für eine Rechteckvermurksungsanalyse ist, die Winkel zwischen benachbarten Knoten in (langen) Wegen zu untersuchen und nach einer Häufung von pi/2 oder pi Ausschau zu halten. Einfacher, aber möglicherweise auch schon nützlich: prüfen, ob in einem Änderungssatz alle Knoten eines längeren, bereits existierenden Weges verschoben wurden.

Dem Lob, Lob an Franz kann ich mich nur anschließen.

Hallo,

gestern hatte ich einen südlich Lissabon gelegenen Ortsteil rückgängig gemacht, der vorher iD-rechteckig war, aber im OSMI nur durch verschobene Knoten im Norden erkennbar war. Auch die beiden Fehler im Süden der Ortsfläche wurden durch das Reverten behoben.

Im Norden Frankreichs hatte ich gestern abend noch diese Fläche vom OSMI genannt bekommen, die selbst ganz in Ordnung war, aber die Nachbarfläche im Westen wurde rechteckig gemacht - erkennbar war nur diese kleine Überschneidung an wenigen gemeinsam genutzten Knoten:

Heute ein ähnlicher Fall, auch in Frankreich:

Hier war auch nur eine kleine Überschneidung zu sehen - aber keine Fläche zu finden, die rechteckig gemacht wirde. Wenn man genau hinschaut, hat der Ortsumriss ab dem Überschneidungspunkt Richtung Osten die typischen Kennzeichen von iD: leichte Bögen und rechte Winkel. Hier wurde also eine Nachbarfläche, die gemeinsame Knoten mit dem Ortsumriss besaß, rechteckig gemacht. Nur die ist nicht mehr da - die hat er gelöscht.

Nach Rückgängig machen des kompletten Änderungssatzes mittels JOSM Reverter in eine neue Ebene (mir scheint, den muss man dann immer zweimal aufrufen - warum eigentlich? Zuerst kommen nur Knoten und manchmal auch Linien. Aber viele Knoten werden erst beim 2. Aufruf an Linien angeschlossen) und Lösen von etwa 200 Konflikten konnte ich dann mittels “Auswahl hochladen” die wiederhergestellte Ackerfläche und die Knoten daran hochladen.

Wenn nun aber keine Überschneidung durch das iD-rechteckig-Machen entstanden ist, kann mir der OSMI auch keinen Fehler melden - dann wird die Suche danach noch schwerer (rechteckige Landflächen-Abschnitte suchen, die nicht ganz zu Bing passen).

Franz

Zwei Fragen: 1) Warum den kompletten Änderungssatz und nicht nur die betroffenen Knoten plus “gelöschte Objekte wiederherstellen”? 2) Warum in eine neue Ebene?

Den Reverter kenne ich erst seit Anfang dieses Fadens, daher habe ich noch nicht so viel Erfahrung damit. Ich wollte nur die eine gelöschte Landfläche wiederherstellen, die an den Ortsrand grenzt, aber nicht weitere Dinge hochladen, die er noch gelöscht hat. In der neuen Ebene kann ich erstmal sehen, wie die Landfläche vor dem Löschen aussah.

Auch bei den kreisförmig gemachten Flächen hatte ich erstmal in die 2. Ebene reverted, denn hier sollen die fehlenden Knoten auch in den Nachbarumrissen, die gemeinsame Knoten mit der zum Zwölfeck gewordenen Landfläche haben, wiederhergestellt werden.

Dazu empfehle ich andere Strategien. In der neuen Ebene fehlt der Kontext (verbundene Objekte, aber auch unverbundene Objekte in der Umgebung), deshalb verwende ich diese Option nicht.

  1. Nach dem Ausführen des Reverters kann man mit Rückgängig/Wiederholen wunderbar zwischen dem neuen und alten Stand hin und her springen und genau nachvollziehen, was der Reverter macht.
  2. Auch die Reverter-Aktion zählt in JOSM als Bearbeitung, d.h. davon betroffene Objekte lassen sich mit dem Schlüsselwort “modified” in der Suchfunktion auswählen. Man sieht sie ähnlich hervorgehoben wie in einer eigenen Ebene, aber mit dem Kontext.
  3. Wenn nur bestimmte verschobene Knoten wieder an ihren alten Ort zurück sollen, diese auswählen und mit “nur Auswahl rückgängig machen” zurückschieben lassen. Dann wird garantiert nichts anderes angefaßt.
  4. Ausschließlich gelöschte Objekte wiederherstellen geht auch. Dazu müßte man eigentlich nichts auswählen und dann “Auswahl rückgängig machen und gelöschte Objekte wiederherstellen” ausführen, aber diese Option bietet JOSM nicht an, wenn nichts ausgewählt ist. Also: ein Objekt auswählen, das mit dem fraglichen Änderungssatz überhaupt nichts zu tun hat, und dann den Befehl ausführen. Dann ist man wieder bei dem von Dir angesprochenen Problem, daß damit alle gelöschten Objekte wiederhergestellt werden und nicht nur das eine, was man haben will. Also mit modified-Suche die fälschlich wiederhergestellten ausfindig machen und löschen (beim Hochladen merkt die API, daß sie schon gelöscht sind, und ignoriert die Löschanfrage).

Allerdings -

  • scheint die Wiederherstellung nicht (mehr) in allen Fällen so zu funktionieren wie sie soll. Mir ist es auch schon passiert, daß Knoten nicht wiederhergestellt wurden und anschließend im wiederhergestellten Weg fehlten, obwohl die Löschung im gleichen Änderungssatz erfolgt war. Ordentlich reproduzieren konnte ich das aber nicht.

Punkt 4) wird auch problematisch, wenn man in eine neue Ebene wiederherstellen läßt. Angenommen, Weg W wurde gelöscht, seine Knoten (da noch durch Weg V anderweitig verwendet) aber nicht - dann tauchen sie auch nicht per Wiederherstellung in der Ebene auf und fehlen dort. Wie JOSM bei der Wiederherstellung in eine neue Ebene damit umgeht, weiß ich nicht; in der ursprünglichen Ebene sollten sie - wenn man großzügig genug heruntergeladen hat - mitsamt Weg V vorhanden sein.

Kleine Idee zum Thema “Quadrieren”: iD könnte die Anzahl der betroffenen Nodes ermitteln (kennt er eh) und ab ca 6-8 Nodes “motzen”

Gruss
walter

Jetzt ist es auch in meiner Heimat passiert. Kann das bitte jemand reparieren?

Danke
Thomas

Erledigt. War etwas mühsam, weil der User gleich in zwei Änderungssätzen munter rechteckisiert und gelöscht hat. Weil die Änderungssätze auch konstruktive Bearbeitungen enthalten, bin ich ziemlich selektiv vorgegangen; daher ist es möglich, daß ich nicht alles erwischt habe - bitte selbst noch einmal genauer prüfen.

PS.

Was die iD-Entwickler dazu sagen werden: Warnungen passen nicht ins Bedienkonzept. Und ehrlicherweise muß man zugeben, daß selbst JOSM bei den Befehlen Q, L und O keine solche Prüfung durchführt.

Interessanter “Übeltäter”: 2005 registriert, Ende 2006 erster Edit und den sogar mit Josm, alle paar Jahre ca 10 Edits, total 69 - und dann nimmt der iD und versaut alles :frowning:

ich glaube oli-wan hat das eben gefixed.

Gruss
walter

Das ist sinnvoll, noch wichtiger ist es m.E. wenn ab einer bestimmten Größe gemeckert wird. Runde oder quadratische Objekte mit mehr als 100 Meter Durchmesser/Kantenlänge halte ich für so selten, daß alle Editoren meckern sollten. Die Leute, die einen Beschleuniger oder sonstigen Versuchsring mappen, werden das verschmerzen können. Hätte mir auch selbst schon Arbeit gespart, wenn JOSM gemeckert hätte.

Die beste Warnschwelle sollten wir noch diskutieren, vermutlich sollte sie auch abhängig sein vom Gesichtsfeld. Bei hohem Zoom darf ein Kreisverkehr o.ä. das Gesichtsfeld durchaus überschreiten, je größer das Gesichtsfeld desto kleiner sollte der Zuwachs des Schwellwerts sein und definitiv innerhalb des Gesichtsfelds des Editors bleiben.

Baßtölpel

Zumindest der residential-Kreis (samt angehängter Knoten) ist von Oli-Wan wieder in vernünftige Form gebracht worden.
Ich komme immer mehr zur Überzeugung, dass es so nicht mehr lange gut gehen kann: Ein simpler Tastendruck (kreisförmig machen) wirft einen ganzen Ortsteil über den Haufen. Niedrige Einstiegsschwelle schön und gut, aber in stark bearbeiteten Gebieten wie D muss es irgendwo Grenzen geben. Es sollte doch machbar sein, in einem Editor wie iD bestimmte Operation höchstens in einer Art Experten-Modus zuzulassen. Bestehende Strukturen kreisförmig oder rechteckig zu machen über Kilometer hinweg kann doch nur ein Versehen sein.

Vielen Dank, ich guck mir das heute mal an.

Wenn man sowas nicht als Warnung darstellen möchte, könnte der Editor auch das Resultat der Operation darstellen (z.B. zweifarbig alte und neue Form) und nachfragen, ob das Ergebnis den Vorstellungen des Benutzers entspricht.

Eine einfache Grenze für die Node Anzahl halte ich aber nicht für sinnvoll.
Hier ein paar weitergehende Ideeen für eine Heuristik zur Entscheidung, ob ein Editor warnen oder die Ausführung ganz verweigern sollte:

Wird eine derartige Operation auf eine zusammenhängende Menge von Wegen angewendet, die ansonsten aber isoliert ist, ist die Operation wahrscheinlich beabsichtigt.

Gleiches gilt für eine Teilmenge einer solchen Menge.

Sind die Wege als “building” getaggt oder noch ungetaggt, so ist die Wahrscheinlichkeit erhöht, dass die Operation beabsichtigt ist.

Ist die Ausgangsform nicht von Wegen einer Klasse (z.B. highway) abgedeckt (überlagerte andersartige Wege können unberücksichtigt bleiben), so ist die Operation vermutlich unbeabsichtigt. Dabei können noch ungetaggte Wege als der jeweiligen Klasse zugehörig betrachtet werden.

Insbesondere bei nicht neu erstellten Objekten ist die Operation wahrscheinlich unbeabsichtigt, wenn die neue Form der alten Form nicht sehr ähnlich ist. Je größer die Ausdehnung ist, desto größer ist auch die zu erwartende Formähnlichkeit.

Ich habe eben mal überlegt, wie es dazu kommt, dass man das Landuse überhaupt erst auswählt: Vermutlich, weil man zum Deselektieren üblicherweise “irgendwo ins Nichts” klickt, womit man in iD aber die dort liegende Fläche auswählt. Vielleicht könnte man ja darüber mit den iD-Entwicklern diskutieren, dass ab einem bestimmten Zommlevel Landnutzungsflächen (oder allgemeiner: grössere Flächen) nicht mehr auf diese Art ausgewählt werden können und als Hintergrund betrachtet werden.

Das klingt einleuchtend, und würde auch erklären, wie neulich eine ganze Kleinstadt zum Hotel umgetaggt wurde: http://www.openstreetmap.org/browse/changeset/17617860 (wahrscheinlich nicht das einzige solche Ereignis)
Angesichts einer gewissen Beratungsresistenz der Matchbox-Leute in Bezug auf einmal getroffene Entscheidungen zum Bedienkonzept bin ich zwar bei den Erfolgsaussichten etwas skeptisch, aber es wäre wohl einen Versuch wert. → https://github.com/systemed/iD/issues