Neue Verkehrszeichen

Im WIKI wurde die Seite
https://wiki.openstreetmap.org/w/index.php?title=DE%3AVerkehrszeichen_in_Deutschland&type=revision&diff=1609181&oldid=1437855
überarbeitet. Finde das erst einmal gut, es auf den neuesten Stand zu bringen.

Aber z.B.:
traffic_sign=DE:274[60] ist m.E. ein Fehler. Das Verkehrszeichen hat die Bezeichnung Zeichen 274-60. Die Angabe in eckiger Klammer ist eine Angabe (Auswertbarkeit?) für OSM und könnte zusätzlich zu der Bezeichnung angegeben werden: traffic_sign=DE:274-60[60], am way: maxspeed=60; source:maxspeed=DE:274-60
So ist z.B. diese VZ (Anfang Parkverbot) auch nur mit Bindestrich richtig dargestellt: traffic_sign=DE:286-10

Oder (Verbot für Fahrzeuge über 10,5 m) traffic_sign=DE:266-10,5[10.5], am way: maxlength=10.5
Oder (Verbot für Fahrzeuge über angegebene tatsächliche Masse) Verbot für Fahrzeuge über angegebene tatsächliche Masse) traffic_sign=DE:262-5,5[5.5], am way: maxweight=5.5
So führt eine Suche nach VZ in Deutschland mit Nummer 262-5,5 im VZ-Katalog oder in Wikipedia zur richtigen Stelle.

Ich habe die VZ bisher nach Wikipedia eingetragen. Eventuell sollte das in OSM auch gemacht werden, da die “Bedingungen” auch nach dem Bindestrich auswertbar / übertragbar sind und nicht in [] stehen müssen. Die Bedingungen werden ja richtigerweise an den way mit Dezimaltrenner Punkt übertragen.

Bei 274 ist das echt tückisch. Eine Geschwindigkeitsbeschränkung auf 60km/m wird mit Zeichen 274-56 beschildert. :smiley:

Das hat auch der Gesetzgeber erkannt und 2017 die Nummerierung geändert.

Ist aber echt tückisch… Je nach Zeitpunkt des Mappens und Kenntnisstand des Mappers kann 274-60 “100km/h erlaubt” heissen (1992-2017) oder “60 km/h” (2017-heute). 274-56 ist harmlos, das gibts nicht mehr.

Mir geht es nicht nur um “ein” VZ - sondern um die Darstellung aller VZ als node und der Werte an dem bereffendem way eventuell mit source=VZ. Und dabei um das [] oder wie es tatsächlich “gültig” benannt ist. Wir ändern das WIKI - aber auch richtig nach den “Vorlagen”.

Auf Grund der vielen Änderungen hatte ich nur Einiges einarbeiten können und bin mir dem durchaus bewusst. Wie bereits angedeutet mag es bei der Seite Verkehrszeichen in Deutschland also noch weiteren Überarbeitungs-Bedarf geben.

Gute Referenzseite zum VzKat

<klugscheiß> Das ist keine Geschwindigkeit, das ist ein Kartenmaßstab von 60.000:1 </klugscheiß>

–ks

Dafür sage ich ja auch Danke.

Aber warum Werte in “” wenn sie durch “-” ausgezeichnet sind? Werte tragen wir am way ein. Dort kann eventuell traffic_sign=* als source:= angegeben werden.

Beispiel
Verbot für Fahrzeuge über angegebene tatsächliche Masse:
traffic_sign=DE:262-5,5[5.5], am way: maxweight=5.5


    
  traffic_sign:forward=DE:262-5,5
  side=right
               |
               v
-------------->.------------------------------------>
highway=*          highway=* 
                          maxweight=5.5
                          source:maxweigth=DE:262-5,5   


EDIT: auch bei Wikipedia sind die neuen VZ: https://de.wikipedia.org/wiki/Bildtafel_der_Verkehrszeichen_in_der_Bundesrepublik_Deutschland_seit_2017

Das könnte die Auswertung schon etwas komisch machen.

Ein Komma in der Bezeichnung könnte für das Parsen auch etwas komisch sein, weil Kommata auch als Trenner für mehrere Zeichen dienen können. Also in dem Fall z.B. könnte es Zeichen “DE:262-5” mit Zusatzzeichen “DE:5” mit Wert “5.5” sein. Natürlich gibt es kein Zusatzzeichen 5, aber da könnten Parser schon drüberstolpern.

Ich kenne mich mit dem parsen nicht aus. Gab es nicht String-Werte, die nicht als Zahlenwerte behandelt werden?

EDIT
Noch eine Möglichkeit wäre DE:* bei jeden VZ zu verwenden, auch bei Aufzählungen. Dann darf der Wert am “,” nicht geteilt werden, wenn nicht DE:* folgt.

Ich weiß natürlich nicht ob/wie Leute tatsächlich traffic_sign=* auswerten, aber wenn ich nach der derzeitigen Beschreibung im Wiki einen Parser bauen würde, dann wäre Trennung an ; und dann , wohl die Vorangehensweise, lediglich solche eingeschlossen in eckigen Klammern ignoriert (für Werte wie zeitliche Beschränkungen die im opening_hours=* Format verfasst sind).

Theoretisch könnte man natürlich die Definition ändern, wie eben z.B. den Ländercode vor jedes Zeichen hängen, aber man muss auch beachten, dass es schon viele Werte in der Datenbank gibt welche diese Regel nicht umsetzen, da würde es also wieder zu Problemen kommen. Ich sehe also als Parser ein Komma ohne ein “DE:” danach… aber woher weiß ich ob es ein Trenner-Komma nach dem “alten” Format ist (wo ein “DE:” vor jedem Zeichen kommen kann oder auch nicht) oder ein Komma in der Zeichen-Bezeichnung nach dem neuen Format? Man müsste also weiterhin als Parser die tatsächlichen Zeichen-Bezeichungen kennen (zumindest das grobe Format), was wenn man sie tatsächlich irgendwie sinnvoll auswerten möchte natürlich nicht unwahrscheinlich ist.

Wenn, dann müsste man eine Regel einführen die man eindeutig als neu erkennen kann, in der Regel nutzt man dafür eine Art Maskierungszeichen, z.B. “DE:262-5,5[5.5]” wobei der Parser weiß dass “,” ein tatsächliches Komma darstellen soll und kein Trennerzeichen. Natürlich müssen Parser das neue Format auch kennen, aber sofern es nicht schon Zeichen-Bezeichnungen gibt in denen Backslashes vorkommen ist die Bedeutung eindeutig. Oder man klammert irgendwie wie bei den Werten: “DE:(262-5,5)[5.5]”. Beides ist jetzt aber auch nicht so schön und ich weiß nicht wie realistisch die praktische Umsetzung ist.

Ich weiß wie gesagt nicht wie das Tag tatsächlich ausgewertet wird. Wenn man die Bedeutung der Zeichen auswertet wird man natürlich auch deren Bezeichnungen kennen und danach entscheiden ob die Trennung Sinn ergibt. Trotzdem macht es die Sache nicht einfacher und ich wollte nur darauf hinweisen, damit es evtl. in die Entscheidung wie man empfiehlt die Zeichen einzutragen mit einfließt. Man könnte natürlich einfach die Kommata durch Punkte ersetzen (wie in den Werten üblich), aber dann ist es wieder nicht wirklich die offizielle Bezeichnung. Nunja.

Aus meiner Sicht ergibt eine solche Doppelangabe logisch keinen Sinn. Der Zusatz in eckigen Klammern ist ja für Schilder gedacht, wo es das gleiche Schild mit unterschiedlichen Texten bzw. Zahlenwerten gibt. Mit der Unternummer hat das Schild den Zahlenwert aber ja “fest eingebaut”, es ist dann kein Schild mit variabler Beschriftung mehr.

Und ja, die Sache mit Komma in den Nummern ist ein Problem. Das setzt aus meiner Sicht eine definierte Lösung fürs Parsen solcher Werte voraus, sei es jetzt Escaping oder etwas anderes.

Eigentlich nicht, denn OSM will normalerweise Punkte haben.

BTW: Kann man eigentlich seine eigenen mxweight/maxheight-Edits auf Kommas absuchen? flöt :roll_eyes:

Allerdings handelt es sich bei den Unternummern der Verkehrszeichen um einen Teil der offiziellen Bezeichnungen, ist also etwas anders als so “normale” Werte. Ich habe auch nichts dagegen statt einem Komma einfach einen Punkt in der Bezeichnung zu verwenden, aber das müsste halt dann auch an passender Stelle klar definiert werden (z.B. auf der traffic_sign-Tag Seite), die allgemeine Regel für Werte reicht da eher nicht aus.

Oh no. That means a scale of 60 kilometers per mile. What an unhandy scale!