IMHO:
oneway:psv=no
oneway:emergency=no
oneway:bicycle=no
Ich würde diese Variante bevorzugen. Ein Beispiel, wo dies so gelöst ist: https://www.openstreetmap.org/node/57138384
mit except=psv,emergency,bicycle würdest du die Ausnahme durch die Zusatzschilder hinzufügen.
1 Like
Nein, das wäre falsch, weil es auch falsch wäre eine sogenannte “unechte Einbahnstraße” mit oneway=yes zu versehen. Gibt es nämlich kein blaues Einbahnstraßenschild sondern nur am anderen Ende ein Verbot der Einfahrt, darf jeder Verkehrsteilnehmer auf der Straße wenden und in die andere Richtung weiterfahren. Nur an dem Einfahrt-Verboten-Schild darf man nicht in der einen Richtung vorbeifahren.
Ich weiß dies sehr genau, weil ich daran mitgewirkt habe, dass in dem Städtchen, in dem ich lebe, eine solche “unechte Einbahnstraße” mitten in der Altstadt eingerichtet wurde.
Rechtlicher Hintergrund ist: Man darf eine Einbahnstraße wohl nicht entgegen der Fahrtrichtung für Linienbusse freigeben. Das ist nur für Fahrräder zulässig.
Insofern hat ma-rt-in in #2 die beiden möglichen Varianten genannt. Wie gesagt: Bei beiden Varianten darf nicht die gesamte “unechte Einbahnstraße” mit oneway=yes versehen werden.
Beispiel für die Variante mit dem kurzen Einbahnstraßenstück im Bereich des Einfahrt-verboten-Schildes: https://www.openstreetmap.org/way/28166808
da es sich um keine Einbahnstraße handelt und auch kein entsprechendes Schild da steht, würde ich von dem Hack mit einem unendlich kurzen Stück Einbahnstraße absehen und eine Restriction Relation verwenden. Einschließlich der Ausnahmen natürlich
Tja, damit fängt eine unendliche Diskussion von Neuem an . und ich schätze, daß es nicht die letzte Diskussion zu dieser Thematik sein wird …
Deshalb: Gibt es nicht irgendeinen Weg, dieses Thema ein für allemal einer Lösung zuzuführen, die dann auch hinreichend nachvollziehbar in der OSM-Wiki zu finden ist?
Seufzend
tracker51
Danke für die Hinweise, ich würde es dann über eine restriction-no_entry machen (die kannte ich so noch nicht). Die Krücke mit der kurzen Einbahnstraße halte ich für nicht gut.
Das ist Tagging für den Router und de-facto falsch.
way[oneway=yes](if: length() < 2)({{bbox}});
(._;>;);
out;
Leider ist diese Lösung für Anfänger manuell nur schwer umzusetzen. Es wäre wünschenswert, wenn diese ebenso wie andere Abiegerelationen in den iD-Editor intergriet würde. Das ist leider anders als bei anderen restictions bislang noch nicht der Fall.
Naja, ob es wirklich falsch ist, darüber könnte man streiten. Man könnte schon der Auffassung sein, dass man auf einem kurzen Straßenabschnitt direkt neben dem Schild nur in einer Richtung unterwegs sein darf.
man kann es ggf so annähern und es wird kaum einen praktischen Unterschied machen, aber falsch ist es schon. Verbot der Einfahrt ist eben nicht Einbahnstraße. Wer die Einbahnstraßen zählen will würde zB. durch oneway tagging hier einen Fehler in seine Statistik bekommen
Auf einem sehr kurzen. Einem sehr sehr kurzen. Genau genommen Länge Null. Ein Way mit Länge Null ist in OSM ein Node. Aber der hat wieder keine Richtung. Und ein 1 cm langer Way ist alles andere als wartungsfreundlich für den nächsten user.
Wenn man keine no-entry-Relation verwenden will, gibt’s auch noch die Möglichkeit, den durchgehenden Way am Schild aufzuteilen und in der verbotenen Richtung eine no-straight-on-Relation einzubauen. Das wäre sachlich noch “richtig”, weil es das Verbot abbildet, in der falschen Richtung am Schild vorbei zu fahren. Und hätte für den nächsten Bearbeiter den Vorteil, dass restrictions in allen Editoren unübersehbar deutlich angezeigt werden.
Aber eine wirkliche Einbahnstraße mit den dazugehörigen Regelungen (kein Rückwärtsfahren) ist da nirgends, nicht einen Meter weit, und dann gehört auch keine in die Daten.
Dieses Stück wäre wenn dann infinitesimal klein (zwei Nodes mit denselben Koordinaten). Und das zu editieren macht keinen Spaß.
Außerdem fehlt es einfach am Einbahnstraßenschild.
Ich habe es problemlos mit iD getaggt. Ganz normal wie eine Abbiegebeschränkung und dann unter Eigenschaften im Auswahlklappmenü der Restriction “no entry” ausgewählt (muss man aber etwas runterscrollen).
Das ist kein hinreichender Grund gegen oneway=yes, da auch viele andere anders begründete Fahrtrichtungsbeschränkungen so gemappt werden wie Richtungsfahrbahnen geteilter Straßen, Autobahnauf- und -abfahrten, Einrichtungsradwege, Kreisverkehre, … Da steht überall kein blaues Einbahnstr.schild … Bzw. nur selten (bei geteilten Fahrbahnen sieht man es ab und zu, insbes. wenn sie zu weit auseinander sind)
Ok, dann hatte ich das beim Scrollen wohl übersehen. Allerdings ist anders als bei Abbiegebeschränkungen keine Bezeichnung dafür hinterlegt. Angezeigt wird das als “Sonstige Abbiegevorschrift”, während z.B. bei “no_u_turn” “Keine Kehrtwende”, bei “only_straight_on” “Nur geradeaus”, … angezeigt wird.
Diese Relation scheint sehr selten, wird das ausgewertet?
https://taginfo.openstreetmap.org/tags/restriction=no_entry - 845 (!)
https://taginfo.openstreetmap.org/tags/type=restriction - 1,5 Mio
Update: im Link aus Post #1 scheint eher eine Einbahn auf OSRM und Graphhopper zu wirken (braucht wohl noch bis aktualisiert)
Da bei allen Restriktionen nur der erste Teil wesentlich ist, sollte ein Auswerter mit allen no_xxx und only_xxx klarkommen.
Die “no_entry” Relation passt gar nicht zu den andren Einschränkungen. Von welcher andren Straße man kommt ist ja ganz egal. Das könnte genausogut mit einem Knoten gelöst werden, vergleichbar dem Stopp-Schild, das man die Richtung vom Weg erben lassen kann. Hier wird mit Kanonen auf Spatzen geschossen.
1 Like
Deshalb kann eine no_entry Relation beliebig viele from-members haben. Da ist die Möglichkeit eingebaut, dass die Einfahrt von EINER der anden Straßen erlaubt ist. Die lässt man dann aus dem from raus.
Ich würde noch die Möglichkeit einbauen, beim no_entry gar keine from-members festzulegen, sondern nur via und to. Die Restriction gilt dann für alle Routen, die über das via zum to führen. Entsprechend beim no_exit nur from und via. Aber man kann sich in beiden Fällen auch mit einem no_straight_on behelfen, wie ich oben schon geschrieben habe.
Hmm, die Möglichkeit, dass das Schild passierbar ist, die braucht man sich nicht freihalten. Die ist per Definition ausgeschlossen. Gegenbeispiel?
Wer schreibt das Proposal “highway=no_entry;direction=forward|backward”? Router dürfte das nicht über Gebühr belasten, die müssen wohl eh schon alle Knoten eines Wegs auf zB Boller prüfen. Macht das Kartieren einfacher, im Editor und auf Karten könnte man das dann problemlos anzeigen.