Sind die neuen Validierungsregeln des iD-Editors wirklich gut?

Hallo,

die Entwickler des iD-Editors schrauben gerade recht stark an den neuen Validierungsregeln zu Gange. Da der iD-Editor als Standard-Editor auf openstreetmap.org in Verbindung mit unerfahrenen Nutzern einen starken Einfluss auf das Mapping hat, verfügen seine Hauptentwickler an großem Einfluss, was die Gestaltung der Inhalte von OpenStreetMap angeht. Ich denke, dass Macht Kontrolle bedarf und wir als Mapper uns die Zeit nehmen sollten, die neuen Validierungsregeln zu prüfen. Es sind sicherlich kontroverse oder fragwürdige Regeln darunter, die noch keiner kritisch hinterfragt hat. Manche ergeben möglicherweise nur in bestimmten Regionen Sinn oder erklären in bestimmten Gegenden etabliertes Mapping für unerwünscht. Diese Kontrolle sollte geschehen, bevor der nächste iD-Release erfolgt. Schon jetzt sind umstrittene (u.a. eine, die ich als Aprilscherz verwendet hätte) Regeln in iD enthalten.

Auf openstreetmap.org ist nur der letzte stabile Release verfügbar. Um richtig zu testen, müsst ihr die Entwicklunginstanz nehmen, mit der ihr die Daten in der Live-Datenbank bearbeiten könnt.

Mit dem Ausrufezeichen am rechten Rand, könnt ihr die Validierung manuell aktivieren und auch auswählen, ob sie nur die bearbeiteten oder alle Objekte kontrollieren soll. Am besten, ihr mappt einfach mal einen ganzen Tag lang mit iD, sofern ihr nicht besonders Anspruchsvolle oder unlösbare Aufgaben wie gewisse Relationsbearbeitungen machen wollt.

Wenn ihr etwas findet, könnt ihr entweder auf GitHub ein Ticket anlegen oder hier schreiben. Eure hier auf Deutsch veröffentlichte Kritik übersetze ich gern ins Englische (Unterstützer sind willkommen).

Viele Grüße

Michael

Bevor man die Validierungsregeln prüft, sollte man erst mal grundsätzlich prüfen, wer diesen Editor zum Standarteditor gemacht hat und wieso. Gibt es dazu irgendwelche beschlüsse von der OSM-Foundation?

Da ich diesen Editor nicht nutze und auch nicht kenne, kann ich zu den Validierungsregeln nichts sagen.

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.