OpenStreetMap

direction: Blickrichtung vs. Geltungsrichtung

Das folgende steht im deutschen Wiki: “Die Tags direction=forward und direction=backward sind nur für Knoten gedacht, die zu genau einer Linie gehören. Stützt der Knoten mehr als eine Linie, wären diese Angabe mehrdeutig. Dann sollten Himmelsrichtungen für direction=* verwendet werden. Hinweis: Bitte die gegensätzlichen Bedeutungen bei der forward/backward (Geltungsrichtung) und bei Himmelsrichtung (Oberflächenrichtung) beachten.” Quelle: https://wiki.openstreetmap.org/wiki/DE:Key:direction

Upps, diesen Hinweis im Wiki habe ich übersehen: Gut dass mich ein anderer Mapper auf meine systematischen Falscheingaben freundlich aufmerksam gemacht hat und er und ich mit Hilfe von https://overpass-turbo.eu/s/1B5L (Danke an den aufmerksamen Mapper) wenigstens viele von mir gemachte Fehler mit relativ viel Arbeit wieder korrigieren konnte (ganz durch bin ich damit aber noch nicht). Das passiert, wenn man mit dem Lesen der Beschreibung zu früh aufhört, oder meint, man hat nach Jahren OSM-Mapping schon genügend Erfahrung. Ehrlich gesagt, habe ich das Wiki auch erst mehrfach lesen müssen, um diese scheinbare Widersprüchlichkeit zu verstehen.

Es gibt also eine tückische Fehlermöglichkeit beim Mappen von Vorfahrtszeichen, da mit direction zwei grundsätzlich unterschiedliche und zudem gegensätzliche (!) Eigenschaften beschrieben werden.

Geltungsrichtung

1.) Bei Verkehrszeichen wie highway=stop oder highway=give_way ist die übliche Methode, mit direction=forward bzw. backward in Bezug auf die in OSM angegebene Richtung der Straße die Richtung anzugeben, in der gefahren wird, damit das Schild gilt. bzw. “The directions forward and backward can be used to specify the direction of a feature relative to an existing way. This only applies to features which are tagged on a node that is part of a way. Examples may include directed traffic signs.” Quelle: https://wiki.openstreetmap.org/wiki/Key:direction Nutzung: m.E. wichtig z.B. bei Navigationsansagen

Blickrichtung/Himmelsrichtung/Oberflächenrichtung

2.) Bei Angabe einer Himmelsrichtung z.B. mit direction=E (Ost) dagegen wird die Himmelsrichtung angegeben, in die das Schild blickt, und das ist üblicherweise natürlich entgegengesetzt der betroffenen Fahrtrichtung (hier: West): “Note that traffic signs traffic_sign=* are tagged the way the sign faces, i.e., against the direction of travel. For example, when travelling west, signs are facing east, so you tag them with direction=90 or direction=E.” Quelle: https://wiki.openstreetmap.org/wiki/Key:direction bzw.: “Bei einem Verkehrsschild wird dessen Oberflächenrichtung angegeben, die Geltungsrichtung liegt um 180° versetzt dahinter.” Quelle https://wiki.openstreetmap.org/wiki/DE:Key:direction Nutzung: Diese Sichtweise orientiert sich m.E. an Eingaben für die 3D-Ansicht.

Vielleicht fragt sich jemand, warum ich überhaupt begonnen hatte, die Himmelsrichtung statt forward/backward einzutragen: Ich war zu faul, beim Eintragen mit dem erstklassigen Vespucci jedesmal nachzusehen, in welche Richtung der betroffene Weg eingetragen ist. Außerdem dachte ich echt, das wäre weniger fehleranfällig…. (Aus wiki: “Manche Editoren könnten den Wert für direction=* an Knoten, die Teil eines Ways sind, missachten, wenn man die Richtung des Ways umkehrt. “). So kann man sich irren. Außerdem hatte ich an einigen Stellen versucht, nodes zu sparen und die Verkehrszeichen auf existierende nodes auf Wegen zu setzen, wobei z.T. 2 ways mit entgegengesetzer Richtung auf einem node zusammentragen (da kann man kein forward oder backward eintragen, siehe oben, allererster Satz)

Auch wenn ich offenbar einer der wenigen bin, die darauf reingefallen sind: vielleicht ist dieser Hinweis ja hilfreich. Laut Wiki gibt es auch noch andere Signale etc., für die das relevant ist.

PS: So habe ich mich erstmals mit dem OSM-Nutzerblog und mit overpass turbo beschäftigt. Scheint echt ein klasse Tool zu sein, und scheint für jemanden, der wie ich mit Logik und Programmieren bereits Erfahrung hat, nicht übermäßig kompliziert in der Anwendung zu sein. Beispiele wie das oben verlinkte helfen aber dabei enorm.

Discussion

Comment from syncronic on 8 October 2023 at 16:17

Danke für die Erklärung. Ich habe aufgehört das direction tag an der Stelle zu setzen, weil ich es auch nicht verstanden haeb. Jetzt fühle ich mich wieder sicherer.

Comment from StephaneP on 9 October 2023 at 05:32

Hello !

Just to let you know that i’ve just release a style for Josm which displays the traffic sign direction. I hope it will help the contributors to add the direction tags.

https://framapiaf.org/@Stfmani/111189046166414211

traffic signals

stop

Comment from dieterdreist on 13 October 2023 at 09:23

es ist in der Tat sicherer, mit direction die Richtung anzugeben, anstatt über “forward” und “backward”, weil letzteres im Falle, dass sich 2 ways im selben node treffen – übrigens eher üblich für traffic_sign nodes, weil sich dort ja eine Eigenschaft ändert – oft nicht definiert ist, und es kann sich weiterhin jederzeit die Richtung eines der beiden ways ändern und dadurch würde es zukünftig undefiniert.

Eine andere Variante ist, das Schild wirklich dort zu mappen, wo es aufgestellt ist, bzw. eine Idealisierung dessen, also einen node zu machen, der nicht Teil des ways ist, sondern rechts davon liegt. Ich mache das so und habe (entgegen der üblichen Unkenrufe) damit bisher gute Erfahrungen gemacht. Die Schilder mappt man ja sowieso eher, um den anderen Mappern zu kommunizieren, warum etwas gemappt ist, und wo man die Information gesehen hat, aber eigentlich nicht, um für Router o.ä. Auswirkungen zu erzeugen. Auch für detailliertes 3D-Rendering (anderer Anwendungsfall) ist die genaue Lage des Schildes interessant. Bei dieser Methode ergibt sich die Richtung bereits implizit durch die Position des nodes (man könnte sie aber natürlich trotzdem auch noch explizit mappen).

Log in to leave a comment