Ich finde es nicht hilfreich, die verschiedenen Anwendungen der Daten gegeneinander auszuspielen. Ich möchte aber kurz daran erinnern, daß OSM gegründet wurde, um Daten für den Bau einer routing-engine zu bekommen.
Es scheint sich noch niemand öffentlich Gedanken gemacht zu haben, wie man mikromapping und routing unter einen Hut bekommt. Vermutlich weil jeder ahnt, daß dabei ein Drittes auf der Strecke bleibt: Einfachheit.
Baßtölpel
Ist das überhaupt relevant? Welches Navi wechselt dann einfach mitten auf der Straße die Seite, oder zwischen Fahrban und Radweg? OsmAnd tut das nicht. Wenn Navis sowieso generell nicht mitten auf der Straße die Seite wechselt, sondern an Kreuzungen, Einmündungen, an denen es auch in der Realität geht, ist das separate Eintragen der Fahrradwege überflüssig.
Ich kenne genug Situation, in denen von den straßenbegleitenden Radweg mehr Wege abgehen als von der Straße, ein Linksabbiegen aber nur über Umweg oder Nutzung der Fahrbahn möglich ist. Außerdem verlaufen Radweg oftmals nicht parallel zur Straße.
Wir mappen die Daten wie sie in der Realität vorhanden sind. Und da kann ein Radweg neben einer 3-spurigen Straßen durchaus 8-10 m neben der (gemappten) Mittellinie der Straße liegen. Und vielleicht nutzen künftige (genauere) Navis eine Kamera, die erkennen, auf welcher “Spur” man sich befindet …
Moin,
das ist eigentlich genau das Argument, das für getrennt gemappte Wege spricht. 
Grüße, Georg
Nein, denn genau dafür gibt es lanes.
Das ist ein Problem der Anwendung damit gut umzugehen mit den Ungenauigkeiten des Gerätes usw… man zeichnet ja schließlich nicht für eine Anwendung… oder einem Renderer.
OSMand kann sehr wohl damit umgehen… zumindest ein bisschen… . OSMand formuliert dann so Ansagen wie “leicht” links Abbiegen… (oder so ähnlich)
Dann gibt es noch Anwendungsfälle wie Rollstuhlfahrer-Routing… wo es immer mehr notwendig machen das extra zu mappen… mit Bordsteinhöhen usw. 
Die Frage stellt sich, ob für das Navigieren allein das Gehör oder nicht auch das Auge gelten soll. Aber das ist eher ein generelles Problem der Anwender von diesen Anwendungen, denn sonst würden solche Geschichten “das Navi hat mich hierhin geführt” nicht existieren.
Zum Fahrradrouting bei getrennt laufendem Radweg, gibt es die Möglichkeit ein access-Tag “bicycle=no” (edit: was ich nur in absoluten Ausnahmefällen anwenden würde) an die Straße zu setzen, aber ob das bei allen Straßen korrekt ist, kann man nur vor Ort herausfinden. Ich war aber davon ausgegangen, dass die RoutingApps bei vorhandenem parallelem Radweg diesem gegenüber der Straße den Vorzug geben, von daher ist es, wie schon mehrfach ausgeführt, Sache der Anwendung.
Ich kann mir keinen Fall vorstellen, wo ein kategorisches bicycle=no allein aufgrund eine getrennt laufenden Radwegs gerechtfertigt wäre. Entweder steht ein explizites (Z254) oder implizites (z. B. Z275 oder Z331-1) Verbotsschild an der Straße oder die Benutzung der Straße ist unter Umständen auch immer für Radfahrer erlaubt.
Lustig wird das Routing auch, wenn der Bürgersteigmapper vergisst den Weg mit den einmündenden Querstraßen zu verbinden.
Wie hier in Dortmund-Wickede. Diese konkrete Stelle habe ich bereits korrigiert, aber da dürften noch ne Menge Fehler sein.
Genau. bicycle=no bitte nur bei “echtem Verbot” (Z254) mappen.
Mindestgeschwindigkeit ist ja interessant. Wenn ich als Radler die 30 schaffe darf ich dort also fahren oder wie… 
Für benutzungspflichtige Radwege hieße das passende Fahrbahngegenstück bicycle=use_sidepath.
Die Unterscheide sind durchaus relevant.
… und wer nicht über eine solche abbiegt, eben nicht = Wahlfreiheit der Form des Linksabbiegens im Unterschied zur älteren Formulierung, die schon bei Vorhandensein einer Führung diese verpflichtend machte …
Bei Fahrrädern wird meines Wissens von einer bauartbedingten Höchstgeschwindigkeit von 25 km/h ausgegangen. Aber eine eindeutige gesetzliche Regelung scheint es nicht zu geben. Sowieso ist die Gesetzeslage für Mindestgeschwindigkeit dünn.
Ich kapere mal diesen Thread, weil er einigermaßen zum Thema passt.
Hier im Nordwesten findet anscheinend ein kleiner Edit-War statt. Mittlerweile werden die Argumente schon als note=* an die Ways geheftet (z.B. https://www.openstreetmap.org/way/263195497/history bzw. https://www.openstreetmap.org/changeset/50613422)). So richtig zielführend ist das nicht…
Wer hat Lust zu vermitteln?
Und weiter geht der Edit-War.
Hmm. Ich verstehe schon die Intention, straßenbegleitende Radwege mit Straßennamen zu versehen, es macht alles aber auch sehr unübersichtlich. Von daher bekommen die Radwege von mir keine Straßennamen. Habe also nicht wirklich ne Idee, wie da ein Kompromiss aussehen sollte.
Ich verstehe ebenfalls, was das soll, nämlich dass der Router auch für Radfahrer Straßennamen ansagen kann, selbst wenn der Radweg straßenbegleitend verläuft. Aber ich kann mich für diese Lösung mit einem separaten name-Tag ebenfalls nicht erwärmen. Ich ziehe mal den Vergleich zu innerörtlichen Fußwegen, wo die als separater highway=footway bzw. highway=path neben der Straße gemappt sind: Dort wird auch der Straßenname nicht gedoppelt. Für die Ansage mag der Name schön sein, für die Übersicht auf der Karte ist es nicht zuträglich.
Als mögliche Kompromissidee: Ich frage mich, ob man die Relation:associatedStreet für solche Fälle aufbohren könnte, indem man dort neben den Rollen ‘street’ und ‘house’ noch eine weitere Rolle für straßenbegleitende Wege vorsieht. Damit wäre eine Zuordnung solcher Wege zum entsprechenden Straßennamen möglich, ohne dass er am Weg selbst stehen muss. Netter Nebeneffekt: Die “grandiose” Access-Angabe “use_sidepath” wäre damit deutlich besser handhabbar, weil klar ist, welcher straßenbegleitende Weg gemeint sein soll. Und sie wäre vor allem auch überprüfbar, inwieweit ein solcher Weg überhaupt gemappt ist.
Ich werf mal cycleway=sidepath in die Runde. Das könnte ein Renderer verwenden, um Radwege neben Straßen als solche zu erkennen und an diesen Wegen die Anzeige zu unterdrücken.
Davon halte ich nicht viel. Das sind wieder mal implizit eingeführte Logiken, bei denen ohnehin kaum noch jemand einen Überblick hat.
Vor allem ist der Standardfall dann genau das, was man vermeiden wollte: Ein Renderer, der den Umstand nicht kennt, dass er bei cycleway=sidepath den Namen wiederum nicht anzeigen soll, wird also standardmäßig den Namen zeigen. Ein Benutzer, der beim Taggen nicht darauf achtet, dass er bei straßenbegleitenden Radwegen cycleway=sidepath setzen muss, damit ein vorhandener Name nicht erscheint, wird ebenfalls dafür sorgen, dass der ungünstige Fall eintritt.
Ein zusätzliches Feature sollte im Regelfall zusätzlichen Tagging-Aufwand und zusätzlichen Auswerteaufwand machen. Es sollte nicht der Standardfall sein, der dann wiederum mit zusätzlichem Tagging- und Auswerteaufwand eingeschränkt werden muss. Denn das ist fehleranfällig auf beiden Seiten.
Hallo,
praktisch ist es so in Deutschland, dass an den allermeisten als separate Ways erfassten straßenparallelen Fuß-/Radwegen kein Name erfasst ist. Jetzt plötzlich einen Namen zu erfassen, ist ein aussichtsloses Verfangen.
Je mehr Objekte den Straßennamen tragen, desto fehleranfälliger sind Straßenumbenennungen.
Viele Grüße
Michael
Ist die Frage, ob Radfahrer das wollen? Ich persönlich schalte genau diese Funktion der Straßennamenansage aus, weil bis ich das Straßenschild entdecke, bin ich durch. Die visuelle Kontrolle ist verlässlicher, schneller und sicherer.