Taggen von Fahrrad-Komforthilfen

Vermutlich nicht. Wenn eine Kreuzung so stark vereinfacht wurde, dass nur ein einziger Ampelknoten vorhanden ist, dann natürlich nicht. Aber ich finde auch das momentane cycleway=asl ungünstig, weil ein Auswerter eben nicht so einfach gucken kann, ob an einer Ampel ein Velosack (Danke an die Schweizer für dieses Wort) vorhanden ist. Ich fände es besser, wenn man das als Eigenschaft einer Ampel vermerken kann und zusätzlich die genaue Position an einem separaten Node (in etwa so, wie wir auch Bushaltestellen-Features erfassen). Natürlich kann man das alles in der Theorie aus der Position ableiten, in der Praxis ist das allerdings sehr komplex und wird deswegen einfach nicht gemacht.

Das Proposal schlägt cycleway=footrest als searaten node vor, was konsistent mit cycleway=asl ist. Ob es jetzt sinnvoll wäre an den highway=traffic_signals-Node jetzt noch zutätzlich so etwas wie bicycle:footrest=yes / bicycle:asl=yes zu packen weiß ich nicht. Vielleicht können diejenigen, die Router programmieren, was dazu sagen.

Wie gesagt, wie willst du am Knoten modellierren an welchen der Straßen die Dinger vorhanden sind. Es sind ja oft nur einzelne an Kreuzungen. Das irgendwo eine ist hilft ja auch nicht viel weiter. Und wofür willst du das überhaupt benutzten? Eine komfortable Route? Wenn man eine Beziehung zur Ampel(anlage) benötigt, dann wäre wohl eine Ampelanlagen-Relation sinnvoll.

Das Problem besteht bei vereinfachten Kreuzungen ja immer. Haben alle Fußgängerüberwege Blindenleitpflaster und akustische Signale oder nur einige? Im Endeffekt müssen diese Altlasten halt detaillierter gemappt werden. Das würde für mich also nicht zwangsläufig gegen ein Tagging an der Ampel sprechen.

Aber spätestens, wenn wir sowas dann an einem anderen Ort haben (Bahnübergang, Fähranleger whatever) haben wir wieder ein Problem, dass wir es nicht taggen können. Also vielleicht trotzdem besser mit cycleway= als Knoten auf dem Radweg.

Ich würde das nur dort machen, wo die Ampeln fur jede Straße einzeln erfasst sind, alles andere hat ja keinen Sinn.

Das würde einem aber auch nicht sagen, ob genau an der Ampel, über die man fahren muss, so eine Vorrichtung steht. Man möchte ja eine Relation zu einer bestimmten Ampel, nicht zur ganzen Ampelanlage. Und da wäre ein Tag am highway=traffic_signals nicht verkehrt. Zusätzlich zur explizit vermerkten Position, wo es ist.

Einen anderen Nutzen kann ich nicht sehen. Ich kenne mittlerweile eine Menge Menschen, die Spezialfahrräder benötigen, die eben nicht der Norm entsprechen. Die Gründe sind vielfältig, aber fast immer geht es um eine körperliche Behinderung. Für einige dieser Personen ist das Absteigen an der Ampel eine Qual, aber eben leider auch eine Notwendigkeit. Wenn es irgendwann mehr von diesen Vorrichtungen gibt, wäre es sicher sinnvoll, wenn man sich einen Weg suchen lassen kann, der wenige Ampeln und/oer viele von diesen Hilfen enthält.
Solange jede Stadt nur 2 oder 3 davon hat ,ist das sicher zum Routen uninteressant, aber in Städten wie Kopenhagen, wo es eher die Regel als die Ausnahme ist, wäre das durchaus möglich.

Aber um die Frage mal direkt zu beantworten: Ich werde das wohl nie benutzen, aber wenn man schon Daten einträgt, dann fände ich es gut, wenn man sie wenigstens gut nutzen kann.

1 Like

Also vielleicht trotzdem besser mit cycleway= als Knoten auf dem Radweg.

an der tatsächlichen Position mappen, dann ist die Seite klar. Wenn das längere Schienen/Rohre sind, dann will man die vielleicht auch linear mappen, da könnte “cycleway” als key vielleicht für Verwirrung sorgen? Kommt vielleicht auf den value an?

Dann ist es noch weniger praktisch auswertbar und fast nur noch für den Renderer verwertbar.

Es ist bereits amenity=cyclist_leaning_rail in Verwendung – ist auch mal auf Basis einer Diskussion auf der Tagging Mailing List entstanden (Proposal:Amenity=cyclist leaning rail - OpenStreetMap Wiki).

1 Like

Mit 23 Verwendungen exakt gleichauf mit cycleway=footrest. Was die Benennung angeht, wäre einer von diesen Muttersprachlern jetzt hilfreich, aber vermutlich gibt’s das weder bei den Briten, noch bei den Amis :thinking:

Ob jetzt amenity oder cycleway … herrje, ergibt beides irgendwie Sinn

1 Like

Ich wäre dagegen, das ohne Verbindung zum highway zu mappen, aus den von @Langlaeufer genannten Gründen. Wenn es die wirklich in verschiedenen Größen geben sollte, würde ich vorschlagen, das über capacity= abzubilden statt geometrisch.

Cyclist footrest ist dafür ziemlich etabliert:

Unter “cyclist leaning rail” konnte ich keine nennenswerten Quellen finden.

footrest beschreibt aber nur eine der Bauformen

Vielleicht sollte man da einen Oberbegriff finden, der die Dinger zum Festhalten (Haltebügel) und zum Drauftreten (Fußstützen) zusammenfasst. und dann erst durch weiteres Tagging genauer werden.

3 Likes

Guter Vorschlag. Es gibt ja auch noch so etwas:

oder

Ich würde das mal im Deutschen mit „Stehhilfe“ oder „Wartehilfe“ zusammenfassen, aber das ist sicherlich keine offizielle Bezeichung. Oder zieht ein cycleway=waiting_aid + waiting_aid=footrest? Hmmm…

Ich wäre dagegen, das ohne Verbindung zum highway zu mappen, aus den von @Langlaeufer genannten Gründen.

ist wie highway=bus_stop oder traffic_sign=city_limit oder Verkehrsschilder, wer die Position auf den highway projizieren will, z.B. für Routing, kann das ohne größere Schwierigkeiten in einem Vorverarbeitungsschritt tun, das ist nicht unmöglich sondern relativ trivial

Bushaltestellen werden mit public_transport=stop_position auf die Straße gemappt, die meisten routingrelevanten Verkehrsschilder wie highway=stop und highway=give_way werden ebenfalls auf den Way gemappt. Dieses Zuordnen von separaten Nodes zu einem Way ist erstens meines Wissens nur theoretisch möglich (oder kennst du Router, die das wirklich machen?) und zweitens fehleranfällig in Kreuzungsbereichen, wo der Node evtl. nicht am nächsten an dem Way ist, für den er gilt.

2 Likes

Ich halte es nicht für sinnvoll, diese Einrichtungen zu gruppieren und das Tagging damit unnötig zu verkomplizieren. Ich denke, das kann beides einfach ein Wert für den cycleway-Tag sein. Ich weiß aber noch nicht, was der passende Begriff für den Griff ist.

Dieses Zuordnen von separaten Nodes zu einem Way ist erstens meines Wissens nur theoretisch möglich (oder kennst du Router, die das wirklich machen?)

es ist möglich, ich kenne mich nicht aus, was die Router machen, grundsätzlich aber kann jeder Router für einen Punkt die nächstgelegene Straße finden, sonst müssten wir alle POIs mit dem Straßennetz verbinden

und zweitens fehleranfällig in Kreuzungsbereichen, wo der Node evtl. nicht am nächsten an dem Way ist, für den er gilt.

in der Praxis selten relevant, theoretisch denkbar

Das ja, aber hier würde es ja genau umgekehrt gehen: finde Punkte in der Nähe der Straße und schau dann, ob die aktuelle Straße die ist, die den Punkten an nähesten ist und zwar unter Berücksichtigung der Straßenseite und -breite…

Das ja, aber hier würde es ja genau umgekehrt gehen: finde Punkte in der Nähe der Straße und schau dann, ob die aktuelle Straße die ist, die den Punkten an nähesten ist und zwar unter Berücksichtigung der Straßenseite und -breite…

ich schrieb ja Vorverarbeitung. Man nimmt alle solchen Punkte, projiziert jeden von ihnen auf die nächste Straße, da ist nichts umgekehrt, ist genau dasselbe

Es tut mir leid, hier schon wieder von der Seite reinzuplatzen, aber ich habe dieses Thema nun nocheinmal im internationalen Forum platziert, um ein größeres Stimmungsbild einzuholen und insbesondere auch Erfahrungen zu Begrifflichkeiten aus anderen Ländern einzusammeln, um im besten Fall zu einem passenden Tagging/zur Fortsetzung eines Proposals zu kommen:

Gerne also (auch) dort beteiligen :slight_smile:

3 Likes

Auf das aktuelle Proposal wird jetzt auch in der Wochennotiz hingewiesen.