Zeichen 267 (Einfahrt verboten) als Einbahnstraße taggen??

Aus meiner Sicht sind TR vor allem für korrektes Routing relevant. Spätestens wenn da auch except=* (gilt nicht für …) mit ins Spiel kommt wird es für den Renderer hoffnungslos.

Die Darstellung eines “no-entry” durch Renderer mag ja noch ein nice-to-have sein, aber die (Nicht-)Nutzung durch Router ist mMn schon ein Problem. Was nützt die sauberste Lösung, wenn “niemand” sie nutzt?

Mir bleibt nur, die no-entry-TR zu setzen in der Hoffnung, dass sie irgendwann mal verwendet werden.

Für mkgmap habe ich die Unterstützung im April 2014 eingebaut, seit 2015 werden auch mehrere “via ways” unterstützt. Die Auswertung macht allerdings die Garmin Soft- bzw.Firmware, mkgmap muss es nur richtig ins img Format umsetzen :wink:

Ich hab’ jetzt mal ein Ei gelegt, es für BRouter implementiert und an einer Deiner no_entry-TRs in Fischbach getestet:

https://www.openstreetmap.org/relation/5138530

Bisher hat BRouter einfach den from-Schenkel genommen, der als zweites in der Relation steht. Für OSRM das gleiche, Graphhopper ignoriert die Relation ganz.

Mit dem nächsten Map-Update am nächsten Sonntag sollte es für BRouter dann passen. Könnte aber grössere Wellen schlagen in meinem QS-Tool, weil implementiert habe ich folgendes: Weiterhin werte ich vom restriction-Text nur den Präfix aus, also “no_left_turn”, “no_entry”, “no_beer” ist alles gleichwertig. Und dann multipliziere ich die Matrix aller from- und to-Schenkel komplett aus und betrachte jede Kombination als gewöhnliche TR. Schien mir irgendwie einfach und logisch, aber ich bekomme jetzt halt zusätzliche Restriktionen.

no_beer gefällt mir. :smiley:

Grüße,
Chris “Zuviel Glühwein”

Ist ja AFAIK auch so gedacht, dass nur das „no“ oder „only“ ausgewertet werden muss und der Rest nur der Menschenlesbarkeit dient. Schwierig wird es allerdinx dann, wenn demnächst ein Künstler kommt und an alle erlaubten Abbiegungen TRs vom Typ no_problem und an alle verbotenen only_lunatics_turn_here mappt.

–ks

Ich fürchte, das ca. 30% der bisher erfaßten no_entry und no_exit Rels Müll sind. Es gibt weltweit nur 552 no_entry rels, davon haben 91 mehr als einen to-way, 50 haben keinen from-way. Bei den anderen gibt es bestimmt auch noch weniger offensichtliche Fehler.

edit:Tippfehler

Ich habe inzwischen den Eindruck, dass die no_entry-Relation nicht ganz durchdacht ist.
Im Wiki steht “Eine Relation des Typs “restriction=no_entry” kann mehrere from-Mitglieder haben (aber auch nur ein via und ein to)”.
Das übersieht, dass es nicht nur ein Einfahrverbot in eine Nebenstraße geben kann, sondern auch ein Ausfahrverbot aus der Nebenstraße (Schild steht anders rum). Wenn es nur einen to-way geben darf, muss für jeden betroffenen Straßenabschnitt eine separate no-entry-Relation angelegt werden. Das widerspricht eklatant der Regel “one feature - one OSM element”, denn es steht ja nur ein Schild da.
Das kann man nur vermeiden, wenn auch mehrere to zugelassen sind.

Du übersiehst, dass es genau dafür die no_exit-Relation gibt, die nur je einen from- und via-Member, aber beliebig viele to-Members haben darf. Problem gelöst :slight_smile: Ganz so doof waren die Erfinder der Abbiegebeschränkungen dann doch nicht.

–ks

Nach einer Mütze Schlaf habe ich jetzt dennoch Probleme mit dem Konzept. Warum soll man bei einer no_entry Rel überhaupt einen from-Way angeben? Ist es nicht viel klarer und wartungsfreundlicher, keinen from-Way anzugeben? Entsprechend bei no_exit keinen to-way.
Die Rolle via ist dann auch fraglich.
Oder anders: Vielleicht hätte man dafür doch besser einen eigenen Relations-Typ erfunden, so was wie type=way_entry oder way_exit.
Mit genau einem nicht geschlossen Weg und genau einem Node, der entweder der erste oder letzte in dem Weg ist und weiteren access tags, die aussagen, was ab diesem Knoten gilt. Quasi eine einseitige barrier=*
Also für ein VZ 267 vielleicht sowas
type=way_entry
access=no
foot=yes

Die Idee ist nicht uninteressant. Aber ein via-Node muss schon sein, wie du nach einer weiteren Mütze Schlaf mühelos erkennen wirst :slight_smile:

Ich wollte gerade einwenden, dass üblicherweise ein from-Member reicht, aber in https://www.openstreetmap.org/relation/7972488 hab ich tatsächlich selbst gleich drei hingesetzt. Wäre auch mit einem from möglich, wenn man die verbotene Einfahrt südlich der Kreuzung nochmal unterteilt. Zweistellig wird deren Anzahl aber mit Sicherheit nur sehr, sehr selten.

–ks

Den Knoten brauchen wir auf jeden Fall. Die Rolle fand ich fraglich, weil ja gar keine Reise “von-via-nach” beschrieben wird.
Was besseres fällt mir aber auch nicht ein. Man kann sich ja ein “egal von wo - via - nach” dazu denken.

Wir haben doch auch andere Stellen, wo wir mit dem Problem kämpfen, ob etwas am Node oder am Weg erfaßt wird, weil der Node eine keine Richtung hat und die Eigentschaft aber nur für die Stelle am Weg gilt.
Schwierig ist das ja immer dann, wenn später der Weg getrennt wird oder eben eine neue Straße am via Node verknüpft wird. Da denkt doch niemand daran, dass er den neuen Weg dann als from bei der no_entry Rel hinzufügen muss.

Dann bleibt der am via-Node liegende Teil in der Relation, der andere fliegt raus. Ich glaub, das macht inzwischen sogar iD richtig.

Das stimmt allerdings. no_entry ohne from-Member sowie no_exit ohne to-Member wären weniger fehleranfällig. Eine neue role für den Node würde ich aber keinesfalls einführen, er hat dieselbe Funktion wie ein via-Node in einer dreiteiligen TR und soll dann auch so heißen.

–ks

Ich meinte, wenn man auf eine Rel verzichten würde und stattdessen versucht, die Eigenschaft irgendwie an den Way zu hängen.
Das Problem gibt es doch z.B. bei noexit=yes am Weg, wo eben nicht klar ist, was passieren soll, wenn jemand die Richtung des Wegs umkehrt.
Aus der Sicht spricht auch vieles für eine generelle Relation für solche Eigenschaften, die genau den Node an einem Ende des Weges betreffen.
Will hier aber nicht alles neu erfinden :wink:

edit: Syntax

Wenn, dann würde ich die Eigenschaft auf einen Node setzen, der Teil vom Weg ist. Ähnlich wie eine Barrier, aber mit Richtungsangabe.

Wie würdest Du die Richtung angeben wollen?

Als “forward” bzw. “reverse”, abhängig davon wierum der Weg gemalt ist. Vielleicht “no_entry:reverse=yes”?

Da würde ich zuerst denken “da darf man nicht rückwärts reinfahren” :wink:
Im Ernst, die Verknüpfung von no mit reverse und yes ist eine Garantie für Mißverständnisse. Ausserdem schwierig für den Editor, wenn Du die Richtung des Weges umkehrst. Soll dann ja nicht ein no_entry:reverse=no werden, oder?

Ok, eine no_exit-Relation löst das Problem.
Zu meiner Entschuldigung: Im deutschen Wiki taucht die nigends auf, in der englischen Version habe ich sie übersehen.

edit: JOSM meckert mehrere to auch bei no_exit an.

Zum weiteren: Ein node allein mit no_entry/no_exit-Eigenschaft reicht mMn nicht. Da ein Punkt keine Richtung hat, braucht man zusätzlich einen way.
Ein way allein ist auch problematisch, da dann eine mögliche Richtungsumkehr des Weges beachtet werden muss.
Da wäre eine Relation mit einem way und einem node das kleinere Übel, wenn man vereinfachen will.

Seit version 14494 nicht mehr. Wird aber wohl wieder revertiert. Es ist nur noch nicht klar, ob man no_entry / no_exit gleich ganz “verweigern” soll.