Beim Fahrradfahren mit OsmAnd leitet mich OsmAnd manchmal falsch, weil es sagt, dass ich abbiegen soll und ich in eine Straße abbiege, obwohl ich nur auf den straßenbegleitenden Fahrradweg fahren soll, welcher als eigener Weg in OSM eingetragen wurde so dass es für OsmAnd „aussieht“, als wenn man dort abbiegen muss. Für Navis ist der Unterschied nicht zu erkennen. OsmAnd navigiert entsprechend so, wie die Daten in OSM sind. Und auf der Karte kann ich das nicht sehen, da das Mobiltelefon in einer Jacken- oder Hosentasche ist, ich höre dann nur die Sprachanweisungen über ein Bluetooth-Ohrstecker. Es würde auch viel mehr Strom verbrauchen, wenn die ganze Zeit das Display an ist. Zum Beispiel an diesen Stellen:
Das sind beispielhaft Stellen, an denen mich OsmAnd wegen extra eingzeichneten Wegen in die Irre geleitet hat. Im letzten Fall befand ich mich bereits auf dem Fahrradweg. OsmAnd glaubte mich aber wohl auf der Straße; GPS ist halt nicht so genau, dass man auf den Meter genau routen kann. Die maximale Präzision im Idealfall bei GPS beträgt drei Meter, in der Stadt weicht es aber oft ungefähr zehn Meter ab. Wenn man sich eine Route mit GPS aufzeichnet und über eine OSM-Karte legt, sieht man deutlich, wie ungenau es ist; die aufgezeichnete Route führt in Schlagenlinien mehrere Meter neben der Straße durch Häuser. Ich finde es daher nicht zielführend, jeden straßenbegleitenden Rad- oder Fußweg extra einzutragen, es führt nur zu Irritationen bei Navigieren. Bei Straßen ohne extra eingetragenen begleitenden Wegen hatte ich bis jetzt keine Probleme.
Es gibt auch andere Anwendungsfälle, die diese Daten benötigen. Wenn dich die straßenbegleitenden Wege beim Navigieren mit OsmAnd stören, wende dich an die dortigen Entwickler.
Oft sind sie unnötig, da hast du Recht, in vielen Fällen sind sie aber wirklich so stark baulich getrennt, dass es da analog zum dual carriage way schon Sinn macht, sie separat einzuzeichnen.
Das Problem mit den falschen Abbiegeansagen tritt aber nicht nur bei Radwegen auf. Das kommt auch bei Straßen generell bei etwas komplizierteren Kreuzungen oder Kurven vor. Abhilfe schafft da vermutlich nur das Einführen eines Typs Realation, der klar macht, welche Weg(teil)e zusammengehören und was ein Abbiegevorgang ist. Das wird vermutlich schnell komplex und unübersichtlich.
… sowie der Gebrauch von placement=transition an Way-Abschnitten, die nur der Anbindung dienen und keinen physischen Verlauf darstellen. Daraus könnten auch Router schließen, dass dort keine 45°-Abzweigung ist.
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.
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.
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.
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 …
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.
