Ja, das ist ein altbekannter Nachteil des Separatmappings.
Ich nutze OsmAnd mit brouter und vermisse eine Ansage, wenn ich mit dem Rad von der Straße auf den (baulich getrennten) Radweg wechseln soll ! Das ist aber ein Problem von OsmAnd und muß dort gelöst werden.
Grüße aus Oberschwaben
Peter
Hilft aber auch nur in den ersten beiden Fällen, aber nicht bei der Querstraße Q …
Q
RRRRRRRRRRRRRRRRRRRRRRRRR
Q
SSSSSSSSSSSSSSSSSSSSSSSSS
E
… wenn man von der Einmündung E auf den Radweg R der Straße S will, da heißt es dann “rechts abbiegen in die Q” und stimmt dann ja auch, wenn direktemang folgt “linksabbiegen auf den R”
Ich sehe das auch als ein Problem an, dass durch die Navi-Software gelöst werden muss. Die OSM-Datenbank ist nicht speziell auf die Navigationsfunktion zugeschnitten. Und an sich macht es gerade im Umfeld von Kreuzungen Sinn, dass ich als Radfahrer über die teilweise komplett anders geführten Radwege durch den Kreuzungsbereich geführt werde und nicht einfach über die Autospur. Entsprechende Hinweise wie von Muek geschrieben muss dann halt die Software leisten.
Für mich ist dies ein Beispiel dafür, dass Navigeräte in der Praxis weiterhin ihre Berechtigung behalten werden: Fahrrad-Navi am Lenker (mit Kartenansicht) und Handy in der Tasche. Mulitfunktionalität hat halt auch seine Nachteile, wie eben das Akkuproblem, wenn man mit dem Smartphone navigiert.
Kann man leicht lösen, wenn man das Handy über einen Ladecontroler an den Dynamo anschließt oder eine entspr. Powerbank benutzt.
Das Problem sehe ich durchaus eher bei unseren Daten, oder allgemeiner beim fehlenden Bewusstsein für die Wichtigkeit von maschinenlesbaren semantischen Beziehungen.
Bei vielen Diskussionen in letzter Zeit (Getrenntmapping von Gehsteigen und Radwegen, Parkplatzflächen anstatt parking_lane etc.) merkt man sehr, dass separate Elemente von vielen intuitiv als “genauer” wahrgenommen werden. Aber das ist eben nur die halbe Wahrheit. Die Geometrie der Elemente ist genauer, aber die Zusammengehörigkeit zwischen den Elementen und andere semantische Information, die man beim Mappen über Tags an einem gemeinsamen Way immer hatte, geht verloren.
Nun ist es natürlich sehr motivierend, die eigene Arbeit in der Karte zu sehen, und dort wird man für die genauere Geometrie direkt mit sichtbaren Ergebnissen belohnt. Die Folgen der verlorenen Semantik sind dagegen zunächst einmal unsichtbar und wirken generell eher abstrakt. Da OSM aber eine für Maschinen verständliche Datenbank sein will, hoffe ich dennoch, dass sich längerfristig Lösungen durchsetzen, bei denen genaue Geometrie und klare Semantik Hand in Hand gehen. Das derzeitige Getrenntmapping, ohne eine Lösung zu haben, um weiterhin die semantischen Zusammenhänge ausdrücken zu können, finde ich voreilig.
Damit wird aber Eindruck erweckt, die Maschinenlesbarkeit sei wichtiger als ein menschenlesbares Kartenbild. Dem möchte ich widersprechen. Erstens werden ja auch immer mehr für das Auge gedachte Karten aus den OSM-Daten erstellt, zweitens ist die Maschinenlesbarkeit ja durchaus gegeben, nur die Umsetzung in sprachliche Navigationsanweisungen ist etwas schwierig.
Als Konsequenz deswegen nun auf das seperate mappen von neben einer Straße baulich getrennt herführende Fuß- oder Radwege zu verzichten, wäre meiner Meinung nach wenig zielführend.
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.
- für Fahrer spezieller Fahrräder nach VwV-StVO
- für das Einordnen zum Linksabbiegen
— wenn mal wieder vergessen wurde, den Radweg an die (Straßen-/Waldweg-)Einmündung auf der anderen Seite anzubinden
— generell seit einer der letzten StVO-Änderungen
… 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 Unbenutzbarkeit des Radweges etc.