[erledigt] Proposed features

Parzelle13 · 2018-10-09T12:04:55.000Z

Hallo,

was hält man hier von solchen Änderungen?

CS-Kommentar: #fastag #traffic_signs Apply traffic_sign:direction tag to avoid problems with new iD editor as an agreement on tagging list

Beispiel: https://www.openstreetmap.org/way/24475466/history#map=18/50.86794/6.19557

https://wiki.openstreetmap.org/wiki/Proposed_features/Extended_traffic_signs_tagging

Gruß

dieterdreist · 2018-10-09T12:20:15.000Z

Direction ist eigentlich anders definiert, und das kommt mir auch solider vor: https://wiki.openstreetmap.org/wiki/Key:direction
also mit Himmelsrichtungen als value.

SimonPoole · 2018-10-09T12:23:14.000Z

Ich hab keine Ahnung was das soll.

Ja, es gibt eine Diskussion auf tagging bezüglich traffic_sign:forward und traffic_sign:backward nodes auf highways und es gab ein Konsens, dass es nicht ne wahnsinnig gute Idee ist, dass wir ohne Not* 3 Toplevel tags für Strassenschilder haben, aber dass ist dann auch mehr oder weniger der aktuelle Stand (neben irgendein Diskurs über Relationen den ich nicht verfolgt habe).

die Argumentation ist vermutlich, dass man so Vorder- und Rückseite eines Schildes auf den gleichen Node taggen kann, aber das kann man auch anders lösen.

mueschel · 2018-10-09T12:26:06.000Z

Davon halte ich gar nichts. Das sieht mir nach einem nicht diskutierten mechanical edit aus, der komplett revertiert werden sollte.
https://www.openstreetmap.org/changeset/63325786

Er bezieht sich wohl auf diesen Post hier:
https://lists.openstreetmap.org/pipermail/tagging/2018-October/039580.html

Das ganze Schema ist schon kaputt, wenn Schilder für zwei Fahrtrichtungen an der gleichen Straße stehen.

mueschel · 2018-10-09T12:28:03.000Z

SimonPoole:

dass es nicht ne wahnsinnig gute Idee ist, dass wir ohne Not 3 Toplevel tags für Strassenschilder haben

Meinst du traffic_sign, traffic_sign:forward und traffic_sign:backward?
Das Tag wird direkt an Wegen verwendet, und wenn unterschiedliche Schilder in beiden Richtungen stehen (genauso wie bei maxspeed) - wie solte man diese sonst unterscheiden, außer mit eben jenen Suffixen?

SimonPoole · 2018-10-09T12:31:21.000Z

mueschel:

SimonPoole:

dass es nicht ne wahnsinnig gute Idee ist, dass wir ohne Not 3 Toplevel tags für Strassenschilder haben

Meinst du traffic_sign, traffic_sign:forward und traffic_sign:backward?
Das Tag wird direkt an Wegen verwendet, und wenn unterschiedliche Schilder in beiden Richtungen stehen (genauso wie bei maxspeed) - wie solte man diese sonst unterscheiden, außer mit eben jenen Suffixen?

Noe (also ja, aber die Verwendung als way node, nicht auf dem way), siehe https://wiki.openstreetmap.org/wiki/Key:traffic_sign#As_part_of_a_way

mueschel · 2018-10-09T12:59:29.000Z

SimonPoole:

Noe (also ja, aber die Verwendung als way node, nicht auf dem way)

Auch da bräuchte man wohl Work-arounds, wenn man auf :forward und :backward verzichten will. Es kommt doch recht häufig vor, dass der gleiche Pfahl für zwei Schilder in entgegengesetzer Richtung verwendet wird (z.B. Überholverbot und Aufhebung davon in der Gegenrichtung).

dieterdreist · 2018-10-09T13:00:24.000Z

ich halte nichts davon, “traffic sign” auf Wegen zu taggen. Das ist ja in jedem Fall eine Interpretation, weil die Schilder nicht auf der Länge des Weges sind, sondern punktuell. Die Interpretation auf dem Weg ist als osm tags völlig ausreichend, die Schilder können eine Ergänzung darstellen, aber das würde ich dort machen, wo auch die Schilder stehen. Die Richtung ergibt sich von selbst wenn man die Schilder an den Rand stellt, und nicht mitten auf die Straße.

Von daher bin ich klar gegen mechanische Edits, die die aus meiner Sicht fragwürdige Praxis sozusagen global implementieren. Um so mehr, falls es ein nicht diskutierter mechanischer Edit ist.

SimonPoole · 2018-10-09T15:13:38.000Z

mueschel:

SimonPoole:

Noe (also ja, aber die Verwendung als way node, nicht auf dem way)

Auch da bräuchte man wohl Work-arounds, wenn man auf :forward und :backward verzichten will. Es kommt doch recht häufig vor, dass der gleiche Pfahl für zwei Schilder in entgegengesetzer Richtung verwendet wird (z.B. Überholverbot und Aufhebung davon in der Gegenrichtung).

Naja man könnte durchaus tags für die Vorderseite und Rückseite machen also etwas in der Art

traffic_sign=yes
sign:forward=…
sign:backward=…

Auch wenn forward und backward sprachlich so nicht ganz passen. kann man so die bestehenden Wegumkehrautomatismen in den Editoren nutzen.

chris66 · 2018-10-09T15:51:17.000Z

dieterdreist:

ich halte nichts davon, “traffic sign” auf Wegen zu taggen.

Ist aber nun mal gängige Praxis. (148000 ways mit traffic_sign).

Für die wenigen Fälle wo es nur in einer Richtung gilt kann man doch problemlos traffic_sign:forward=* taggen…

mueschel · 2018-10-09T16:24:49.000Z

Wir scheifen ab - hier ging es ja eigentlich erst einmal nicht um das beste Tagging, sondern um einen nicht wirklich diskutierten, undokumentierten, massenhaften Edit, siehe
https://www.openstreetmap.org/changeset/63325786

geri-oc · 2018-10-09T17:25:07.000Z

mueschel:

Wir scheifen ab - hier ging es ja eigentlich erst einmal nicht um das beste Tagging, sondern um einen nicht wirklich diskutierten, undokumentierten, massenhaften Edit, siehe
https://www.openstreetmap.org/changeset/63325786

Finde ich auch - es ist ja nicht nur ein Gebiet betroffen - es wurde weltweit durchgeführt.

Es betrifft auch Änderungssätze von mir, die ich mit JOSM Plugin mache, die nun einfach geändert wurden. Wenn es dokumentiert ist das es forward und backward ist kann nicht in direction geändert werden, da dies dann den Sinn des Schlüssels / Wertes verfälscht.

Ich bin für ein Revert aller seiner diesbezüglichen Änderungen. Ich habe bisher noch nichts unternommen außer seinen CS zu kommentieren.

EDIT: Schon der Kommentar es für den neuen iD zu ändern sollte den Revert bestätigen.

PS: Ich verstehe OSM nun langsam nicht mehr so richtig: Da wird maxspeed:source gegen maxspeed:type ausgespielt oder Editoren verwenden einfach ihre eigenen Vorstellungen, jeweils nur einen Schlüssel am Weg zu ändern, ohne die Gesamtheit vor Ort zu berücksichtigen.
Wo ist das “vor Ort erfassen Prinzip” geblieben? Da werden Adressen gelöscht und an Garagengebäude gemappt, weil es im WMS so angezeigt wird. Oder es werden Hausnummer geändert, die vor Ort tatsächlich nicht mit dem WMS übereinstimmen.

yopaseopor · 2018-10-09T18:48:03.000Z

Sorry but I don’t speak German so I try to explain me in my English

This edition is about the discussion done in tagging list http://gis.19327.n8.nabble.com/Re-Traffic-sign-direction-tagging-td5923137.html about the subkeys forward and backward (my favourite option, this was not an easy decision for me but I have prefered the enable in iD and close the discussion) and the issues of iD to add the possibility to edit traffic signs. iD was big trouble to make able these editions. So in the list it was discussed the solution (change :backward /:forward subkey for traffic_sign:direction=* as the traffic_signals) , and also the iD issue solved and closed (you can see it in https://github.com/openstreetmap/iD/pull/5333 ).

The discussion ended (many days without any message in reference to that topic)

So I said I will do all the modifications on the environment: presets, styles, taginfo projects, traffic_signs_maps… . And also there was no more messages about that.
Also I start to modify the “old scheme” traffic signs to the new scheme.
I have used overpass to make only these modifications - with JOSM and checking via style traffic signs were correct:

-traffic_sign:forward/backward=* > traffic_sign=* & traffic_sign:direction=forward/backward/both.

I try to answer message by message

key direction

Key direction is not a good solution. Traffic signs are facing in the direction of the way you are driving. This direction can change due to the curves and straight lines. Some nodes are to NE, some to SW, some to 95 from the North, some to…
For this reason it is better to have its own key: traffic_sign:direction=* . And make relative to the way because the traffic sign is for the “road”, not for the street, not for other utility. And make it simple: the direction you are driving (it would be the same direction the way is drawn in OSM, as rivers)

About the way to make the editions

Editions were not “mechanical”. I have made 55 changesets with 16470 nodes (it took two days, not two minutes). If the editions were all mechanical I would not make so many changesets.
I change the tags as explained above and check if the icons were appearing . The vast majority do it (because in overpass I remove the way and relation part - I don’t believe to tag the traffic signs IN the way but ON the way).

About the Big change

The scheme does not have big change. Subkey is located now as a value on a new subkey called traffic_sign:direction. As explained above this change has done because the problems with the iD editor. To avoid it it have been a solution: the same as traffic_signals, with the direction suffix.

About not to tag the traffic signs

Ok. Can we delete all the Stops? Can we delete the give_ways? The city limits? I don’t know…but what is the problem to tag the reality…as it is?

About the obviousity

There is nothing obvious in OSM if you want to tag specifically. If the information is well tagged there is no problem to render the traffic signs (all these keys are rendered by kendzi3D , the JOSM style, and the leaflet traffic signs map).

I am only say I’m sorry for the errors…but I don’t let go this. I will start again the discussion to get a complete scheme for the traffic signs.You can revert all my work but it is better to fix only the broken items, as the scheme is working as you can check with styles, presets, maps, etc.

yopaseopor

streckenkundler · 2018-10-09T19:29:41.000Z

Guten Abend,

Es ist Scheiße, die Daten an den Editor anzupassen. (Ich scheibe es so, wie ich es sehe und wähle das harte Wort für die weiche Masse bewusst!!)

geri-oc:

Ich bin für ein Revert aller seiner diesbezüglichen Änderungen. Ich habe bisher noch nichts unternommen außer seinen CS zu kommentieren.

+1

geri-oc:

EDIT: Schon der Kommentar es für den neuen iD zu ändern sollte den Revert bestätigen.

Dafür erst recht ein +1

Sven

Nachtrag: Ach ja, auch ein CS ausgewählt und kommentiert… https://www.openstreetmap.org/changeset/63325225. Inhaltlich träfe jedes dieser CS zu…

MitteloberrheinischerWaldameisenschreck · 2018-10-09T21:16:24.000Z

???

Verstehe ich richtig, dass das bewährte traffic_sign:*ward=DE:x in traffic_sign=x + traffic_sign:direction=*ward geändert werden sollte? Und wie hätte es werden sollen, wenn Vorder- und Rückseite des Mastes (unterschiedlich) beschildert sind?

Und das alles für iD?
Das verstehe ich am wenigsten, weil das traffic_sign:*ward=DE:x schon mal kurzzeitig funktionierte … Sprich: man sah die Ausrichtung des Schildes, war nicht zuletzt eine Motivation für mich, die Richtung verstärkt zu mappen …

Derzeit funktioniert es nur mit den abweichend gemappten Schildern nach dem Schema highway=give_way/stop direction=*ward, da wird die Richtung korrekt angezeigt.

Eigenartig ist derzeit die Anzeige von “doppelt” gemappten wie dem da, wo derzeit beide Rchtungen angezeigt werden, obwohl direction nur forward ist, da “funkt” die traffic_sign:backward also schon rein, obwohl traffic_sign:*ward nicht angezeigt wird, wenn kein direction da ist …
Eigentlich ist es so für doppelseitige Schilder richtig, nur warum nacht man’s nicht bei einseitigen ohne direction? Einseitig mit direction geht ja auch schon wie bei dem, wo das Radwegschild nicht auf der Rückseite, sondern paar Meter weiter zurück hängt … Es sieht so aus, als wenn das Rüstzeug für korrektes traffic_sign:*ward schon vorhanden ist (war ja auch schon mal aktiviert vor etlichen Monaten …)

MitteloberrheinischerWaldameisenschreck · 2018-10-09T21:23:53.000Z

dieterdreist:

Direction ist eigentlich anders definiert, und das kommt mir auch solider vor: https://wiki.openstreetmap.org/wiki/Key:direction
also mit Himmelsrichtungen als value.

Da ist unter 5. aber auch forward/backward beschrieben!

kreuzschnabel · 2018-10-09T21:34:14.000Z

MitteloberrheinischerWaldameisenschreck:

dieterdreist:

Direction ist eigentlich anders definiert, und das kommt mir auch solider vor: https://wiki.openstreetmap.org/wiki/Key:direction
also mit Himmelsrichtungen als value.

Da ist unter 5. aber auch forward/backward beschrieben!

Richtig, und im nächsten Satz steht: „This only applies to features which are tagged on a node that is part of a way“ sowie dann sogar ausdrücklich: „Examples may include directed traffic signs.“

Betrifft den hier diskutierten Fall also definitiv nicht (traffic_sign am kompletten Weg statt nur auf einem Punkt). Wenn ich das traffic_sign sinnvollerweise nur da mappe, wo es auch steht, muss ich natürlich dazusagen, für welche Fahrtrichtung es gilt.

–ks

dieterdreist · 2018-10-09T22:33:13.000Z

chris66:

dieterdreist:

ich halte nichts davon, “traffic sign” auf Wegen zu taggen.

Ist aber nun mal gängige Praxis. (148000 ways mit traffic_sign).

Für die wenigen Fälle wo es nur in einer Richtung gilt kann man doch problemlos traffic_sign:forward=* taggen…

ja, wenn ein tag auf einem way ist machen forward und backward Sinn, auf einem Node nicht.

geri-oc · 2018-10-10T05:40:11.000Z

https://wiki.openstreetmap.org/wiki/Key:traffic_sign:

As a separate node
…
You can use the direction=* tag to describe the facing orientation of the sign by using an angle or cardinal direction.
…

As part of a way
…
You can use traffic_sign:forward=* to specify that this sign affects vehicles moving in the same direction as the OSM way. The opposite direction can be tagged with traffic_sign:backward=. Formerly the direction= key has also been used to describe the affected direction. But its common meaning has changed to Relative to Geographic North.
…

EDIT: Alle CS wurden revertet durch Frederik Ramm (z.B. https://www.openstreetmap.org/changeset/63325786 )

chris66 · 2018-10-10T06:34:55.000Z

Danke.