search

osmberlin / osm-traffic-sign-tool

A proof of concept tool to help you find the right `traffic_sign=*` tag as well as recommended tags for the road that it applies to.
https://trafficsigns.osm-verkehrswende.org/
GNU Affero General Public License v3.0
18 stars 5 forks source link

Zusatzzeichen "Motorrad-Symbol / Auto-Symbol frei" #51

Open tordans opened 1 month ago

tordans commented 1 month ago

Die Frage ist, wie man dieses Zusatzzeichen als traffic_sign taggt. Das Tagging in Tags ist recht gut definiert in den Artikel

Das Symbol ist das von DE:290

Unter https://wiki.openstreetmap.org/wiki/DE:Verkehrszeichen_in_Deutschland#Zusatzzeichen_KFZ_frei wird empfohlen traffic_sign=KFZ frei zu verwenden.

image

Dazu passt auch dieser Thread https://x.com/tobwen/status/1836810294112440684

image

Kennt jemand die Quellen dieser Screenshots?

Aktuell würde ich also sagen, dass traffic_sign=traffic_sign=DE:244.1,"Kfz-Verkehr frei" das beste Tagging wäre. Allerdings nennt das Wiki gerade eine etwas andere Formulierung.

fkoester commented 1 month ago

Hi @tordans , der erste Screenshot ist jedenfalls aus dem "Leitfaden Fahrradstraßen" des Verkehrsministeriums NRW: https://www.agfs-nrw.de/fileadmin/Mediathek/AGFS-Broschueren/Loseblattsammlung_Fahrradstrassen_RZ_Einzel_01.pdf

fkoester commented 1 month ago

In Mainz gibt es eine leichte Variation dieser Beschilderung. Dort sind lediglich Motorräder und PKWs erlaubt (keine LKWs oder Busse). Unterschied ist, dass das Auto nicht von vorne sondern von der Seite abgebildet ist.

image

Ich hatte dieses kombinierte ZZ damals interpretiert und die eigentliche anzubringende Beschilderung mit den ZZ aus dem VZKat getaggt (traffic_sign=DE:244.1,1022-12,1024-10). Aus heutiger Sicht würde ich aber sagen, dass das so nicht korrekt ist.

https://www.openstreetmap.org/node/10783674829

In den ERA (2010) wird interessanterweise genau die Kombination 1024-10 und 1022-12 genannt um Kraftverkehr zuzulassen. Dass dadurch gar keine LKW erlaubt sind wird dort erstaunlicherweise nicht erwähnt: IMG_20241001_113032

tordans commented 1 month ago

Danke @fkoester. Ich frage mich, ob wir für diese Zeichen einfach unsere eigenen OSM Values definieren müssen, damit wir sie sauber zuordnen können.

Grundsätzlich unterstützt das Schema ja schon jetzt Freitext, aber den hatte ich bisher wirklich für Text-Schilder "reserviert" und nicht um Piktogram-Schilder zu beschreiben. Bei dieser Beschreibung schafft man im Grunde ja mit "Kfz-Verkehr frei" eine ID, die jedoch sehr unpräzise ist wie dein Beispiel zeigt.

Was meinst du @SupaplexOSM?

Man könnte Text-IDs vergeben, beispielweise

Man könnte Nummern-IDs vergeben, beispielweise einen 9000-ender Nummernraum eröffnen Jeweils mit Wiki-Tabelle mit Beispiel und Quellenangaben zur Interpretation…

SupaplexOSM commented 1 month ago

Aktuell würde ich also sagen, dass traffic_sign=traffic_sign=DE:244.1,"Kfz-Verkehr frei" das beste Tagging wäre. Allerdings nennt das Wiki gerade eine etwas andere Formulierung.

Das sehe ich genauso und würde vorschlagen, das Wiki an der Stelle anzupassen. Laut TagInfo ist "Kfz-Verkehr frei" auch der häufigste Value, allerdings nur, weil sich der Rest in bunte Groß- und Kleinschreibungsvarianten zersplittert:

grafik

"Kfz-Verkehr frei" scheint auch der Bezeichnung zu entsprechen, unter der dieses Zeichen in Planungsveröffentlichungen wie oben genannt auftaucht. Es gibt auch eine Zeichenvariante, auf der tatsächlich "Kfz-Verkehr frei" als Text steht, was ja dann die gleiche Bedeutung hat:

grafik (Quelle)

In der Vergabe von eigenen Text- oder Nummern-ID's sehe ich keine Vorteile bzw. das erscheint mir so unintuitiv und kompliziert, dass ich mir nicht vorstellen kann, dass das Verwendung finden würde. Freitext-Angaben sind ja (meiner Wahrnehmung nach) letztendlich auch Text-ID's für Zeichen ohne Katalognummer, egal ob da auf dem Zeichen tatsächlich ein Text steht oder irgendwelche anderen "Phantasie-Piktrogramme".

Ich hatte dieses kombinierte ZZ damals interpretiert und die eigentliche anzubringende Beschilderung mit den ZZ aus dem VZKat getaggt (traffic_sign=DE:244.1,1022-12,1024-10). Aus heutiger Sicht würde ich aber sagen, dass das so nicht korrekt ist.

Warum würdest du sagen, dass traffic_sign=DE:244.1,1022-12,1024-10 bei der Variante, die Pkw statt Kfz meint, nicht korrekt ist? Zumindest von der Bedeutung her scheint es das ja präzise zu treffen.

Kommunen und Straßenverkehrsbehörden denken sich so viele "kreative" Schilder aus, da sollten wir nicht versuchen, die irgendwie zu katalogisieren sondern einfach deren Bedeutung so genau wie möglich mit den bestehenden Mitteln zu erfassen.

SupaplexOSM commented 1 month ago

P.S. Hier nochmal zusammengefasst, wie ich die Zeichen taggen würde:

traffic_sign=DE:244.1,"Kfz-Verkehr frei"

OSM-access-Bedeutung: vehicle=no + bicycle=designated + motor_vehicle=yes

ebenfalls traffic_sign=DE:244.1,"Kfz-Verkehr frei"

OSM-access-Bedeutung: ebenfalls vehicle=no + bicycle=designated + motor_vehicle=yes

traffic_sign=DE:244.1,1024-10,1022-12

OSM-access-Bedeutung: vehicle=no + bicycle=designated + motorcar=yes + motorcycle=yes

traffic_sign=DE:244.1,1022-12,1024-10 oder ebenfalls traffic_sign=DE:244.1,1024-10,1022-12 (die Reihenfolge der Zusatzzeichen ist unterschiedlich, aber hier recht irrelevant)

OSM-access-Bedeutung: ebenfalls vehicle=no + bicycle=designated + motorcar=yes + motorcycle=yes

fkoester commented 1 month ago

Grundsätzlich unterstützt das Schema ja schon jetzt Freitext, aber den hatte ich bisher wirklich für Text-Schilder "reserviert" und nicht um Piktogram-Schilder zu beschreiben. Bei dieser Beschreibung schafft man im Grunde ja mit "Kfz-Verkehr frei" eine ID, die jedoch sehr unpräzise ist wie dein Beispiel zeigt.

Das ist in der Tat eine Herausforderung. Ich habe das in der Vergangenheit des öfteren so gelöst, Beispiel:

image

traffic_sign=DE:250,"Landwirtschaftlicher Verkehr u. [Sinnbild Radverkehr] frei". Die Namen der Sinnbilder ja in § 39 StVO eindeutig definiert.

In der Vergabe von eigenen Text- oder Nummern-ID's sehe ich keine Vorteile bzw. das erscheint mir so unintuitiv und kompliziert, dass ich mir nicht vorstellen kann, dass das Verwendung finden würde.

Das sehe ich auch so.

Warum würdest du sagen, dass traffic_sign=DE:244.1,1022-12,1024-10 bei der Variante, die Pkw statt Kfz meint, nicht korrekt ist? Zumindest von der Bedeutung her scheint es das ja präzise zu treffen.

Weil es sich bereits um eine Interpretation des Verkehrszeichens handelt. Meiner Meinung nach sollte traffic_sign möglichst nur die "Realität" beschreiben ohne Annahmen zu treffen, was die Behörde damit wohl gemeint haben könnte. Die Interpretation der Zeichen erfolgt ja bereits über die anderen Keys (access=, vehicle=, bicycle=) usw.

Es kann für Datenkonsumenten auch durchaus interessant sein zu wissen, ob da jetzt eine StVO-konforme Beschilderung ausschließlich mit den Zeichen aus dem VZKat hängt oder ob die Behörde mal wieder lieber den Plotter angeworfen hat um eigene Schilder zu basteln.

Ich gebe aber zu, dass es recht schwierig ist ein Schema zu entwickeln, dass selbst für solch komplexere Kombi-Schilder ein passendes und einheitliches Tagging ermöglicht und zugleich auch einfach zu benutzen ist.

fkoester commented 1 month ago

Um die Sache noch komplizierter zu machen gibt es ja auch noch unterschiedliche Versionen des VZKat (in anderen Ländern vermutlich entsprechend). Beispielsweise das oben angesprochene Zeichen 260 war bis 1992 das Zeichen 252.

Aktuell tagge ich sowas meist mit traffic_sign=DE:260 und meiner temporären Eigenkreation traffic_sign:deprecated=yes und einer entsprechenden note. Aber was man da ja eigentlich bräuchte wäre eine Versionierung. Wenn es irgendwann mal einen neuen VZKat gibt und bestehende IDs neu vergeben werden könnte traffic_sign=DE:260 theoretisch was ganz anderes bedeuten.

Wäre jedenfalls ganz cool wenn man in der OSM gezielt nach Verkehrszeichen aus einem bestimmten veralteten Katalog suchen könnten.

Aber das ist jetzt ein ganz anderes Thema. Hier nur mal so als Anregung, ich denke das müsste man dann mal auf einer OSM-Mailingliste oder so diskutieren.