OpenStreetMap

KlausG's Diary

Recent diary entries

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.