Sowas als “Beispiel” zu bringen, ist sinnlos, unnütz und für die Disskussion in meinen Augen auch gefährlich. Diese Routing-Abfrage ist genauso witzlos wie diese hier: https://www.openstreetmap.org/directions?engine=fossgis_osrm_foot&route=52.80184%2C12.70413%3B52.80152%2C12.70445#map=18/52.80146/12.70553&layers=N …Wahllos mal ein Ort herausgegriffen… 
Sven
Ist sidewalk:right=no eine akzeptable Antwort auf die Frage?
Ich hätte den separaten Gehweg auf den Teil verkürzt, wo der kein sidewalk ist, und dann vor Ort geschaut, ob der 30er wirklich erst so weit in der Straße drin beginnt wie erfasst, das schaut mir zweifelhaft aus. Und dann als nächstes vor Ort geschaut, wo da überall sidewalks sind.
Das ist wohl der Weg, den die meisten hier gehen würden? Oder ist da ein Zaun dazwischen? Für Leute mit besonderen Bedürfnissen würde ich annehmen, dass auf einer Seite der Straße bis zum nächsten Übergang geroutet wird, von dort dann wieder zurück. OSRM kann das nicht, gibt auch kein Profil dafür.
Ich auch und so ist es auch entstanden. Lange vor separate oder :left/:right. Die Aussage ist mit 3 (4) Werten abgedeckt: Beide Seiten/Links/Rechts/(kein)
Alles was danach entstanden ist sollte hier nichts verwässern und ich sehe sidewalk=left als Äquivalent zu sidewalk:left=yes + sidewalk:right=no.
Ein sidewalk:right=no macht wohl nur wirklich Sinn bei einem sidewalk:left=separate. Alles andere lässt sich kürzer anschreiben.
Ein Mehrwert besteht darin, dass es die Information gibt, dass es überhaupt einen Gehweg gibt.
Ein anderer ist, dass man bei einseitigen Gehwegen erkennt, dass die Straße gequert werden muss. Das ist für die Gehzeit wichtig. Man könnte sich auch einen Malus vorstellen: desto höherklassig die Straße und desto mehr Spuren sie hat, desto böser ist das Queren und desto eher gewinnen Alternative Routen.
Gegenüber dem Seperat-Tagging ist der Mehrwert, dass systematisch sichergestellt ist, dass es keine Umwege gibt, wenn (virtuelle) Verbindungen zur Straße fehlen.
Genauso aber gibt es Radfahrende wie mich, die solche Bordsteine garnicht stören. Die schließt das Getrennt-Mapping hier wieder aus.
Beim Zusammenmappen kann doch an die Knoten / Linien geschrieben werden, wo der Wechsel ohne Bordstein möglich ist. Dann hat man beides abgebildet. Einzges Problem ist die eindeutige Zuordnung von ‘left’ und ‘right’ an den Knoten.
OK, der eine Nachteil wurde durch einen anderen Nachteil beseitigt, darauf können wir uns einigen 
Das habe ich nicht behauptet. Ich behaupte, es gibt einen systematischen Fehler. Den kann man durch Workarounds in der praktischen Anwendung “Routing” mit viel Aufwand auf nahezu null reduzieren, er ist dadurch aber nicht weg.
Problem ist freilich, dass sich kaum jemand diesen Aufwand gönnt und der Fehler dadurch in der Praxis Auswirkungen hat.
Zudem zeichnet der Workaraund etwas in die Karte, was es in dieser Form draußen nicht gibt.
Wenn man gleichzeitig an die betreffenden Knoten ‘kerb=no’ schreibt, dann muss man nichts splitten. Die Knoten gibt es so oder so, egal ob Zusammen- oder Getrenntmapping.
Du beschreibst das als Schwarz oder Weiß, das ist es für mich aber nicht. Mir sind a) Dinge nur unterschiedlich stark wichtig und ich sehe b) für die mir weniger wichtigen Anwendungsfälle durchaus auch Lösungen beim Zusammenmapping.
Meine persönliche Prioritätenreihenfolge für die hier diskutierten Eigenschaften:
1-7 lässt sich mit dem Zusammenmapping lösen, nur das ‘left/right’ an den Knoten kann problematisch sein analog zu dem ‘forward/backward’ an Verkehrschildern oder Ampeln. Aber dort wird das ja auch in Kauf genommen.
Dort mappe ich getrennt. Hier in Leipzig scheint diese Kombination Standard zu sein. Ich könnte mir auch ein Zusammenmappen mit ‘crossing=no’ an der Straßenline vorstellen, zumindest wenn der Abschnitt kurz ist.
Wenn dir das zu konstruiert erscheint, nimm die Einmündung des “echten” Gehwegs im östlichen Teil: https://www.openstreetmap.org/directions?engine=fossgis_osrm_foot&route=53.10890%2C9.14735%3B53.10825%2C9.14949#map=18/53.10845/9.14869
Sowas sieht man regelmäßig, wenn wo separate Sidewalks hinzugefügt werden.
Du kannst die fehlenden Daten (Grundstückzufahrten, Bordsteinabsenkungen) nicht fürs falsche Routing verantwortlich machen. Einfach “ordentlich” detailliert mappen.
wenn man es explizit machen will: sidewalk:right=no
Ich sehe es generell kritisch, ein Routing auf solch kurzen Strecken für solche Disskussion heranzuziehen. Da kann man immer irgendwo Routen kreieren, die real so nicht funktionieren, egal nach welchem Schema man mappt.
Sven
Das Beispiel zeigt schon sehr deutlich die Fehler, die durch das falsche Gehweg-Mapping entstehen. Allerdings spricht es auch nicht für den Router, dass er mehrere hundert Meter Umweg in Kauf nimmt, nur um ein paar Meter näher an den Zielort zu routen.
Ich würde eher sagen “durch unvollständiges Mapping”. Wichtig für mich ist aber auch der zweite Satz:
Du kannst auch durch bestimmtes Positionieren des Start-/Zielmarkers fü die Route ein falsches Routing provozieren… Wenige Pixel nach der einen oder anderen Seite und schon kommt eine funktionierende Route raus, oder eben eine die Quatsch ist…
Sven
Offenbar ist es nicht so einfach, wenn es so häufig falsch gemacht wird. Einfach ist nur das Anlegen des Weges, ohne daran zu denken wie dieser dann interpretiert wird. Auch die Zufahrten werden öfter einmal auf private gesetzt, ohne dass dabei bedacht wird den kurzen Abschnitt zw. Fahrbahn und separaten Fußweg davon auszunehmen.
Naja, bei einem Fluss wirst du dir das ja bspw. erwarten, auch wenn das Ziel in Sichtweite wäre.
Der systematische Fehler beim Getrennt-Mapping ist, das der Mapper alle möglichen Querungen mappen muss.
Der systematische Fehler beim Key-Mapping ist, das der (eingeschränkte) Nutzer eine mögliche Querung finden muss.
Der Key-Mapper routet über die Fahrbahn-Kante und geht davon aus, dass am Ziel eine Querung zum Sidewalk vorhanden ist.
Die sidewalk-Tags werden ja nicht wirklich und korrekt in das Routing einbezogen.
Ein weiterer systematischer Fehler ist daher, dass er Nutzergruppen ausschließt.
Hier eine längere Route, gleiches Ziel, anderer Start, https://www.openstreetmap.org/directions?engine=fossgis_osrm_foot&route=53.11269%2C9.14329%3B53.10825%2C9.14949#map=17/53.11024/9.14584 - vom Kindergarten nach Hause: Der Gehweg wird überhaupt ignoriert. Das gilt für alle Häuser auf dieser Seite der Straße.
Und weil es manchmal heißt: Es müssten nur alle Garageneinfahrten erst erfasst werden, dann werden die Fußrouten kürzer. Das mag schon stimmen, aber das ist nicht das, was den Leuten hilft, die eben möglichst barrierefrei geroutet werden wollen.
Das Grundproblem seh ich in dem Versprechen, dass man mit getrennt erfassten Gehwegen den Autorouter (OSRM, Graphhopper) fürs Fußrouting verwenden kann und es sich erspart, einen Fußrouter zu machen.
Doch, es ist eigentlich einfach die Verbindungslinien vom Gehweg zur Straße (footway/path=crossing bzw. driveway bei Zufahrten) hinzuzufügen. Es ist nur aufwendig. Korrektes sidewalk-Tagging ist es aber auch. Weder bei dem einen noch beim anderen reicht es nur eine Linie oder nur ein sidewalk=* hinzuzufügen!
Ja, das stimmt.
Nein wird er nicht…! https://brouter.de/brouter-web/#map=18/53.10964/9.14621/standard&lonlats=9.149508,53.108375;9.143071,53.112755&profile=hiking-beta Du musst allerdings dem Routing-Programm Zeit geben, daß es die hier recht frisch erfassten Auffahrten fürs Routing erst mal lernt. Das kann 2-3 Tage, bis zu 1-2 Wochen oder länger dauern, je nach Router. Kennt es dann diese neuen Wege, springt die Route bei deiner Variante an der erst besten Stelle auf den Fußweg…
Sven
Interessant dass brouter im Wandern-Profil soweit wie möglich auf der Straße bleibt statt den footway zu nehmen.
Sven
Nein, das ist nicht das Problem. Schiebt man den Startpunkt z.B. etwas weiter zu einer Auffahrt, dann nimmt er auch den Fußweg (und verwendet dafür die Auffahrt oder ein footway=crossing). Aber erst wenn man auf der anderen Seite der Straßen-Linie ist. Die Alternativrouten verwenden den Fußweg auch früher (verlassen ihn dann aber auch wieder).