Vor- und Nachteile des indirekten Kartierens mittels cycleway=track

Ich verstehe das Problem durchaus. Wenn ich auf meiner Fahrt nach 500 Metern die vielbefahrene Straße mit dem verdammt hohen Bordstein überqueren muss, um dort links abzubiegen, schickt mich der Router auf meinem separaten cycleway ggf. 2 km weit zur nächsten Ampel und von da 1,5 km zurück, wenn dazwischen keine Verbindung zur Straße gemappt ist. Ist natürlich nicht ideal.

Verlasse ich mich dagegen auf meinem cycleway=track blind auf den Router, der mir nach 500 Metern sagt “Alter, hier links abbiegen” und holper dann voller Vertrauen in die Technik den Bordstein runter, gerate in’s Schlingern und falle vor das nächste herannahende Auto, ist das auch nicht ideal.

Ich beiden Fällen wird man vermutlich zu einem besseren Ergebnis kommen, wenn man sich nicht blind auf seinen Router verlässt, sondern rechtzeitig die Gelegenheit zum Mitdenken ergreift … :wink: - ganz unabhängig von dem Modell, dass für das Tagging gewählt wird.

aber wie macht man sie zugänglich? Bei einem cycleway=track kannst Du nicht davon ausgehen, dass Du jederzeit wechseln kannst, daher ist es ja ein track, also ein von der Straße unabhängiger Weg. Klar, es könnte nur ein niedriger Bordstein dazwischen sein, aber es könnte auch ein Pflanzbeet mit hohen Wurzeln und Steinen, oder ein hoher Bordstein da sein (z.B. in meiner Nähe gibt es einen Fahrradweg mit einem ziemlich hohen Bordstein, gibt sicherlich Leute die da hochfahren können, aber die meisten eher nicht, vor allem nicht mal so nebenbei), nur vom cycleway=track lässt sich das nicht erkennen.

Das steht ja schon bei den Vorteilen: es geht schneller und ist weniger Wartungsaufwand. Ansonsten hat man dann halt auch diese Details nicht, weshalb es als Nachteil aufgelistet ist.

Deinen anderen Punkt habe ich als Vorteil aufgenommen.

Ich glaube is_sidepath:of=primary wäre ein solcher Tag.

Eventuell ist eine Gegenüberstellung der Vor- und Nachteile der jeweiligen Systeme besser geeignet und ein paar mehr Worte braucht es auch. Mit den Standard-Routern bin ich nicht zufrieden, daher fällt mir ein Abschätzen schwer. Solange crossing=* und kerb=* nicht verwendet oder nicht vorhanden ist, wird es schwierig. Hier mal ein Beispiel mit begleitenden Rad- und Fußweg (oneway) an einer vierspurigen Straße mit durchgezogenem Mittelstreifen und Bordsteinen:

OFF TOPIC

Mann, in dem Radgeber-Laden da am Spechgassi hab ich vor Ewigkeiten mal ein Tandem gekauft … dass es den immer noch gibt … voll krass :sunglasses:

cycleway=lane [edit: hatte hier vorher aus versehen “track” geschrieben] kann meines Erachtens nur für den lediglich mit eine aufgemalten Linie von der Fahrbahn getrennten Radweg gelten und nicht für einen mit Bordstein abgetrennten Radweg.

vor ein paar Jahren wurde mir noch ein separater Fahrradweg durch ein cycleway=track “ersetzt” wo es Drängelgitter zur Straße hin gibt. Bei nur einer Linie durchgehend finde ich die Lösung an der Straße auch angebracht, aber sobald Sachen umfahren werden oder sonst was dazwischen ist, kann man es mit einem eigenen Weg besser repräsentieren

Ich hab gemeint, dass für so etwas cycleway=lane da ist?

Vielerorts sind die Bordsteine an straßenbegleitenden Radwegen übrigens angeschrägt.

Dort wären Abbiegebeschränkungen sinnvoll.

Ja, vermutlich schon, mit dem Fahrrad die Schenwlinstraße auf Höhe der Belfortstraße als Linksabbieger zu kreuzen ist nicht ganz ungefährlich, aber wenn ich skyper richtig verstanden habe, ging es ihm bei den Beispielen eher um die Darstellung von unzulänglichen Vorschlägen der Fahrradrouter.

Ich habe mich schlicht verschrieben, wollte “…=lane” schreiben. :rage: - war anscheinend heute Morgen noch nicht richtig wach.

Ok, dass geht fürs Fahrrad. Nicht optimal, trotzdem danke. Bei “zu Fuß” sieht das anders aus, dafür haben wir keine Beschränkungen.

Sowohl als auch. Zu Fuß, habe ich die Schnewlinstraße schon an fast allen Stellen gekreuzt, auch z.B. direkt auf der Brücke, wo es eine “Insel” gibt. Je nach Tageszeit, Verkehrslage und Ampelschaltung ist das möglich. Von einem Router für Fahrrad oder zu Fuß würde ich das aber nie erwarten.

Was das Fahrradrouten angeht wird hier glatt am Ende die Einbahnstraße in falsche Richtung benutzt. Ja ich weiß, es gibt besser Fahrradrouter, aber die grundlegendsten Regel sollte schon alle können.

Die Schnewlinstraße ist an der Stelle noch ein weiteres gutes Beispiel, da westlich davon der parallele Zufahrtsweg auch nur über einen Bordstein getrennt ist. Wenn ich mir die Situation jetzt nochmal anschaue, spricht an der Stelle wohl einiges eher für getrenntes Mappen. Und weiterhin bin ich der Meinung, wir brauchen die Barrieren inklusive Bordstein(-höhe) und Übergängen plus Verbindungen an allen Stellen, wo Bordsteine abgesenkt sind. Am schwierigsten finde ich die Kreuzungen an denen zum Kreuzen auf dem Trottoir der Bordstein (auf beiden Seiten) nicht abgesenkt ist, aber das ist hier OT.

…was passiert, wenn man sklavisch cycleway=track einsetzt, kann man sich z.B. hier anschauen: Steindamm in Senftenberg; https://bb-viewer.geobasis-bb.de/?projection=EPSG:25833&center=430908.13091058,5707771.191770395&zoom=13&bglayer=4&layers=25

Mapillary dazu: https://www.openstreetmap.org/#map=19/51.51641/14.00520

Im übrigen waren da mal die Wege separat: https://overpass-turbo.eu/s/1ehs

In meinen Augen ist hier nun die Wegeführung unlogisch und geht bei der Situation vor Ort an der Realität vorbei.

Sven

Die Diskussion wiederholt sich immer wieder. Wirklich Neues kommt kaum hinzu.

Ich hatte schonmal eine solche Gegenüberstellung von Vor- und Nachteilen aus bisherigen Diskussionen erstellt: wiki/User:JochenB/VorundNachteileGetrenntmapping

Die Tag-Seiten sollen vor allem Handlungsemopfehlungen geben. Ich finde eine Auflistung von Vor- und Nachteilen eines Taggingsschemas da nicht so passend. Besser sagen, wann welches Taggingschema seine Vorteile auspielen kann.

Wenn du alle Vor und Nachteile volständig darstellen willst, wird der Abschnitt überproportional groß. Vielleicht besser einfach sagen dass beide Taggingvarianten Vor- und Nachteile haben und meine Gegenüberstellung verlinken. Falls da noch etwas fehlt oder falsch ist, dannn nehmen wir es mit auf / ändern es.

Vielleicht auch das nur das Fazit der Gegenüberstellung übernehmen, wenn das Konsens ist. Das hänge ich unten nochmal dran. Ich finde es besser und neutraler, von beiden Vorgehensweisen die Vorteile zu nennen. Das geht auch eher in Richtung Handlungsempfehlung.

Den Satz "… es aber einige Verfechter gibt, die ein Tagging an der Straße bevorzugen. " empfinde ich als nicht neutral.

Je nach Vorlieben und je nach betrachteten Anwendungsfall wichtet man Vor- und Nachteile anders und kommt zu anderen Ergebnissen. Am wenigsten Konflikte gibt es, wenn immer dann getrennt gemappt wird, wenn der Weg nicht direkt neben der Fahrbahn verläuft. Eine stures Verfechten “immer getrennt” oder “immer zusammen” wird irgendwann zu Diskussionen führen, da war ich auch mal anders drauf. Hier sollte es also nicht um das “Verfechten” der einen oder anderen Variante gehen, sondern um eine für den konkreten Fall angemessene Lösung.

Was “indirektes Kartieren” ist, erschließt sich mir nicht auf Anhieb. Enweder man kartiert es direkt an der Straßenkante oder als seperate Linie.

Hier nochmal die Zusammenfassung aus der Gegenüberstellung als Vorschlag:

Inhaltlich zur fehlenden Verbindung zur Straße beim Getrenntmappung: Dafür gibt es bis heute keine brauchbare Lösung. Das ist der eine Grund, warum ich bei einfachen Verhältnissen weiter für ein Taggen an der Fahrbahn bin, vor allem bei Gehwegen.

Der andere Grund ist, dass es bis heute kein Renderer gibt, der es schafft, getrennt gemappte Geh- und Radwege immer an die Seite der Straße darzustellen. Scheinbar verlangen wir mit unserer Datenstruktur von den Maschinen etwas ab, das sie nicht leisten können. Wir sollten uns nicht für einzelne Renderer verbiegen (Tagging für die Renderer), aber wir sollten die Datenauswerter im Blick haben, wenn wir Entscheidungsspielräume haben.

Inhaltlich zum “Lastenradproblem”: Man könnte beim Taggen des Radwegs an der Fahrbahn problemlos auch die Bordsteinhöhe mittaggen und einen Standardwert festlegen, wenn die nicht getaggt ist (Bordstein=hoch). Insofern liegt der Nachteil nicht strukturell in dem Taggingschema des Zusammen-Mappings, sondern darin, dass das bisher keiner macht.

Einziges strukturelles Problem ist, wenn eine Absenkung am Knoten getaggt wird und diese nicht beidseitig ist. Angaben von “right” und ‘left’ am Knoten werden immer dann uneindeutig, wenn die abgehenden Kanten unterschiedliche Richtungen haben oder mehr als 2 Kanten abgehen. Hier müsste man die Höhe des Bordsteins an die Kante schreiben und die Kante ggf. splitten.

So kurze Kanten sind freilich nicht schön, weil unsere Editoren da keine komfortable Möglichkeit bieten, einen ganzen Straßenabschnitt mit allen zugehörigen Kanten auszuwählen, so dass auch kurze Kanten mit ausgewählt werden.

Alles hat so seine Vor- und Nachteile.

Gähn …
s.
https://wiki.openstreetmap.org/wiki/Proposed_features/Key:is_sidepath#Extension

Hä?!?
Das verstehe ich weder syntaktisch noch semantisch. Was willst du wie an welcher Seite darstellen?

Hilft leider nicht. Damit kann man nicht sagen, welche Gehwegkante zu welcher Straßenkante gehört, somit kann das auch kein Datenauswerter berücksichtigen. Üblicherweise ist mindestens eine von beiden Kanten irgendwo geteilt, oft nicht an der gleichen Stelle. Auch ist oft der Radweg nicht auf der gesamten Länge der Straße vorhanden.

Eine eindeutige Referenz zwischen zusammengehöriger Radweg- und Fahrbahnkante wäre theorethisch über Relationen möglich. Dann muss man aber Radweg und Straße immer an den gleichen Stellen schneiden und für die jeweiligen zusammengehörigen Abschnitte je eine Relation anlegen. Heidenaufwand und fehleranfällig.

Sorry, ich dachte das ist bekannt. Dieterdreist formulierte es im Wiki so:

Je nach Zoomstoofe und Karte sind die getrennt gemappten Geh- oder Radwege von der Straße verdeckt, sind sie mitten auf der Straße oder weit weg von der Straße obwohl sie in Wirklichkeit direkt daneben verlaufen. Ich bin vor langem zu OSM gekommen, weil ich für unsere Stadt und den hiesigen Fahrradverein einen Fahrradstadtplan in den Druck geben wollte. Haben wir bis heute nicht gemacht, genau deswegen.

Heute ist irgendwie nicht der Tag der wertschätzenden Kommunikation, oder habe ich irgendwas falsch gemacht?

Ich verstehe irgendwie nicht das Problem… Für was brauchst du denn diese Info einer genauen Kante-zu-Kante-Zuordnung. Mir würde adhoc keine vernünftige Datenauswertung, die nicht mit “gehört zu einem anderen Weg” (als Fußweg/Radweg) und der Zuordnung mittels Namen/Ref ausreichend arbeiten könnte. Vielleicht habe ich auch Scheuklappen auf?

Vielleicht setzt du dich mit den Machern der “Fahrradkarte” in Verbindung. Die haben das Meiner Meinung nach relativ gut gelöst…?

Warum reduzierst Du nicht einfach die Expansion der Straßenways beim Rendering,
und bei einem Fahrradstadtplan sollten die Radwege logischerweise immer über die Straßenways gerendert werden,
dann werden getrennt gemappten Geh- oder Radwege auch nicht von der Straße verdeckt.