Traffic_sign=city_limit zwischen Orten mit verschiedenen Namen

Moin!
Wie erfasst man eine Ortstafel, die auf Vorder- bzw. Rückseite unterschiedliche Namen angibt?
Hier Node: 7079692834 | OpenStreetMap ist noch kein Schild erfasst. Auf der einen Seite steht Stenum, auf der anderen Schierbrok. Es geht also nicht darum, unterschiedliche Sprachen auf einer Seite zu erfassen.
Das ist ja gar nicht so selten, oder?
Edit: Die Abstürze um die Mittagszeit haben meinen Post verstümmelt. Im Wiki ist was von alt_name=* erwähnt, aber mir ist nicht klar, welchen Namen man dann wo angibt.

Normalerweise mache ich das bei zweiseitigen Verkehrsschildern (30-Zone, verkehrsberuhigter Bereich, etc.) immer so, daß zwei Verkehrsschilder auf dem gleichen Punkt sind, mit jeweils anderer direction. Das könnte man hier theoretisch auch so machen, funktioniert aber glaube ich nur wirklich gut, wenn die Nodes nicht auf der Straße liegen, sondern daneben (was glaube ich nicht die Norm für city_limit ist).

Man könnte sich damit behelfen, zwei Nodes knapp hintereinander auf die Straßenlinie zu setzen. Der Abstad zwischen den Nodes ist dan quasi die Dicke des Blechs des Schildesr

1 Like

Wie wäre es mit:
traffic_sign=city_limit
name:forward=
name:backward=
direction=both

Bei direction bin ich mir nicht sicher ob dann klar ist das es sich auf die Digitalisierrichtung der Straße beziehen soll, sonst müsste man doch direction=forward oder backward angeben.

2 Likes

Das finde ich ein wenig Overkill. Was erwartetest du denn sonst auf der Rückseite von so einem Zonenschild außer deren Aufhebung? Ist doch vermutlich eine seltene Ausnahme, dass diese Schilder nur einseitig sind, oder?

…und wie wäre die zweisprachige Variante?

fragt Sven

Wie machst du das denn sonst mit den zwei Sprachen?
Keine Ahnung was das welches Kürzel für sorbisch (wen,hsb,dsb) hier richtig ist. Und dann einfach forward und backward dranhängen.

name:de:forward
name:xx:forward

Edit. also andersrum. Danke @Nadjita

Laut wiki kommt erst die Richtung, dann die Sprache. Also:

name:forward:de=Lübbenau
name:backward:de=Zerkwitz
…
2 Likes

@Langlaeufer und @Nadjita

Danke. Bei Sowas bin ich mir mit der Position des Länderkürzels nicht sicher.

Der ISO-Code für mich wäre dsb für Niedersorbisch. Mehr oder weniger in Sachsen wäre es hsb (Obersorbisch)

Sven

Ich hab das bei mir mal so gemacht: https://www.openstreetmap.org/changeset/131513631

1 Like

Das funktioniert leider nicht, da ein Punkt keine Richtung hat. Und wenn wie üblich die Straße am Ortsschild aufgeteilt wird lässt sich die Richtung auch nicht aus der Straße ableiten.

1 Like

Der Punkt nicht, der Linienvektor, auf dem der Punkt liegt hingegen schon.
Oder hast du eine andere Idee? Mir fällt da nichts ein… Ja und das Arbeiten mit Nord/Süd/Ost/West und deren Derivate halte ich allgemein für nicht einheitlich erfassbar, ebenso, wenn man mit Gradzahlen arbeiten würde…

Bedingung ist:

  • traffic_sign muß auf einem Punkt des Straßenvektors liegen,
  • Straße darf an dem Punkt nicht aufgeteilt sein,
  • wenn die Straße aufgeteilt ist, muß das Segment davor und danach in die selbe Richtung zeigen.

→ dann sollte es durchaus auswerbar sein.

*:forward:*=* sowie *:backward:*=* funktioniert in der Routingauswertung z.B. bei touristischen Themenradwegen auch. Das ist hier eigentlich nichts anderes.

Sven

Das da. Wobei ich nicht weiß, ob Programme das korrekt auswerten :person_shrugging:

Das wird bei city_limit vermutlich schwer, da ja mindestens wegen maxspeed und source:maxspeed da immer eine Trennung vorliegen wird (wenn nicht jetzt, dann später mal).

Das wäre ein Fall für eine Fehlerprüfung:
Zeige alle Punkte, von aufgeteilten Straßen, an denen jeweils die Zeichenrichtung aufeinander zu laufen, oder voneinanderweg laufen und die (z.B.) mit traffic_sign erfasst sind. (dazu noch was kein direction hat)

Beispiel…

Eine durchaus vergleichbare Richtungsvektorenauswertung gibt es bei Wasserwegen: nennt sich Possible direction errors

Wenn es da geht, geht es hier auch bei einer möglichen Routing-Auswertung…

…im übrigen ist das bei Wasserwegen in Bezug auf solche Dinge nicht immer lösbar… das nur nebenbei.

Sven

Ah richtig… du hast recht… das wäre auch ein Fall für eine Fehlerprüfung… city_limit erfordert im Normalfall immer eine Geschwindigkeitsänderung also in der Folge eine Trennung des Linienvektors…

Sven

traffic_sign muß auf einem Punkt des Straßenvektors liegen,

wieso? Wenn der Punkt daneben liegt hat man die Richtung, wenn es auch einen weiteren Schritt erfordert (nächste Straße finden und den Punkt draufprojizieren)

Tja, scheint wohl doch nicht so oft vorzukommen. Ich kenne aber zumindest zwei solche Stellen und hätte gedacht, dass Ruhrgebiet sei voll davon.
Die Frage ist für mich, ob traffic_sign=city_limit da überhaupt hingehört. Man ist ja vor und hinter dem Schild in einer geschlossenen Ortschaft, nur eben einer anderen. Für den Router hat dieses Schild also eigentlich gar keine Bedeutung.
Ob man das Schild zwischen zwei OSM Wege setzt oder kurz vor den Anfang bzw. das Ende des Einen scheint nicht klar zu sein. Ich kenne beide Varianten und habe auch beide genutzt.
Ich habe allerdings bei der Variante “dazwischen” ganz auf direction=* verzichtet. Werde ich noch mal im Detail prüfen.

1 Like

Für die Datenbank hat das Schild doch eh nur die Bedeutung dass dort ein Schild steht. Die Namen der Orte sind hoffentlich noch anders erfasst und alles was Verkehrsregeln betrifft sollte über die Kanten modelliert werden.

Ich habe direction=* bei Verkehrsschildern bislang so verstanden, dass damit die Ausrichtung des Schilds angegeben wird, als Himmelsrichtung oder Winkelgrad. So steht es auch im Wiki: DE:Key:direction. Damit wären auch klar definiert, was name:forward= und name:backward= bedeuten.

Dem ist auch so.
Das Problem hier ist nur, das wir dem Schild eine Richtung geben müssen und dann noch ausdrücken wollen was auf der Vorder- und was auf der Rückseite steht. Die Bedeutung von direction=forward / backward wäre klar definiert. name:forward/backward hingegen auf einem Punkt ist glaube ich aber nicht dokumentiert. Das könnten wir für diese Zwecke aber einfach mal übertragen.