Sind die neuen Validierungsregeln des iD-Editors wirklich gut?

Nakaner · 2019-05-28T09:22:38.000Z

Lukas458:

Wurde hier eigentlich schon erwähnt, dass der iD-Validator neuerdings auch vorschlägt, kerb=lowered an highway=crossing zu kerb=lowered + barrier=kerb zu machen?
siehe auch https://github.com/openstreetmap/iD/issues/6440
falscher geht es ja wohl nicht oder?
Begründung der iD-Leute: kerb=* an highway=crossing sei ja falsch (wurde aber im den Preset für crossing jahrelang vorgeschlagen), da kerb=* ja wohl ein Untertag von barrier=kerb sei. Man solle stattdessen zwei barrier=kerb nodes für jeden Überweg erstellen, voll sinnvoll, vor allem wenn die Gehwege nicht separat kartiert sind. Aber klar, die kann man ja dann direkt gleich mit ergänzen

Ich fühle mich nicht kompetent genug, um das zu beurteilen. Möchtest du selbst auf der Mailingliste Tagging nachfragen oder soll ich das tun und dort weitere Meinungen einholen?

Elefant_aus_Wuppertal · 2019-05-28T14:22:41.000Z

Nakaner schrieb: Möchtest du selbst auf der Mailingliste Tagging nachfragen oder soll ich das tun und dort weitere Meinungen einholen?

das kannst du gerne machen, ist eine gute Idee. Übrigens habe ich gerade herausgefunden, dass die ganze Sache wohl auch noch damit zusammenhängt, dass die iD-Leute (puh, ja, wer ist das jetzt, unter anderem wohl dieser User: https://github.com/quincylvania)),
der Meinung sind, dass kerb=* halt gar nicht an highway=crossing gehöre. Siehe dazu auch den geschlossenen Issue https://github.com/openstreetmap/iD/issues/6078
Aber gut, das erwähnte ich bereits.

Prince_Kassad · 2019-05-28T19:13:36.000Z

Was mir nicht gefällt:

iD entfernt gnadenlos highway=platform, obwohl public_transport=platform bis dato noch nicht auf der Standardkarte gerendert wird
iD geht automatisch davon aus, dass jeder Parkplatz mit parking=underground layer=-1 sein muss, auch dann, wenn es sich um ein Gebäude handelt und lediglich unter dem Gebäude drunter geparkt wird, will er trotzdem das Gebäude selbst mit layer=-1 taggen (was dann selbst ein Fehler wäre).
Volksbanken in Deutschland werden automatisch mit der österreichischen Volksbank verlinkt. Das ist schon als Bug auf Github gemeldet.

Elefant_aus_Wuppertal · 2019-05-28T19:47:07.000Z

ich finde, mit dem aktuellen Release ist der Editor endgültig außer Kontrolle geraten. Aber gut, jetzt kommen wieder diejenigen, die sagen, alles wurde ja vorher (so) abgesprochen.

Prince_Kassad · 2019-05-28T19:51:48.000Z

Netto wird übrigens automatisch mit dem Hundenetto verlinkt. Na dann…

Elefant_aus_Wuppertal · 2019-05-28T19:52:27.000Z

snip -

dieterdreist · 2019-05-28T20:52:05.000Z

Prince Kassad:

Netto wird übrigens automatisch mit dem Hundenetto verlinkt. Na dann…

klar hat das noch Kinderkrankheiten, aber gerade in so Fällen wie bei den beiden Nettos kann man mit so einem System überhaupt erst Hoffnung haben, dass man die bald irgendwann flächendeckend sauber zugeordnet haben wird. Mit den Logos funktioniert es einfach und ohne dass man Supermärkte studiert haben muss.

Tordanik · 2019-05-28T21:16:39.000Z

Lukas, danke fürs Teilen der beiden Issues bzgl. kerb. Es ist gar nicht so einfach, den Überblick zu behalten bei all den iD-Kontroversen in letzter Zeit.

Im Übrigen muss ich dir in der Taggingfrage auch absolut Recht geben: highway=crossing + kerb=* ist recht etabliert, im Wiki dokumentiert und hat knapp 100k Verwendungen. Daran ist nichts korrekturbedürftig.

tux67 · 2019-05-31T09:38:53.000Z

Hi,

bin hier gerade auch auf so einen Fall gestossen:
https://www.openstreetmap.org/way/687835229
Wenn man das in iD aufmacht, dann kommt die Meldung “Becken hat veraltete Eigenschaften”.
Die Eigenschaften stimmen aber m.E. mit der Wiki Dokumentation überein.
Liege ich da falsch?

Gruß
tux67

chris66 · 2019-05-31T11:09:37.000Z

Nö, ich denke ID liegt da mal wieder falsch.

Mammi71 · 2019-05-31T11:50:36.000Z

Ich vermute Mal, dass iD das durch natural=water + water=basin ersetzen möchte. Hatte Grad das gleiche mit landuse=reservoir.

tux67 · 2019-05-31T12:07:41.000Z

Mammi71:

Ich vermute Mal, dass iD das durch natural=water + water=basin ersetzen möchte. Hatte Grad das gleiche mit landuse=reservoir.

yup - was ist das - Bananensoftware Ansatz?
Jeder Anfänger glaubt natürlich dem Editor und klickt auf “fix”.

Gruß
tux67

Mammi71 · 2019-05-31T12:31:46.000Z

Beim landuse=reservoir steht im deutschen Wiki ein deprecated während im engl. Wiki seit Jahren zw. deprecated und in use gewechselt wird.
Beim basin ist dies jedoch als gleichberechtigt beschrieben.

pyram · 2019-05-31T17:32:06.000Z

tux67:

bin hier gerade auch auf so einen Fall gestossen:

Ebenfalls. Da bin ich wohl zu spät dran Wollte gerade fragen, ob es an mir vorübergegangen ist, dass landuse=basin veraltet sei:
https://www.openstreetmap.org/changeset/70781901
(war mir aufgefallen, weil review_requested=yes)

Elefant_aus_Wuppertal · 2019-06-02T15:19:40.000Z

Tordanik schrieb: Im Übrigen muss ich dir in der Taggingfrage auch absolut Recht geben: highway=crossing + kerb=* ist recht etabliert, im Wiki dokumentiert und hat knapp 100k Verwendungen. Daran ist nichts korrekturbedürftig.

Das sehe ich genauso. Ich habe im iD-Issue #6440 mal zwei Vorschläge gemacht, entweder highway=crossing + kerb=* ganz ignorieren oder den Vorschlag machen, zwei einzelne barrier=kerb Nodes zu setzen (wenn es einen kreuzenden Way gibt), aber auf jeden Fall nicht barrier=kerb in die Mitte eines highways, da wo die Überwegsmitte ist…

wobei man mit dem zweiten Vorschlag eigentlich schon wieder iD nachgeben würde. Wenn beide bzw. alle involvierten Bordsteinkanten eines Überwegs die gleiche Beschaffenheit haben, dann ist an kerb=* auf highway=crossing meiner Meinung nach wirklich nichts auszusetzen. iD behandelt kerb=* als wäre es ein reines Untertag von barrier=kerb.

-genommen von der Wikipage von kerb=*:
“Assuming both sides of the crossing are the same this could be added to the crossing node.”

UPDATE: iD-Issue #6440 wurde geschlossen, mit dem nächsten Release scheint der Bug also behoben zu sein. In welcher Form genau, bliebe dann zu kontrollieren. (ich traue dem Braten noch nicht ganz ;))

geri-oc · 2019-06-02T15:48:04.000Z

Ich habe iD für schnelle einfache Änderungen genutzt. Jetzt sagt er mir zu oft etwas falsches an, was ich korrigieren sollte:

shop=boutique sollte besser shop=clothes werden. Was ist aber wenn nicht nur Kleidung verkauft wird?

Wenn dann solche Änderungen im WIKI eingetragen werden https://wiki.openstreetmap.org/w/index.php?title=Tag:shop%3Dboutique&diff=next&oldid=1826057
ist es verständlich.

Lieber werfe ich JOSM an - iD sagt mit zuviel “Unsinn”.
Was allerdings für “Unsinn” mit den Daten passiert, zeigt

pyram:

Wollte gerade fragen, ob es an mir vorübergegangen ist, dass landuse=basin veraltet sei:
https://www.openstreetmap.org/changeset/70781901

kartonage · 2019-06-02T16:58:56.000Z

geri-oc:

shop=boutique sollte besser shop=clothes werden. Was ist aber wenn nicht nur Kleidung verkauft wird?

Theoretisch sollte der Benutzer das ja überprüfen können und gegebenenfalls *shop=jewelry *oder irgendetwas anderes draus machen. Oder bei Ungenauigkeiten einfach unberührt lassen.

Praktisch werden aber sicherlich so einige Nutzer einfach komfortabel ohne Überprüfung den “Fix All”-Klick machen. Gibt da jetzt schon so Kandidaten, die scheinbar sehr intensiv den Gebrauch davon machen. Überprüft ob das Objekt überhaupt existiert, wird da sicherlich eher weniger. Dann wird da einfach shop=clothes draus.

Elefant_aus_Wuppertal · 2019-06-02T19:02:13.000Z

Es wäre gut, wenn iD wenigstens bei einigen dieser Sachen mal so ein Feld hinzufügen würde mit Fragen wie “bevor das aktualisiert wird: Hast du auch geprüft, ob das Objekt/dieser Laden dort existiert?”
das könnte man zwar als User immer noch schlicht “abnicken”, aber diese “ein-Klick-Philosophie” wäre wenigstens ein bisschen ausgebremst.

dieterdreist · 2019-06-02T20:38:18.000Z

m.E. sind das in der jetzigen Form verkappte automatische Edits, eigentlich sollte man die DWG anschreiben, damit sie den Editor erstmal blockt bzw. auf eine ältere Version revertet.

Wulf4096 · 2019-06-02T21:05:06.000Z

dieterdreist:

eigentlich sollte man

Dann mach.