Zugangsbestimmungen auf Straßenpunkten mit Wert "no"

Gerade auf crossing=unmarked gefunden, ist aber nicht der einzige Fall und leider auch öfters in den Daten:

Hervorhebung von mir

Ist das Verwenden von negativen Zugangsbestimmungen nicht gefährlich, wenn es sich um Beschreibungen handelt, die mit der eigentlichen Straße nichts zu tun haben?
Ein weiteres sehr prominentes Beispiel ist public_transport=stop_position, oder werden die Zugangsbestimmungen bei entsprechenden Hauptmerkmalen von Routern ignoriert?

Den Schlüssel wird nur auf der DE-Seite im Wiki genannt!

Sachen die ich bisher so gesehen habe:
Es kreuzen sich 2 Straßen die jeweils ein cycleway=lane/track haben. An jeder Seite gibt es eine Fußgängerampel.
Man könnte mit bicycle=no versuchen zu verhindern, daß Fahrradfahrer die Fußgängerübergänge benutzen.

Dinge mappen die irgendwelche theoretischen Probleme lösen.
Oder Dinge mappen weil sie sich mappen lassen.
… ist ja aber auch ein allgemeiner Trend. :frowning: In letzter Zeit entdecke ich laufend neue covered=no an irgendwelchen Wegen…

Von mir aus kann der Schlüssel gerne aus crossing=unmarked raus.
PS: Bei crossing=traffic_signals wird der Schlüssel ebenfalls angepriesen und ebenfalls nur im deutschen Artikel.

Und ein Pferdefleischer ist dann

shop=butcher
horse=yes

siehe hier

Der wird sich freuen, wenn ein Pferd in den Laden reinkommt.

Soviel zum Verwenden von access-Tags an Punkten

:slight_smile:

Kommt wohl auf den Zustand des Pferdes drauf an und ob noch selbst geschlachtet wird. :stuck_out_tongue:
Solange das nur als Punkt und nicht mit ans Gebäude getaggt ist, stört mich das weniger, aber die Problematik ist eigentlich die Gleiche.

Im Ernst, mir geht es darum, dass sowas nicht auch noch im Editor vorgeschlagen wird.
JOSM Ticket 21400 hat das für stop_position geregelt, aber crossing habe ich wohl übersehen. Werde wohl einen tieferen Blick in die Vorlagen werfen und alle durchforsten müssen.

+1

Wenn der mit ‘no’ getaggte access-Ablieger an einer Barriere steht, dann sollten ja alle Wege die an diesen Punkt anschließen für die entsprechenden Zugang gesperrt sein, dort ist das m. E. richtig. Aber bei Kreuzngen lässt es sich doch garnicht festlegen, für welche Richtung dieses Tag gilt oder?

Gefährlich wohl kaum, es sei denn, ein Router wertet “nur mal so aus Spaß” auch alle access Tags von allen Knoten aus. Ich kenne nur barrier=* wo das nötig ist, folglich wird das zuerst geprüft (zumindest in mkgmap).

Na ja, barrier=* besagt ja nur, dass man dort nicht durchfahren/gehen kann. In manchen Fällen ist es erlaubt, mit dem entsprechenden Fahrzeug auf beiden Seiten bis an die Barriere ranzufahren. Meist ist allerdings auch der reale Weg auf einer der beiden Seiten dann entsprechend markiert. In OSM sollte ein barrier=* Knoten niemals Teil von mehreren Wegen sein.

Ja, ist es.
Vor allem nicht an Kreuzungsknoten.
Denn der gehört ja zu ZWEI Wegen.
Selbst wenn er am EINEN Weg richtig wäre, dass da keine Radfahrer fahren dürften (was nicht unbedingt immer so sein muss …), ist das Tag für den ANDEREN Weg so gut wie NIE richtig!

Genau das Problem hatte ich vor gut einem Jahr hier schon im Forum diskutiert, wo man die Abwesenheit von Streuscheiben für Radfahrer in Ampeln mit bicycle=no gemappt hat, was dann einige Router als Radfahrverbot über diesen Knoten gedeutet wurde.

Grundsätzlich ist es aber so, dass die Kreuzung mit Rad hier nicht möglich ist. Also muss man es auch irgendwie taggen können. Da das ‘bicycle=no’ für alle Richtungen gilt, muss man es auf die Kkreuzungs-Richtung beziehen. Das müsste so gehen, oder?:

highway=crossing 
crossing:bicycle=no

Im Prinzip könnte man das auch an der Linie taggen, wenn das Überqueren der Straße nicht gestattet oder möglich ist. Das könnte beim Routing für Fuß- und Radverkehr helfen.

Wo ist “hier”?
“Hier” im Faden sehe ich gerade keine konkreten Bsp.
“Dort” in meinem alten Faden sind es m.E.n. alles Stellen, wo “bicycle=no” nirgends als access-tag korrekt war, weder längs noch quer, und nur “keine Radstreuscheibe” bedeutet hat.
Ob es “hier” im Faden, wo es um ampellose Kreuzungsstellen geht, korrekte access-Anwendungen gäbe, müsste man das am konkreten Bsp. durchdiskutieren. Oft irrt da der gemeine Endanwender der Verkehrsregeln … :wink:

Wäre schon mal besser, weil dann dumme Routing-Maschinen, die nur bicycle=* suchen, das dann ignorieren. “Intelligentere” könnten immer noch vor dem Problem stehen, in welche Richtung sie es anwenden sollen, daher ist das auf jeden Fall der bessere Weg:

Genau dorthin gehören access-tags, punktförmige Barrieren auf Nichtkreuzungsknoten mal ausgenommen, da können sie auch ran.

Nicht genau gemappt werden könnten so evtl. Kreuzungsradfahrrechte an Straßen mit straßenbegleitenden Radwegen, wo die Radeltags an der Gesamtstraße statt an separaten paths/… hängen. Das sind aber Fälle, wo real der Radweg so direkt an die Fahrbahn geklatscht ist, dass man ein “no” kaum für eine Querungsstelle annehmen dürfte, da mindestens die Benutzung für das Wenden auf den Radweg auf der anderen Seite über die Querung erlaubt sein sollte, wartepflichtig natürlich. Und wenn kein Radeltagging an der Gesamtstraße gemappt ist, ergibt sich das Problem eh nicht.

Gut, bicycle=no an Übergängen wird zumindest bei JOSM nicht mehr angeboten. Den Schlüssel in crossing:bicycle zu ändern habe ich mich nicht getraut. Wenn ich mir den Edit-war auf z.B. highway=crossing anschaue. Habe ich da ein abgekühltes Eisen wieder zum glühen gebracht?

Insgesamt ging es mir aber eben nicht nur um Übergänge sondern allgemein um access Tags mit einschränkender Wirkung an highway-Knoten.

Mag für diesen Wert gelten aber auch im Englischen finde ich Seiten, s.o.

Ja, gefährlich war hier falsch. Gibt die Straße ja nicht frei sondert sperrt sie eher.
Danke für die Info zu mkgmap.

Vorsicht, zwei Wege, jeweils als Anfangs-/Endknoten, ist schon ok.

Danke, scheint ja nicht wirklich zu einem Ergebnis gekommen zu sein, denn die Wiki-Seite der Übergänge wurden nicht angepasst.

Genau, an die Linie gehören die rechtlichen Einschränkungen (Verkehrszeichen). Setzt aber separates Geh/Radweg-Mapping voraus. Hier erreichen wir eine der vielen Grenzen des Geh/Radweg-Taggings am Straßen-way.

Der Missbrauch von access-Tags für das “Können” halte ich für nicht sinnvoll und widerspricht auch der ursprünglichen Definition der access-Tags. Was meint ein ‘foot=yes’ an einer Barriere? Schlanke Menschen, Menschen mit Gehhilfen wie Rollatoren, Kinderwagen, …? Bei Fahrrädern das gleiche Dilemma. Was ist mit Pferden? Und so weiter und so fort. Man kann die maximal mögliche Breite (maxwidth:physical) erfassen. Das macht Sinn.

Hatte noch keine Muße für’n Editwar o.ä.

Wie gesagt: Die beim straßenway-tagging nötige räumliche Enge gibt idR keinen Spielraum für ein no, yes o.ä. wäre ja kein Problem …

Rollis könnte man ja noch abweichend von foot extra behandeln mit wheelchair …
Spezialradfahrer haben nix und können bei cycle_barrier und anderen große Probleme haben, wo Normalradler nur müde lächeln …

Die Barriere alleine entfaltet aber nur eine geringe rechtliche Wirkung. Aus § 43:

bzw. Anlage 4

Also nur die Fläche des Pfostens selbst darf nicht befahren werden, ggfs. 'n cm mehr drumrum, wenn der Bommel oben o.ä. größer sind.
Was dran vorbei passt, ob Fußgänger, Radfahrer, Motorradler(!) oer evtl. eine Ape, darf vorbei … Anders wäre es nur wenn in der Nähe ein Vz 260 stünde …

Ja, beim Getrennt-Mapping von Gehwegen gehört das an die Kreuzungs-Linie. Ich habe es aber auf das Zusammen-Mappen bezogen.

Beim Taggen der Rad- bzw. Gehwege an der Straßenlinie ist implizit, dass man an jeder Stelle auf die andere Seite kommt. Das ja ein Vorteil dieser Taggingvariante*. Mit einem ‘crossing:xyz=no’ an der Streßen-Linie kann man in dieser Taggingvariante abbilden, dass das Queren nicht möglich ist. Dann müsste der Router einen bis zur nächsten Keuzung oder zum nächsten Knoten mit ‘hw=crosssing’ schicken, um auf die andere Seite zu gelangen.

“Hier” im Sinne von “In dieser Diskussion”. Hier in dieser Diskussion geht es um access-Tags an Knoten. :slight_smile:

*) Vor und Nachteile Getrenntmapping siehe hier: https:wiki/User:JochenB/VorundNachteileGetrenntmapping

Stimmt, dann ist das Routen über den Knoten hinweg gesperrt und nicht die Kanten.

Grundsätzlich kann es immer vorkommen, daher müssten die Datenauswerter damit umgehen können.

Gedankenspiel: wenn mittig auf der Kreuzung eine Panzersperre steht, die den Fahrzeugverkehr in allen Richtungen sperrt?

Dann sollte der Mapper evtl. zwei Knoten mit barrier=* verwenden. Ich denke, ein Router ignoriert besser Knoten, die zu mehreren highway=* Wegen ghören, weil völlig unklar ist, welcher Weg betroffen ist. Man kann man eine Ausnahme machen, wenn es genau zwei highway=* gibt, die an einem barrier=* verbunden sind. Das engl. wiki ist da auch ziemlich klar. Im deutschen wiki wird davor nur gewarnt.

Das ist doch aber nötig zu haben. Bspw. Betonklötze auf der Straße mit Lücken, dass ein Fahrrad durch passt, ein Auto aber nicht. Oder Höhenbeschränkungs-Barrieren. Gibts in China recht häufig um LKW-Durchgangsverkehr zu verhindern. Einfach ein Rohr in 2.5m Höhe. Gut, dass wäre dann max-height und kein xyz=no.

Wieso? Wenn sich die Wegeigenschaft an der barriere ändert, würde man den way in OSM aufteilen und die Barriere wäre teil beider ways. Theoretisch kann das auch auf einer Kreuzung getaggt werden, aber das wäre dann eher ein Sonderfall. Aber beides wäre legitim. Man muss halt wissen, was die Konsequenz ist. Ein Beispiel könnte eine Furt sein, die ich nicht befahren darf. Die wäre am Kreuzungspunkt von Fluss und Straße eingetragen und hätte bspw. vehicle = no.

Solange da kein Verkehrszeichen ist, darf dort alles entlang was durch passt → maxwidth:physical

+1 Es ist durchaus eine Straßenkreuzung denkbar, die im Kreuzungsbereich für alle Richtungen durch Poller oder Steinblöcke gesperrt ist. Eine Sackgasse für alle hier einmündende Straßen.

Stimmt, dann halt ohne Lücke und mit access=no :sunglasses: