direction mit Gradzahl oder traffic_sign:forward

Communities Deutschland (Germany)
1

Der Beitrag #1633 im Forum auf der Seite

https://forum.openstreetmap.org/viewtopic.php?id=27176&p=66

hat mich zu einer Überprüfung in meiner Heimatstadt veranlasst. Nun zeigt Osmose unter

http://osmose.openstreetmap.fr/de/map/#&item=2030&zoom=17&lat=48.9956922&lon=9.1051407&level=2

viele Punkte als mögliche Fehler an. So werden u.a. am Kreisel Bahnhofstraße/Gottlob-Grotz-Straße in Bietigheim-Bissingen einige VZ 201 markiert. Die „Fehlermeldung“ lautet dann stets:

„Möglicherweise fehlender direction-Tag an Stop- oder Vorfahrtschild“

obwohl z.B. ein Eintrag mit direction=281 vorhanden ist.

Unter

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

habe ich folgende Aussage gefunden:

„Mit dem Unterschlüssel traffic_sign:forward=* kann festgelegt werden, dass das Verkehrszeichen in Richtung der OSM-Linie gilt. Die entgegengesetzte Richtung kann mit traffic_sign:backward=* gekennzeichnet werden. Früher wurde hierzu der Schlüssel direction=* verwendet, um die entsprechende Richtung zu beschreiben.“

Ich lese dies so, dass der Eintrag „direction“ wohl überholt ist und durch „traffic_sign:forward“ ersetzt werden soll. Da ich keine Eintragungen von Zeichen 201 eines anderen Kollegen gefunden habe und mir nicht sicher bin, ob dies die Ursache der Beanstandung von Osmose ist und nicht an den Eintragungen eines Kollegen Änderungen vornehmen wollte, habe ich ihn in einer persönlichen Nachricht gebeten, dies selbst zu überprüfen.

Er hat mir geantwortet, dass er die Richtung an Verkehrsschildern regelmäßig durch Gradangaben ausdrückt, weil er das mit forward/backward an Punkten für ein kaputtes Konzept hält, u.a. wenn der betreffende Punkt Teil mehrerer Wege ist und deshalb forward/backward nicht anwendbar ist bei freistehenden Objekten.

Die Fragen sind nun:

Ist die Aussage zu traffic_sign:forward im wiki https://wiki.openstreetmap.org/wiki/DE:Key:traffic_sign
falsch?

Zeigt Osmose den Punkt zu Unrecht als evtl. Fehler an?

2

Der oben angesprochene Kollege bin ich und ich wiederhole hier als Diskussionsgrundlage einfach nochmal, was ich in der privaten Kommunikation geschrieben hatte:

Warum ich direction=[forward|backward] nicht verwende:

  • Als Attribut eines Punkts stellt sich die Frage, was denn die Vorwärtsrichtung eines Punkts sein soll.
  • Die These, man könne ja die Richtung des zugehörigen Wegs auswerten, ist nicht universell - das funktioniert nicht, wenn der betreffende Punkt Teil mehrerer Wege ist. Dies ist regelmäßig der Fall bei z. B. Änderung eines Tempolimits, Beginn eines Überholverbots etc. Hierzu die Topologie zu verändern nur damit das tagging passt, so wie es im Wiki empfohlen wird, ist meines Erachtens ein kaputtes Konzept.
  • ist nicht anwendbar bei freistehenden Objekten (warum sollte man für die gleiche Aussage unterschiedliche Taggingschemata verwenden, je nachdem, ob das Objekt Teil eines Wegs ist oder nicht?)
  • die Auswirkung auf einen Weg z. B. bei einem Tempolimit wird in der Regel sowieso mit eigenen tags am Weg dokumentiert.
  • Nicht robust gegen unbeabsichtigte Änderungen - nicht jeder Editor berücksichtigt das wenn z. B. eine Wegrichtung umgedreht wird.

Warum ich direction=n verwende? (n ist die geographische Richtung in die das Objekt zeigt in Grad)

  • Es ist ein sachlich und semantisch korrektes Attribut für einen Punkt.
  • Es ist immer eindeutig und kann sofort ausgewertet werden
  • Es funktioniert universell, auch bei freistehenden Objekten, z. B. bei separat vom Weg erfaßten Verkehrsschildern oder der Ausrichtung einer Sitzbank.
  • Es ist robust gegen unbeabsichtigte Änderungen

Grüße, P.

3

Danke euch beiden für diese Diskussion.
Ich hatte erst die Tage jemanden, der gerne direction=back/forward auf der direction Karte angezeigt bekommen hätte.
Unabhängig von dem Punkt, dass ich mit overpass eben nur die “Punkte” hole und so gar keine Chance habe die “Wegrichtung” zu bestimmen, sind die aufgezählten Punkte von Peilscheibe durchaus nachvollziehbar.

Das einzige was ich aber schon irgendwo im Wiki gelesen habe ist, dass man z.B. Stoppschilder eben NICHT auf den Kreuzungspunkt setzen sollte, sondern wirklich genau da wo die Haltelinie ist, und dann “könnte” man wieder mit back/forward arbeiten

4

Und das bei allen Schildern - auch Parkverbot oder Geschwindigkeit, wenn sie als node im way liegen - sind sie sogar auswertbar (wenn wer will).

5

Nur mal als Denkanstoß:

Soweit ich das in der Praxis erkennen kann, bekommt z. B. OSMAnd die korrekte Auswertung bei Stop-Schildern auch ohne direction hin (*) - liegt natürlich an der Besonderheit der Stop- und Vorfahrt achten Schilder und ist daher nicht auf andere Schilder übertragbar.

(*) Vorausgesetzt, sie sind sinnvoll gemappt - und nicht auf dem Kreuzungsnode eingetragen!

6

Noch ein Problem, welches ich mit “direction” bei Schildern sehe.

Schilder werden oft von den Verkehrsverantwortlichen auch 90° gedreht um sie “auszuschalten”. Ganz in meiner Nähe wurde z.B. sämtliche Geschwindigkeitsbegerenzungen per “Drehen” aufgehoben und dafür “temporäre” Geschwindigkeitsschilder aufgestellt. “Temporär” heißt in dem Fall, seit 5 Jahren :smiley: und vermutlich auch noch viele weitere Jahre…

7

Sbip

8

Ist doch klar, was dass zu bedeuten hat: wenn Du auf Der Normalfahrspur rückwärts fährst, hast du nun auch Geschwindigkeitsvorgaben!

Die Bürokraten Will so den Spinner das Handwerk legend, die bei einem Stau in eine Richtung einen U turn ausführen und rückwärts am Stau vorbeirasen.

Passiert seit die Fahrer abgeschafft sind und nur Elektroautos unterwegs sind, ja ständig.

Und Deine Gemeisnde plant eben gut vor…und benutzt dabei eine realistische Verkehrszenariensiftware, die gemeinsam von Appel und Mirosoft entwickelt wurde.

Schlage vor das mit lane:forward@conditional;backing zu beschreiben.

9

Ich glaube du verwexelst 90° mit 180°.

10

Glaube ich auch :wink:
Lachen musste ich trotzdem herzlich!

11

Meistens stehen die dann so, dass 'ne querende Wildwutz geblitzt werden könnte, was die Verkehrssicherheit ungemein erhöht! :laughing: