Editor iD verunstaltet Landflächenumrisse

Hallo,

bei meinen Reparaturen der Meldungen des OSM-Inspectors (Geometry) habe ich den letzten Monaten mehrfach auch selbst überschneidende Landflächenumrisse korrigiert, bei denen einige Knoten mittels iD um über 300 m verschoben wurden, aber nicht alle um den gleichen Wert, wie beim Verschieben einer Fläche. Gesten abend hatte ich eine auf diese Art beschädigte Waldfläche direkt südlich Goslar gefunden. Hier waren der Wald und auch andere Flächen, die die selben Knoten wie der Wald verwendeten, mit verformt worden. Einige Seen im Süden dieser Waldfläche, die vom Wald fast umschlossen waren, hatten ihre Fläche um ein Vielfaches vergrößert. Auch waren die Radien des Waldumrisses an den (innen-)Kurven einer anliegenden Straße (B 241) vergößert (der Abstand zur Straße war hier in der Mitte der Innen-Bögen größer als an den Rändern der Bögen). Im Norden hatte diese Fläche auch einige rechte Winkel.

Es scheint mir so, dass hier eine Funktion von iD, die (versehentlich) über eine Taste ausgelöst wurde und die vermutlich zum Verschönern von Umrissen dient, wie das ‘q’ bei JOSM (und vielleicht auch anderen Editoren) zum Rechteckig-machen - bei iD scheinbar auch, um Rundungen gleichmäßiger zu machen. Möglicherweise werden Winkel unter 45° zu Rundungen und Winkel darüber zu rechten Winkeln (ein etwas anderes ‘q’)

Mir blieb nichts anderes übrig, als die Landflächen einzeln mit P1 rückgängig zu machen, da ich den Reverter bei JOSM (als eifriger JOSM-Nutzer) noch nicht versucht hatte.

Heute bin ich wieder auf solch eine, von iD auf die gleiche Weise modifizierte Landfläche gestoßen. Im Osten der Fläche sind einige Knoten um bis zu 180 m verschoben - hier ist nach Bing östlich vom Feldweg Landwirtschaft und keine Ortschaft. Die Ortsfläche ist immer noch in Version 1, aber die Knoten haben von iD am 17. Juni 2013 Version 2 bekommen. Ich möchte vorschlagen, diese Fläche als Beispiel für dieses Verhalten von iD erstmal noch nicht zu korrigieren.

Edit: Nachdem nun ein anderer Mapper diese Fläche nur an der Stelle der Selbstüberschneidung korrigiert hat, habe ich die Koordinaten der Knoten mit dem JOSM-Reverter wieder auf die Positionen vor dem “Rechteckig-Machen” mit iD korrigiert.

Weiß jemand, welche Funktion bei iD so etwas macht? Sollte diese Funktion (von der Tastatur aus) lieber nur im Edvanced-Modus möglich sein? … und wie man diese Verformung auch ohne Revert (mit JOSM) einfach korrigieren kann?

Franz

Inzwischen habe ich einige Versuche mit den Editor iD gemacht: Eine Fläche gezeichnet, die einem Umriss einer Ortschaft ähnlich sieht und darauf das Werkzeug zum Rechteckig-machen angewendet - schon hatte ich einen selbst überlappenden Umriss, der dem im östlichen Teil des Umrisses in dem 2. Link in Posting #1 ähnlich sah (einige rechte Winkel, aber auch leicht gebogene Linien).

Nun hatte ich in iD ein regelmäßiges Sechseck gezeichnet und mit dem ‘q’ bearbeitet - die Fläche hatte sich um ein vielfaches vergrößert! Bei JOSM bleiben die Knoten beim gleichen Versuch mit dem ‘q’ und dem Sechseck in der Nähe des Sechsecks und vergößern die Fläche nicht wie bei iD.

Also wird bei iD für das ‘q’ ein völlig anderer Algorithmus verwendet als bei JOSM. Hier sollten die Programmier nochmals nachbessern.

Franz

Ja und? Egal welcher Algorithmus verwendet wird, das Ergebnis ist danach totaler Quatsch. Zwar unterschiedlicher Quatsch aber immer noch Quatsch. Jetzt noch zu erwarten, dass beide Editoren den gleichen Quatsch machen, ist wohl ein wenig übertrieben.

Das einzige Problem kommt vom Mapper, der diesen Mist auch noch hochlädt.

Gruss
walter

Ich sehe das Problem ein Stück weit schon bei dem Editor, der solche eher seletenen und destruktiven Operationen dem Mapper in oberster Ebene anbietet (Menürad) - um nicht zu sagen aufdrängt - obwohl er sich angeblich gerade an Anfänger richten soll, von denen Du eben nicht erwarten kannst daß sie es zielsicher bemerken, wenn sie Mist hochladen.

Meiner Meinung nach haben solche Operationen in der obersten Menüebene bzw. direkt auf Tastendruck nichts verloren und sollten zumindest noch weiter abgesichert werden.

bye, Nop

Ich bin jetzt auch auf so eine mit iD vermurkste Fläche gestoßen: http://www.openstreetmap.org/browse/way/86340006 (Nicht irreführen lassen: die letzte Bearbeitung des Weges - jene mit dem vielsagenden Standardkommentar “Aktualisierung nach Spaziergang/Radtour/etc” - erfolgte mit JOSM, es wurden jedoch alle seine Knoten in einem einzigen Änderungssatz mit iD verschoben.) Auch hier finden sich hübsche Rechteckstrukturen, die den Gebrauch einer entsprechenden Funktion nahelegen.

Edit: nichts mehr zu sehen, wurde von jemand anderem rückgängig gemacht.

Sehe ich auch so, die Entwickler von iD sind aber leider anderer Meinung. Sinngemäß aus dem SOTM-US-Vortrag: “iD wird die Nutzer nicht mit lästigen Warnungen behelligen”, selbst dann nicht, wenn sie im Begriff sind, groben Unfug anzurichten. Das mag auch damit zu tun haben, daß die iD-Entwickler allesamt in den USA sitzen und es ihnen vermutlich noch nie passiert ist, daß in einem von ihnen gepflegten Gebiet ein Anfänger mit freundlicher Unterstützung seines Editors großflächigen Murks angerichtet hat.

Hallo Nop,

recht herzlichen Dank für Deine Unterstützung - insbesondere der Teil, wie denn ein unerfahrener Mapper vor dem Hochladen erkennen soll, dass er inzwischen eine größere Ladfläche mit vielen Knoten unbeabsichtigt rechteckig gemacht hat.

Bei zwei bis drei anderen Fällen, in denen Landflächen mittels iD unverhältnismäßig modifiziert wurden, hatte der Mapper wie auch in diesen Beispielen aus Posting #1 Gebäude ergänzt und diese vermutlich rechteckig gemacht und dabei auch den Umriss des Ortes oder eines Waldes erwischt. In einem Fall hat ein Mapper ein neues Gebäude erstellt und ein kurzes Fluss-Segment modifiziert wobei dann gut 1000 modifizierte Knoten herauskamen - die meisten von der vesehentlich modifizierten Landfläche.

Inzwischen habe ich mich mit dem Reverter von JOSM beschäftigt und schon erfolgreich zwei Landflächen zurückgesetzt (ohne die neuen Gebäude aus dem Changeset mit zu entfernen). Nun weiß ich, dass ich diese Fehler mit dem Reverter einfach korrigieren kann: Knoten des Umrisses markieren (JOSM Menü: Auswahl - Streckenpunkte wählen), dann im Reverter: Changeset-Nummer der Knoten! (nicht des Weges! - weil der meist nicht verändert wurde (nur die Koordinaten der Knoten, die im Way aufgezählt sind)) eingeben und “Nur Auswahl umkehren” ankreuzen, anschließend optisch prüfen, ob es geklappt hat und hochladen.

Edit: Quelle der Changeset-Nummer ergänzt

Franz

Danke Franz

dass hätte ich auch machen sollen, als ich in dieser Ecke auch einen Fall von rechteckiger Landnutzung hatte

http://www.openstreetmap.org/?box=yes&bbox=7.02256%2C50.85547%2C7.05767%2C50.87561
wahrscheinlich war die Änderung am 15. Juni.
Dummerweise war auch nicht sofort ersichtlich wo die Ursache lag, ich habe es dann händisch gemacht

Bernd

Ich glaube, wir nähern uns langsam dem Punkt, wo man sich zumindest für intensiv erfasste Gebiete wie DACH Gedanken über die Absicherung der bisher eingegebenen Daten machen muss. Es ist leider grundsätzlich viel weniger Aufwand erforderlich, Unordnung zu erzeugen als Ordnung herzustellen.
Auch wenn Reverten in JOSM halbwegs komfortabel möglich ist, kann es doch nicht sein, dass ein Teil der Mapper damit beschäftigt ist, versehentliche oder mutwillige Schäden an relevanten Teilen der Daten wiederherzustellen. Komfortablere Möglichkeiten des selektiven Revertens würden da Erleichterung schaffen, packen das Übel aber nicht an der Wurzel. Auch noch so eindringliche Warnungen in Editoren (wenn sie denn erfolgen) schützen nicht vor Trollen.

Mir schwebt ein teilweiser, abgestufter Schutz von essentiellen Daten vor, so ähnlich wie es inzwischen in Wikipedia praktiziert wird. Das Verfahren dort kann nicht einfach übernommen werden, da die Geodaten in OSM nie fertig sind und es immer möglich sein muss, sie zu verbessern und zu verfeinern. Es kann also nur darum gehen, nicht sämtliche Daten unbesehen und sofort zu übernehmen, wie es jetzt der Fall ist. Ich denke da an Straßen und Umrisse, die in 10cm-HiRes-Genauigkeit erfasst wurden und nur nach Bestätigung verschoben werden können. Das Aufspalten z.B. wegen Routen und das Einfügen von zusätzlichen Nodes müsste weiterhin möglich sein. Ebenso könnten Grundeigenschaften wie primary, secondary, ref geschützt sein, da sich diese Eigenschaften nur sehr selten ändern wenn sie erst einmal richtig erfasst wurden.

Dass damit nicht alle Probleme aus der Welt geschafft werden können (landuse-Grenzen sind in der Regel recht grob und werden leicht mit erwischt, mit ziemlich erheblichen Folgen), dürfte klar sein, aber OSM wird immer mehr auch für “erwachsene” Aufgaben wie Routing eingesetzt, wo die Qualität der Daten eine essentielle Rolle spielt. Etwas Schutz ist immer noch besser wie gar keiner. Ich möchte es eigentlich nicht erleben, dass ein paar Tage lang Radfahrer in den Sumpf geschickt werden, bis man den Fehler bemerkt.

Das soll kein “Teil-Lob mit Ganz-Ablehnung” (*) sein, aber die Sache ist schon etwas problematisch.

  • Rein technisch besitzt die derzeitige Datenstruktur (nodes/ways/relations) keinerlei Access-Flags. Außer Versionnummer, Datum und User der letzten Änderung steht sowas nicht drin, wenn man mal von dem Full-Planet mit History absieht.
    Daher wäre so eine Implementierung von der Erweiterung der Datenstruktur abhängig. Im OSM-Wiki gibt es eine Diskussion zur API_v0.7, deren Ergebnisse hoffentlich noch dieses Jahrzehnt (?) implementiert werden.

  • organisatorische stellt sich dann auch die Frage “wer darf wann was?” und “wer administriert die Rechte?”

Ich würde mich damit auch etwas wohler fühlen - gerade wenn es um Vandalismus (“Umgebung Schleswig”) oder um Newbie-Edits geht.

Gruss
walter

*) Chef zum Angestellten: “Das ist eine phantastische Idee, auf die wir schon lange gewartet haben! Nur werden wir sie nicht realisieren”

Ich sehe eigentlich weniger das Problem bei den neuen Usern, sondern dass gerade die einfach zu verwendenden Editoren wie Potlatch oder ID
für Neulinge* zu mächtig sind. Und man sollte Vandalismus nicht mit anderem vermengen.

Andererseits sollen aber die Neulinge, meiner Meinung nach, durchaus in der Lage sein, auch “gravierende” Änderungen machen zu dürfen.
Vielleicht wäre dann eine abgestufte Warnung: " Du möchtest Änderungen vornehmen, die andere als die von Dir ausgewählten Objekte betreffen, vornehmen?" bis
“Du möchtest Änderungen außerhalb des sichtbaren oder herunter geladenen Bereichs vornehmen?” angebracht.

Es mag Objekte geben, die nicht allgemein veränderbar sein sollten, Küsten - oder Grenzlinien, aber selbst bei denen sollte höchstens eine Warnung kommen.

Ich bin u.a. zu OSM gekommen, weil es einfach ist mitzumachen, und IMHO sollte es auch weiterhin so bleiben.
Fehler aufzeigen und beseitigen ist viel wichtiger.

Bernd

  • das soll keine herabsetzende Bezeichnung sein.

Änderung wegen Vandalismus hinzu gefügt.

Ganz Deiner Meinung. Ich habe die Datenqualität schon gelegentlich angesprochen. Ich habe schon öfter Leute angeschrieben, wenn mir “Fehler” aufgefallen sind. Davon bin ich abgekommen. Mir ist der Aufwand zu viel geworden.

Hallo Bernd

Da kann ich dir nur voll zustimmen.
In Dausenau (an der Lahn) wurde z.B. vor kurzem eine neue Umgehungsstraße eröffnet. Dort sollten entsprechend der geänderten verkehrlichen Bedeutung die Ortsdurchfahrt runtergestuft und die Umgehungsstraße heraufgestuft werden. Das ist unabhängig davon, ob die Umgehung bereits als Teil der B260 gewidmet ist oder noch nicht. (Vor wenigen Wochen war das noch nicht der Fall.)
Insoweit wären Einschränkungen immer sehr zweischneidig.

Edbert (EvanE)

Da stimme ich zu. Wie weiter oben schon angemerkt, lehnen die Programmierer sowohl von Potlatch als auch von iD aber jegliche Warnungen ab, egal welchen Murks ein User veranstaltet, und lassen sich darin nicht von uns alteuropäischen Bedenkenträgern beirren.

Es bleibt uns also wohl weiterhin nichts anderes übrig, als Bearbeitungen anderer Mapper, besonders jene von Anfängern oder mit bestimmten Editoren, im Auge zu behalten.

Es gab ja schon des öfteren die Idee einer automatischen Changeset-Überwachung zur Detektion von Mapping-Unfällen. Ich bastele auch ab und zu an so etwas: Changesets auf bestimmte Muster untersuchen, etwa auffällig hoher Anteil von Löschungen, Verschiebung ungewöhnlich vieler Knoten usw. Leider bin ich erst bei der grundlegenden Funktionalität und das ganze ist folglich noch weit von einer Einsatzreife entfernt; ferner man muß auch festhalten, daß bisher alle Versuche zur Entwicklung eines solchen Werkzeugs gescheitert sind. Mir steht diese Erfahrung noch bevor :wink:

Ich stimme zu, dass Einschränkungen ein zweischneidiges Schwert sind. Auch an “geschützten” Daten müssen Veränderungen möglich sein. Ich bin nur der Meinung, dass bei wichtigen und selten zu ändernden Daten ein höherer Sicherheitsaufwand tragbar sein müsste. Wie der praktikabel ausehen könnte (Moderator, Web of Trust, Vier-Augen-Prinzip), müsste man sich gut überlegen.

In den (seltenen) Fällen, in denen ich eingegriffen habe, habe ich die entsprechenden User informiert und meine Gründe erläutert. Bisher waren die Betroffenen verständnisvoll und so ein Kontakt kann ja auch motivierend für die weitere Mitarbeit sein. Kritisch wird es nur, wenn große Bereiche versehentlich verändert wurden, das einige Zeit nicht bemerkt wird und weitere User darauf aufbauend Änderungen machen. Die sind bei einem Revert dann hinüber und das frustriert schon (der Redaction-Bot lässt grüßen).

Ein nachgeschaltetes Plausibilitätsfilter wie von Oli-Wan vorgeschlagen, das etwas häufiger als KeepRight aktualisiert würde, könnte die Situation etwas entschärfen. Alle Aktionen, wenn das Kind schon im Brunnen liegt, sind aber naturgemäß schwieriger.

Die Vandalismusaktionen, die ich bisher gesehen habe, waren relativ primitiv. Bei ausgefuchsteren Angriffen könnte es notwendig sein, die gesamte Datenbank auf einen früheren Zustand zurückzusetzen. Das würde für ziemlichen Frust sorgen.

Ich bitte meinen zarten Hinweis als Anregung zur Vorsorge zu verstehen.

Sehe ich nicht so. OSM funktioniert doch gerade deshalb so gut, weil eben jeder machen kann, was er will. Wir wollen doch hoffentlich keine Blockwartstrukturen wie bei der Wikipedia. Man sollte das nicht auf die Nutzer schieben, die können meist wenig dafür, was sie anrechnen. Was man aber (als OSMF) sehr wohl machen könnte und sollte, wäre, auf der Startseite nur Editoren anzubieten, die vor den gefährlichsten Veränderungen schützen. Eine Sache, die ich mir höchstens vorstellen könnte, wäre bei den ersten paar (vielleicht 10) Changesets eine ‘Warnung’ auszugeben, wenn bestimmte Aspekte ungewöhnlich aussehen, beispielsweise eine sehr hohe Anzahl an bearbeiteten Objekten.

Die von mir beobachteten unbeabsichtigten Veränderungen von Landflächen durch iD wurden meist von Nutzern gemacht, die schon ein bis vier Jahre dabei sind, aber erst etwa 50 Edits gemacht haben (mit Unterbrechungen von mehreren Monaten) - bis auf das Beispiel von Oli-Wan in Post #5 (dieser Nutzer ist erst einige Tage dabei und hat schon etwa 250 Änderungssätze).

Wie sollen wir mit aufgefundenen Fehlern dieser Art umgehen? Sollten wir weitere mit dem OSMI gefundene Flächen erstmal als Beispiele hier posten oder sie gleich reverten, wenn wir sie finden? (wer den JOSM-Reverter nicht benutzen mag, kann sich hier mit einem Link auf den Umriss melden, damit es ein anderer zurücksetzt). Oder sollten wir warten, bis sich jemand in Unkenntnis dieses Fadens daran macht, Knoten der fehlerhaften Fläche zu verschieben, was einen Revert nur erschwert?

Wie finden wir unbeabsichtigt rechteckig gemachte Flächen, die sich nicht selbst überschneiden? und daher im OSMI nicht angezeigt werden?

Kann man den Fehler irgendwie speichern um dann (wie jetzt mit dem Link auf den Umriss) die fehlerhafte blaue Linie im Browser auch noch nach dem Revert anzuzeigen? (Z.B. könnte man mit JOSM den Umriss vor und nach dem Revert in jeweils eine neue Ebene kopieren und dann als zwei *.osm-Dateien speichern).

Franz

Ich bin da eigentlich ziemlich schmerzfrei, ich versuche den Fehler zeitnah zu beheben :wink: weil ich die Erfahrung gemacht, das ein reines Anschreiben mit Bitte der Reparatur praktisch nie zum Erfolg führt. Ich schreibe aber meist eine freundliche Mail dazu
Sind die Fehler behoben, kommen in der Regel aber immer positive Antworten und mehr als eine Mail ist meist gar nicht erforderlich.

ich hatte mal irgendwo eine Historienseite gesehen, die auch alte Wegeverläufe zeigte, weiss aber nicht mehr wo.
Es wäre vielleicht schön wenn in der History die Knoten die die Postion geändert haben, farbig hinterlegt würden.

Ansonsten hilft nur Suchen

Bernd

Vlt. war es dies: http://osmhv.openstreetmap.de oder http://owl.apis.dev.openstreetmap.org (danke Edbert)

Hallo Bernd

Siehe BonnAufKarten → Testkarten → Neuer History-View

Edbert (EvanE)

@reneman und EvanE

Danke für die Hinweise

Der neue History-View ist schon fast zu ausführlich :wink: mal sehen wie man da Erkenntnisse heraus ziehen kann

Bernd