Sind die neuen Validierungsregeln des iD-Editors wirklich gut?

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

Lässt ändern? Wenn ich das richtig gesehen habe, kann man nicht ändern lassen bekommt allerding teiweise Hinweise, was man ändern kann?

Man kann allerdings einstellen, was überprüft werden soll. Alles im Kartenaauschnitt zu wählen, wird sicherlich frustrierend sein., da sehr viele Fehlermeldungen. Da kann man dann im Grunde nur ignorieren. Wenn man die Prüfung sich auf seine eigenen Bearbeitungen beschränken lässt - und das war bei mir automatisch so voreingestellt, kommen kaum Fehlermeldungen. Und die, die bei mir kamen, waren meist hilfreich, ließen mir aber in der Regel die Wahl, sie zu ignorieren oder meine Änderung noch einmal zu überarbeiten.

Es gibt rechts von der Meldung ein Schraubenschlüsselsymbol. Wenn man das anklickt, wird repariert. Das gleiche Symbol gibt es auch zum “Reparieren” aller Meldungen. Also eigentlich genau wie bei JOSM. Die Meldungen selbst sind teils etwas kurios:
Da steht dann zum Beispiel “Dr. Rinne hat veraltete Eigenschaften”. Vielleicht ist aber auch nur die Übersetzung missglückt?

dito
Ich hatte bislang einmal den Fall, dass es ohne Änderung nicht weitergegangen wäre, kann mich aber nicht mehr erinnern was es war.

Ja, ist korrekt - immer den aktuellsten Stand zum Testen findet man weiterhin auf http://preview.ideditor.com/master
Ich meinte eben nur, das nun der grosse Software-Änderungssatz an Validierungsregeln nun tatsächlich auch als stabiles Release V2.15 rausging…

Bezüglich der eigentlichen Frage “Sind die neuen Validierungsregeln des iD-Editors wirklich gut?” ist mir eine Ersetzungsempfehlung aufgefallen, bei der ich nicht so recht weiss, ob sie sinnig ist. Bei einem vorhandenen

leisure=track
sport=running

wird vorgeschlagen ein highway=footway anzuhängen, damit es also zu

leisure=track
sport=running
highway=footway

wird.

Wenn du auf den Eintrag klickst, wird Dr. Rinne ausgewählt. Du kannst dann im linken Panel auf das “i” neben der Fehlermeldung klicken, um eine Erläuterung zu erhalten. Wahrscheinlich fehlt der Praxis ein healthcare=*.

Zwischenzeitlich habe ich auch Sachen gefunden:

Bezieht sich das auf eine Linie oder eine Fläche?

Gute Frage. Habe soeben nach unterschiedlichen Beispielen gesucht.
Als Linie:
https://www.openstreetmap.org/way/173313008
Als Fläche mit area=yes
https://www.openstreetmap.org/way/153292480
Als Fläche ohne area=yes
https://www.openstreetmap.org/way/516501138

iD fragt bei allen drei Beispielen, ob man highway=footway anhängen möchte.

Meiner Meinung nach nicht mal das, da “beachvolleyball” surface=sand impliziert, zumindest ist mir keine andere Oberfläche bei Beachvolleyball außer Sand bekannt.

waterway=riverbank
ID sagt: veraltet, ersetzen durch natural=water + water=river

Wiki sagt:
Do not convert from waterway=riverbank to natural=water tagging scheme […]

Im Wiki nachzuschauen, ist schnell getan. Wirklich Substanz hat ein Verweis auf das Wiki aber nur, wenn man auch nachschaut, wer besagte Ausage dort hineingeschrieben hat. Sonst sitzt man bloß denen auf, die über Änderungen im Wiki Änderungen im Tagging erreichen wollen.

Leute, nochmal die Erinnerung: schaut euch eure POIs an. Das sind teilweise heftige Fehler in den Upgrade-Vorschlägen drin, die möglichst schnell erkannt und behoben werden sollten.

Gerade aufgemacht: https://github.com/osmlab/name-suggestion-index/issues/2652

Auch ganz praktisch ist folgende Übersicht: http://osmlab.github.io/name-suggestion-index/brands/

Quincy Morgan hat die Änderung abgelehnt. Ich habe das jetzt auf der Mailingliste Tagging thematisiert. In der dortigen E-Mail habe ich auch gezählt, wie oft die Kombination public_transport/railway=platform + highway=footway überhaupt vorkommt. Weltweit macht sie 0,4 % aus.

Dieser Vorschlag ist umgesetzt worden.

Neu gefunden:

https://www.openstreetmap.org/way/102715762 wird mit “Weingut Otto Menold könnte eine private Information enthalten” bemängelt. Gemeint ist damit die Telefonnummer. Das Gebäude hat außer building=house und name=* sonst nur Kontaktangaben. Für mich ist das eher ein unzureichend getaggter POI, kein Datenschutzskandal.

[offtopic]

Ganz ehrlich, willst Du mir hier den Mund verbieten und meinen Post entfernen lassen? Das hat mit einem offenen Projekt nix mehr zu tun. Den Shitstorm, weil ich es gewagt habe, das Thema an dieser Stelle noch mal hochzubringen, lasse ich mir ja noch gefallen. :sunglasses:

Aber die Aussage, den Post entfernen zu lassen, ist schon ein starkes Stück [/offtopic]

+1

und als 2. nervt es, dass ID jetzt auch über kreuzende Strassen / Wasserwege meckert.

in gefühlt 90 % der Fälle animiert das nur dazu, irgendeinen Blödsinn in die Datenbank zu schreiben.

man kann in der Regel nicht wissen, wie die Situation jeweils gelöst ist - ausser man hat wirklich vir Ort nachgesehen.

Standart ist, dass Kreuzungen von Wegen so ausgeführt sind, dass man trockenen Fusses drüberkommt. ist dem nicht so, kann man den Spezialfall als Furt taggen

aber wozu brauchen wir mehrere tausend Brücken / Rohre etc in der Datenbank, die nur erraten werden?

entweder mappt man das genau mit Nutzwert. oder msn lässt es bleiben.

nix einzutragen kann also kein Fehler sein.

Naja, nur das zu mappen was man auch tatsächlich weiß, sollte eigentlich jeder Mapper machen…
Wenn ich ne Warnung bekomme und es nicht definitiv weiß, lasse ich Warnung Warnung sein…

Sehe ich auch so. Abgesehen davon sind bei mir in der Gegend die Esri-Luftbilder inzwischen so genau, dass man bei vielen Wegen sogar erkennen kann, ob der Weg per Brücke über einen Bach geführt wird oder Bach mit einem Rohr unter dem Weg durch.
Ich finde es richtig, dass die iD-Validierungsfunktion auf Herz und Nieren geprüft wird. Grundsätzlich möchte ich aber anmerken, dass hier im Forum in der Vergangenheit stets beim iD kritisiert wurde, dass er halt keine Validierung macht. Ich finde es somit grundsätzlich einen enormen Fortschritt, dass dies jetzt geändert wurde.

Sollte. Aber wieviele Bäche mit durchgehend layer=-1 sind mir schon begegnet, nur damit es keine Fehlermeldungen mit kreuzenden Wegen gibt!

Das ist die richtige Einstellung, und ein Editor, der bewusst einfach gehalten ist und sich an Anfänger richtet, sollte auch darauf hinweisen, etwa „Wenn du nicht weißt, was da genau ist, dann ignoriere diese Warnung. Bitte trag nichts auf Verdacht ein, nur damit eine Warnung verschwindet“.

Das stößt mir ein bisschen übel an der Entwicklung von iD auf: Man kann jetzt ganz einfach Sachen in die Datenbank bringen, für deren Erfassung man eigentlich ein gewisses Hintergrundwissen braucht. Zum Beispiel Abbiegebeschränkungen. Natürlich ist die Möglichkeit im Editor nicht verkehrt, aber der Mapper sollte darauf hingewiesen werden, dass man das nur macht, wenn man auch verstanden hat, was man da tut und welche Auswirkungen das hat. Ich denke da an meinen Spezialkollegen hier am Ort, der turn restrictions von Einfahrten auf Radwege gesetzt hat, ohne zu bedenken, dass er damit auch Radfahrern das Einbiegen in den Radweg verbietet.

–ks