naja, das ist durchaus ungünstig gewählt wenn man es auf einen Node setzt, der Teil einer Straße ist. Da kann man ja nur raten, dass das für den querenden Verkehr und nicht für den auf der Straße gemeint ist.
+1
Zumal in meinen Augen völlig unnötig - denn wenn es ein Pelican ist, kann der querende Weg ja auch nur ein highway=footway sein …
Genau. Deshalb gehören auf den Kreuzungs-Node nur Tags, die beide Ways betreffen, z.B. die Art der Kreuzung an sich (controlled, uncontrolled, zebra, so was). Alles, was nur einen der kreuzenden Verkehrsströme betrifft, gehört an den entsprechenden Way und ist dann eindeutig auswertbar.
–ks
schön dass wir uns einig sind, aber im Wiki steht es seit 2009 anders (pelican crossing, siehe Link oben)
Nein, das ist kein Problem. Das “bicycle” bezieht sich auf keinen der beiden Wege, sondern auf das “crossing=*” bzw. “highway=crossing”. Es verbietet keiner, durch diesen Knoten mit einem Rad zu fahren. Der vorhandene Überweg mit seinen Rechten und Pflichten ist aber keiner für Radfahrer. Das ist auch genau passend für Zebrastreifen: Da darf ich mit dem Rad rüber, habe aber keinen Vorrang im Gegensatz zu Fußgängern.
Mich hat es auch gewundert, dass Router das wie ein barrier=* auswerten.
Naja, als access-Tag halt. Mich wundert da nichts.
Ein bicycle=no an einem Straßen-Way heißt ja auch nicht „keine speziellen Einrichtungen für Radfahrer vorhanden“, sondern schlicht „für Radfahrer gesperrt“. Dafür muss kein barrier=* in Sichtweite sein.
–ks
genau, es bezieht sich auf den Knoten, und damit auf beide Wege (weil man auf den Wegen durch den Knoten muss, der Knoten Teil der Wege ist). Ein highway=crossing steht ja nicht nur in Verbindung mit den Fußweg sondern genauso auch mit der Straße.
OSM als kostenloses Fortbildungsprogramm … 
… bei highway=crossing.
Bei highway=traffic_signal ist das erst seit 1.3.2020(!) drin …
Wie schon oben geschrieben, betritt das Problem einiger Router wohl nur die highway=traffic_signal-Knoten, nicht die highway=crossing-Knoten, von daher keine Fehlinterpretation.
Die provisorische Änderung hat übrigens geholfen, ORM routet dort nun korrekt, an anderer Stelle mit bicycle=no an einem h=t-Knoten weiterhin nicht.
Davon abgesehen halte ich das access-tag an solchen Knoten weiterhin für mindestens fragwürdig.
a. Rein technisch:
- wenn es dort einen kreuzenden highway=path gibt, würde das bicycle=no, so es denn zutrifft, eher an diesen gehören, nicht an den Knoten, den ja auch die highway=xxxxary nutzt …
- wenn es dort keinen kreuzenden highway=path gibt, gibt es eh keine Anwendung für das bicycle=no
b. Rechtlich betrachtet: - Das bicycle=no kommt hier in .de hauptsächlich aus dem fehlenden Radsymbol in der Streuscheibe. Das ist aber völlig irrelevant, wenn es daneben eine Ampel für den allgemeinen Fahrverkehr gibt, dann it die nach § 37 zu beachten, damit wäre ein access-tag fehl am Platze
- selbst wenn es eine solche Fahrverkehrsampel nicht gäbe, sagt das m.E. noch nichts über die Befahrbarkeit der Furt aus, das hängt, wie schon geschrieben, von anderen Faktoren ab. Wenn dort nicht stattdessen § 10 für die Radler gilt (was oft ersatzweise der Fall ist, aber nicht immer), ist das allenfalls unsägliche Behördenschlamperei, aber noch imme kein Verbot.
Besser wäre, das zu taggen, was man sieht:
streuscheibe=Ampelmännchen-West/-Ost
streuscheibe=Radler
streuscheibe=Ampelmännchen&Radler
streuscheibe=Vollscheibe
streuscheibe=Pfeilnachrechts
…
Übersetzen kann das wer anderes … 
Spurmapper können so auch richtig feine streuscheibe=Pfeilnachlinks:Pfeilgeradeaus:Pfeilgeradeausundnachrechts:Pfeilnachrechts-Orgien draus machen! 
Eben!
Nur teilweise richtig.
Bei einem Zebra über eine Hauptstraße stimmt das so.
Bei einem Zebra parallel zur Hauptstraße über die einmündende Straße oder bei einem Zebra an Kreiselzufahrten stimmt das so nicht ganz. Der Radler hat dann zwar keine Rechte aus dem Zebra heraus, aber er hat Vorrang gegenüber Abbiegern parallel zu ihm nach § 9 und Vorfahrt ggü. den Leuten aus der Querstr./ggü. den Leuten, die in den Kreisel fahren nach § 8 …
Idealerweise gibt’s dann genau dafür eine extra Radfurt neben dem Zebra, aber nicht überall ist die Welt ideal …
Eigentlich logisch. bicycle=no = den Weg oder Knoten darf man mit Rad nicht nutzen, egal warum …
Bei ways ja, bei Nodes gibt es Objekte, wo das access-Tag missbraucht wird, zB information=guidepost, bicycle=yes.
Router sollten deshalb bei Nodes zusätzlich auf barrier prüfen.
Andersrum wird ein Schuh draus, wenn ich darstellen will, dass es keine Ampel für Radfahrer (oder was auch immer) gibt, dann muss ich ein zusätzliches Tag erfinden.
Ob der Node eine Barriere ist oder nicht spielt doch hier gar keine rolle? access=no heisst access=no und nicht: “nur access=no, wenn auch ein barrier dabei ist UND es ein Node ist UND Vollmond” Und wenn sich da irgendwer im Wiki oder sonstwo was anderes dabei gedacht hat, ok, das ist dann aber nicht mehr intuitiv wie der grösste Teil des restlichen Taggings.
Was du aufzählst sind alles Dinge, die sich direkt aus der Situation ergeben und identisch wären, wenn da kein Zebrastreifen wäre. Sogesehen hat das gar nichts mit dem crossing sondern nur mit allgemeinen Regeln zu tun.
Es hat dann was damit zu tun, wenn dort osm-technisch EIN Weg für Rad/Fuß die Straße kreuzt.
Wenn dort KEIN Weg kreuzt, dann beträfe es “nur” den Längsverkehr, wie im auslösenden Bsp. Dann braucht es aber auch keine access-tags, weil da kein Verkehr kreuzt …
Wenn dort ZWEI Wege kreuzen, einer für Rad- und einer für Fußverkehr, könnte man, vorausgesetzt es gäbe das eben erwähnte Längsverkehrproblem nicht, der crossing des Fußweges das bicycle=no verpassen (aber warum macht man das dann nicht an den Weg?) und es am anderen crossing weglassen, aber wer macht bei sowas schon getrennte Wege für Fuß und Rad, wo sich viele schon darüber aufregen, dass es neben der Fahrbahn noch einen getrennten Weg gibt? Eben: praktisch niemand.
Damit sind wir wieder bei EINEM Weg, der da kreuzt, für Fuß und Rad mit segregated=irgendwas und dann ist das bicycle=no idR falsch, egal ob Zebra oder Ampel ohne Radstreuscheibe, weil es eben auch noch andere Regeln gibt als die des Zebras und der Ampel …
Und zum Längsverkehrsproblem:
Und die Vollmondfrage kann eh komplex werden.
Im Moment basiert eine Auswertung von Knoten mit access-Tags darauf, dass ein bicycle=no wohl nur für den querenden Rad-/Fußweg gilt.
Ich würde aber meine Hand nicht dafür ins Feuer legen wollen, dass es in NL oder DK nicht schon längst Fußgängerampeln über hochfrequentierte Radverbindungen gibt und dann stehste dumm da mit dem bicycle=no für den querenden Fußweg …
Also access-tags an die Wege, wenn die gerechtfertigt sind (eben nicht immer, wie schon beschrieben) und für “hat keine Radstreuscheibe” was eigenes erfinden, was am Kreuzungsknoten auch nicht so einfach ist, weil da immer noch nicht die Ausrichtung klar ist …
Was ich meine ist etwas anderes: Natürlich gibt es da einen Weg, und der hat natürlich kein bicycle=no. Ich rede von dem Kreuzungsknoten, der die Informationen zum Überweg darstellt. Der kann problemlos ein bicycle=no haben wenn die Überwegs-Informationen eben nicht für Radfahrer gelten. Dieses bicycle=no ist kein access-Tag, sondern eine Eigenschaft des Überwegs. Genau wie das bicycle=yes an einem Wegweiser hat es die Aussage “Dieser (Überweg|Wegweiser) ist für Radfahrer (nicht) gedacht”.
Wenn ich das im Wiki suche, lande ich aber bei access-tags.
Dass bicycle=no kein access-tag sein soll, muss man sich mühsam aus dem Zusammenhang zusammenreimen, was spätestens beim Vollmondfrage-Bsp. versagt … Bei einigen Routern anscheinend schon vorher …
Besser wäre es, wenn man den Zusammenhang klarer mit gibt, dass eindeutig kein access-tag sein kann, wie im “Not-Tag” “traffic_signals:bicycle=no” gemacht, auch wenn auch das nicht vollmondfragentauglich ist, weil noch die Ausrichtung am Kreuzungsknoten fehlt … Also noch besser eigenen kreuzungsfreien Ampelknoten …
genau, bicycle=* ist ein access-tag und für andere Bedeutungen sollte man andere tags verwenden. Besser spät (?) als nie.
Bitte keine überhasteten Umtag-Aktionen, die am Ende hunderttausende von Objekten betreffen, nur weil eine Routing-Software mal Mist gebaut hat.