Sind die neuen Validierungsregeln des iD-Editors wirklich gut?

Nur zur Info’, die Entwicklunginstanz wird nun zum Testen nicht mehr benötigt, weil die V2.15 (inklusive der neuen Validierungsregeln) gerade (zufällig) heute auf der openstreetmap-website eingebunden wurde, siehe:
https://github.com/openstreetmap/openstreetmap-website/pull/2231

Diese Frage wurde erst vor ein paar Wochen/Monaten entweder hier im Forum oder auf Talk-de diskutiert. Wenn ich den Link dazu habe, update ich diesen Eintrag.
Übernimmt Mapbox die Tagging-Hoheit in OSM?, ab Beitrag #18 geht’s dann damit los. Und ursprünglich würde das auch schon 2013 in iD ist nun der default editor auf osm.org angerissen und diskutiert.

… und schon ist durch eine Gegenfrage die eigentliche Frage in eine andere Richtung geschoben. Aus “wie gut sind die neuen Validierungsregelungen” wurde die Frage, wieso iD zum Standart-Editor gemacht wurde. Ich warte jetzt erst einmal ab, worum es in dieser Diskussion gehen soll, bevor ich mir Gedanken über Antworten mache. Oder besser noch, ich stelle mal noch eine Frage in den Raum:
Wer sagt, dass iD der Standart-Editor ist? Wenn man die Bearbeitungsfunktion der Standartkarte aufruft, werden einem mehrere Editoren zur Auswahl angeboten. Davon, das iD davon der Standart-Editor sein soll, kann ich erst mal nichts erkennen.

Gegenfrage einfach ignorieren und in den in #4 genannten Threads weiterdiskutieren.
Im Zweifel gilt immer die Hauptfrage des Threaderstellers :wink:

+1 diese Gegenfrage gehört nicht in diese Thread und sollte hier entfernt werden. Wen es wirklich interessiert kann gern einen neuen Thread eröffnen. Wer nach eigener Aussage iD nicht kennt und nichts dazu sagen kann, sollte dann auch so konsequent sein, dies zu lassen.

ich war gestern Abend auch überrascht, irgendwas war plötzlich anders am iD …

Die ersten Validierungsregeln gibt es bereits seit der letzten Version. Bisher ist mir noch kein Hinweis begegnet, der irgendwie sinnlos oder falsch war oder gar machtmissbräuchlich etwas faktisch durchdrücken würde, was nicht Konsens ist.

Auch dieser bereits tendenziösen Formulierung möchte ich antworten: ich hatte mir gestern Abend ein größeres Wald-MP angesehen, das plötzlich auf der Standardkarte nicht mehr gerendert wurde. Tags zuvor war es noch da. OSM Inspector zeigte zwar einen Fehler an, der aber für das Nicht-Rendern nicht verantwortlich sein könnte. Ich bin direkt vom inspector zu iD gewechselt und bekam die Fehlermeldung über zwei zwei Nähe beieinander liegende aber nicht verbundene Punkte des outer Rings. Der Fehler ist dem letzten Bearbeiter sicher unabsichtlich passiert. Behoben und die Kacheln werden jetzt so nach und nach wieder neu gerendert mit Wald ausgeliefert.
Und bevor spekuliert wird: die letzte vmtl. fehlerverursachende Bearbeitung erfolgte mit JOSM. Moral von der Geschichte: man kann sowohl mit iD Relationen korrekt bearbeiten wie auch mit JOSM Relationsfehler verursachen.

Ich würde mir jedenfalls wünschen, dass der Thread und die berechtigten Kritiken an iD hier sachlich bleiben und das mehr oder weniger offene bis unterschwellige iD-Bashing mal unterbleibt.
Danke

Der Mammi

Edith Wortkorrektur

OT Bin im Thread mehrfach über das Wort “Standart” gestolpert. Die Standarte ist ein Feldzeichen, das die Römer vor ihren Truppen hergetragen haben. https://de.wikipedia.org/wiki/Feldzeichen Und der ID-Standard schreibt sich mit “d”. Dies nur am Rande. User AB-inf-x-chg-AB hat´s richtig geschrieben.

Ich lese hier mit, da noch am OSM-Lernen. Was ist ein “Wald-MP”? Im OSM Wiki finde ich nichts dazu.

MP = Multipolygon

Ich hab’s geschrieben … :sunglasses:

MP ist eine Multipoligon-Relation.

Vielleicht wäre es gut, wenn mehr Leute ein besonderes Augenmerk auf die Vorschläge zum Aktualisieren veralteter Tags werfen würden, vor allem für POIs. Ich habe da so ein Gefühl, dass dort noch ein paar merkwürdige Sachen drin sind.

Die Vorschläge kann man sich übrigens vorher auch anschauen, wenn man die kleine Box mit den Taggingvorschlägen rechts oben aufklappt.

Danke für Hinweis auf Multipolygon-Relation.https://wiki.openstreetmap.org/wiki/DE:Relation:multipolygon

Doch nun zurück zum iD

Gegen die Fehlschreibung Standard/Standart wird von Sprachfreunden seit Jahrzehnten erbittert angekämpft – mach dir keine Hoffnungen, das hier ausrotten zu können :slight_smile:

Damals in desd (falls noch jemand das Usenet kennt) hatte „Standart“ exakt drei Bedeutungen, mit denen Fehlschreiber genüsslich aufgezogen wurden: 1. die Standarte (Feldzeichen), 2. eine spezielle Ausführung eines Standes (auf einem Markt oder einer Messe), 3. eine spezielle Weise zu stehen (z.B. auf einem Bein).

–ks

Ich habe es nicht ausprobiert, aber das klingt tatsächlich nach einem Scherz:
“Add fix to tag real nonsquare buildings with nonsquare=yes tag (#6332)”
Ich finde schon den entsprechenden Test absurd, weil ich in einem Gebaude aufgewachsen bin, in dem aufgrund seltsamer Vorschriften eben nicht alle Winkel rechtwinklig waren. Als das in JOSM eingeführt wurde habe ich es gleich abgeschaltet.
Aber jetzt auch noch ein Tag nonsquare=yes dran kleben? Für was sind diese rechten Winkel denn so wichtig?

Hast du dafür konkrete Beispiele?

Ja, das wurde bereits heftig diskutiert. Es ist nun mal so, dass viele Couchmapper Gebäude gerne mit der q Taste rechtwinklig machen, auch wenn sie vielleicht im RealLife nicht 100% rechtwinklig sind.

Dieser Thread macht einen grundsätzlichen Mangel deutlich. Es fehlt an einem verbindlichen Tagging-Standard der 90-95 Prozent aller Tags umfaßt. Ein solcher Goldstandard schafft dann Klarheit für die Mapper, die Editorentwickler und die Datenauswerter. Aber an dieses Thema traut sich der Vorstand nicht heran …

Also hier mal meine sachliche Rückmeldung zu den Fehlermeldungen, die es im iD tatsächlich bereits seit der vorhergehenden Version gibt. Ich empfand sie als durchaus sinnvoll. Ob sich durch die gestern online gestellt nächste Version daran Veränderungen gibt, kann ich noch nicht erkennen.
Folgende Beobachtungen:
Bearbeite ich irgendwo einen Feldweg, weil ich z.B. den Kurvenverlauf korrigiert, macht mich der iD vorm Abspeichern darauf aufmerksam, dass dieser Weg an einer anderen Stelle (die ich gar nicht betrachtet habe) einen Bach kreuzt ohne dass dort eine Furt, eine Brücke oder ein Tunnel eingezeichnet wurde. +1!
Auch werde ich darauf aufmerksam gemacht, wenn ein Weg ein Gebäude kreuzt ohne dass dort etwas wie “tunnel=building_passage” oder “covered=yes” eingetragen wurde. +1!
Auch prüft inzwischen der iD inzwischen, ob eine Linie auch eine Rolle in einer Multipoligon-Relation zugewiesen bekommen hat (inner oder outer). +1

So nun mal meinen Kommentar:

  1. waterway=riverbank wird in natural=water und water=river geändert. Beides ist richtig - warum dann ändern? Dann erst einmal Klarheit im WIKI schaffen und es ändern (allgemeines Problem Nummer 1 in OSM-WIKI).
  2. Ein Weg unter building=roof, layer=1 ist kein Fehler - oder doch?
  3. name_1 und so weiter ist im WIKI als falsch eingetragen, wird aber von iD bei weiteren name=* verwendet
    https://www.openstreetmap.org/way/29021735
  4. amenity=dentist wird als veraltet angezeigt und zu healthcare=dentist geändert - ganz neu im WIKI vom Mai 2019
  5. dito bei doctors

Warum wird nicht erst das WIKI konsequent geändert, dann alle “veralteten” Schlüssel und Werte automatisch ändern?

So kann ich weiterhin waterway=riverbank oder amenity=doctors eintragen - ist ja nicht falsch (soll sogar beides verwendet werden) und trage wieder “veraltete” Daten ein.

Viel Spaß habe ich nicht mehr - man kann ja alles “ignorieren” - bringt das uns weiter?
oder
man lässt alles “reparieren” - das könnte doch automatisch gemacht werden. Bis wieder einer nach WIKI einträgt …

ich würde das mal nicht allein am Couchmapper festmachen, auch Reallife ist nicht immer ersichtlich, ob ein Gebäude rechteckig ist. Wer schleppt schon einen großen Winkel mit sich herum und legt diesen an Gebäudeecken an?
Was am rechten Winkel wichtig ist? Nun, ein großer Teil an Gebäuden hat nun Mal rechteckige Grundrisse, die sich Freihand nicht so exakt mappen lassen. Daher halte ich eine Funktion die ein Viereck automatisch zu einem Rechteck macht genauso sinnvoll wie ein nosquare=yes genau dieses verhindert.

Hallo,

es hat mich überrascht, dass der Release so plötzlich kommt.

Naja, aber alle Änderungen, die seit dem Release erfolgen, sind nur auf der Entwicklungsinstanz verfügbar. Zur Bug-Suche ist diese IMHO besser geeignet.

Dem stimme ich ausdrücklich zu und gehe deswegen nicht weiter darauf ein.

Ich finde es sehr gut, dass es endlich Validierungen in iD gibt. Ein Feature, das seit sechs Jahren gefordert wird. Das aktuelle Problem sind bestimmte Validierungsregeln, die dazu verwendet werden, das Mapping in OSM in eine bestimmte Richtung zu lenken. Frederik hat das vor ein paar Wochen auf der Mailingliste Talk-de erläutert.

Ich sehe übrigens, dass Prince Kassad mit gutem Beispiel vorangeht und schon den ersten Bug gefunden und gemeldet hat.

Gerne:

  • Also zum einen die von mmd angedeuteten Regeln, die “veraltete” Tags finden. Das ist ein mechanischer Edit durch die Hintertür. Ein Teil ist berechtigt, aber manche sind es nicht.
  • nonsquare=yes, damit die Validierungsregel “Gebäude ist nicht rechtwinklig” nicht anschlägt. In dem Fall gab es Protest von Seiten der Community, der ignoriert worden ist. Auf Einladungen, sich an der Diskussion auf der Mailingliste zu beteiligen, ist nicht eingegangen worden. (Das ist angesichts der Äußerung von Bryan Housel, dass er von OSM die Schnauze voll habe und das Wiki und die Mailinglisten deshalb ignoriere, nicht verwunderlich)
  • highway=track als “unmaintained track road” zu bezeichnen, obwohl Bryan dafür wiederholt Widerspruch erntet.

Beim Mappen sind mir folgende Dinge noch nicht begegnet, aber sie sind fragwürdig:

  • Objekte mit einem wikidata-Tag (einschließlich :wikidata=) lassen sich nur eingeschränkt bearbeiten.
  • Validierungsregeln, die sich an Straßen/Wegen in Gebäuden stören. Das habe ich noch nicht endgültig durchprobiert und vermutlich gibt es da auch kein “richtig” und “falsch”, sondern eher ein “so wird es hier gemacht” und “so wird es dort (anderes Land) gemacht”.
  • Ways mit einer zu hohen Anzahl an Nodes
  • Wie auch JOSM hat iD bei vielen Regeln automatische Reparaturen. Die sind in einer Reihe von Fällen unstrittig, z.B. das Ersetzen von veralteten Tags ist oft eine 1:1-Ersetzung. Manch andere automatische Reparatur kann aber auch mehr schaden als nützen.

Viele Grüße

Michael

Nur mal so am Rande… Es gibt auch Gebäude, die nur vermeindlich auf den ersten Blick rechteckig sind… Das Gebäude, wo u.a. die Amtsverwaltung hier bei mir in Straupitz sitzt (https://www.openstreetmap.org/#map=19/51.90989/14.12046&layers=N), ist in 2 Achsen um ca. 60cm außerm Winkel (wenn ich mich richtig erinnere). Das wissen heute recht wenige Leute… Ich hatte in meinem ersten Berufsleben in der Nachwendezeit frisch ausgelernt, dort den Dachstuhl mitgebaut.

Für OSM spielt diese leichte Schiefwinkligkeit aber keine Rolle…

Sven