Ja, für’s Routing ist es egal, trotzdem sollten Daten schon halbwegs korrekt sein, unabhängig von potentiellen Anwendungen.
Ich hab mir mal einen Fall angeschaut, da wurde ein Radweg gebaut und beim Einzeichnen nicht auf das schon bestehende sidewalk=no geachtet.
Auch interessant: Fuß-/Radrouting über Autobahn(-Links).
Laut Wiki gilt ja access=no / motor_vehicle=yes, sprich Sperrung für Fußgänger und Radfahrer. Aber wenn’s nen Bürgersteig gibt (sidewalk=*), dann kann man ja mal ein Auge zudrücken.
Testcase (hier kann man ausprobieren welcher der 3 Fußrouter hier den motorway_link nimmt):
Im Wiki wird mMn nicht deutlich gesagt, dass sidewalk- und cycleway-Attribute keine access-Tags sind.
Das würde ich dem Router jetzt aber nicht als schlecht anrechnen. Die OSM-Daten müssen interpretiert werden insbesondere weil die Doku nicht bis in jedes Detail geht. Und das ein Fuß- oder Radweg entlang einer Autobahn(auffahrt) zu dessen Rad- und Fußfreigabe führt halte ich für vernünftig - was soll sonst der Weg dort. Wenn ich den Seitenweg eintrage und der darf aber nicht genutzt werden, würde ich hingegen erwarten, dass ich ihn explizit sperre.
Ich würde auch den anderen Routern nicht vorwerfen, dass sie da nicht entlangrouten - weil es ist halt nicht dokumentiert das Seitenwege den Default-Access aufheben.
Ich würde sagen: Mappingfehler!
Wenn man den Fußweg schon separat mappt, sollte man diese auch westwärts als separaten Fußweg fortführen. Damit wäre das Routing-Problem datentechnisch gelöst und der Router müsste nicht mehr Rätsel raten.
Tagging-Fehler…
muß er ja auch… es gibt sonst keinen anderen Routing-Vektor…
Ich sehe hier einen Widerspruch zwischen den Tags an https://www.openstreetmap.org/way/380160649 und an https://www.openstreetmap.org/way/677537665 zum dritten hört Fußweg am motorway_link auf, obwohl er nach meinem schnellem Blick nach Esri-Luftbildern da in Richtung Westen weitergeht…
…so wird das erst recht nichts… 
Für mich sind sehr viele cycleway:=-Tag obsolet, wenn wie begleitenden Wege vernünftig erfasst werden würden… aber so wird das wohl noch 1365 Jahr dauern, bis wir zu Potte kommen…
Sven
Ich hab das mal anhand von Luftbild und Mapillary korrigiert.
Das war insgesamt großer Murks:
Der Radweg ist in Wirklichkeit ein Schleichradweg.
Der scheinbare Radweg direkt nördlich neben der Fahrbahn ist mehrfach mit Pollern blockiert.
Ja, schon schade, dass b=use_sidepath welches zur Verbesserung des Radroutings erfunden wurde manchmal das Gegenteil bewirkt bei falscher Anwendung.
(ist schon behoben)
Das bicycle=use_sidepath war schon richtig weil das ist da kein Fußweg sondern ein 240er
Nicht widersprüchlich aber veraltet ist das Tagging foot/bicycle=offical. Im Wiki offiziell als deprecated markiert.
Hier eine entsprechende Abfrage dazu. Essen ist voreingestellt da besonders betroffen.
Oh… ein Besenthema… ich nachher mal putzen…
Danke, Sven
Naja, das allgemeine access=official ist genauso falsch wie access=designated.
Besen wieder in die Ecke gestellt… Bei dem Thema trifft man noch auf viel mehr Unsinigkeiten: vehicle=yes bei highway=primary und so…
Sven
Ich habe heute folgende hübsche Kombi gesehen:
access=yes
bicycle=designated
foot=designated
motor_vehicle=no
War igendwo am Grünen Ring Leipzig 
Worauf sich das access bezieht, ist mir irgendwie nicht klar …
Wird wohl ein “Reiter und Kutschen frei” unter dem 240 hängen? 
Die wären auch bei einem 260 drin, aber da wären f+b nicht designiert …
Ich habe es aus dem Gedächtnis nicht ganz korrekt wiedergegeben. Richtig (und komplett) ist:
access=yes
agricultural=yes
bicycle=designated
foot=designated
highway=path
lit=no
motor_vehicle=agricultural
oneway=no
segregated=no
source=survey
surface=asphalt
ganz am westlichen Ende steht ein motor_vehicle=agricultural;forestry - wobei hier weit und breit kein forstwirtschaftlicher Verkehr erfolgen kann mangels Bäume.
Hi @Langlaeufer
haste Lust diesen Fall zu reparieren?
Auch hier ist use_sidepath gesetzt, obwohl nicht auf beiden Seiten ein Radweg vorhanden ist bzw. oneway am Radweg falsch gesetzt ist.
Interessant noch, dass OSRM oneway beim Radrouten anscheinend gar nicht beachtet.
Lau Mapillary war das das Problem, dort sieht man an der Querungshilfe das rüberweisende 237.
(Kleine Community-Auszeit gehabt.) Den Radfahrern noch ein paar Querungen erlaubt.
Da er das unten an der Weseler Straße nicht macht vermute ich hier einen Tagging-Fehler.
soweit ich das ergründet habe nutzt OSRM einfach die halbe Geschwindigkeit für entgegen der Radwegrichtung. Zudem ist die Gewichtung für Pfade immer noch total falsch und erheblich besser als alle anderen Wege. Desshalb nutzt er hier lieber den Pfad in Gegenrichtung als alle anderen Wege. Der Bug ist seit Monaten gemeldet.
siehe auch Debugmap:
https://map.project-osrm.org/debug/bike.html#17/51.93514/7.58164
Eigentlich sollte man das OSRM-Radrouting auf der OSM Seite ausschalten bis das gefixed ist.