Ich hab’ mal surface=tartan ergänzt. 
Wobei hier immerhin Straße mit sidewalk=both und der Gehweg mit footway=sidewalk sinnvoll getaggt sind. Man könnte das jetzt so interpretieren, dass Straßen-way und footway-way an jeder beliebigen Stelle verbunden sind und ein Router könnte eigene virtuelle Verbindungen an jeder beliebigen Stelle zwischen den ways ergänzen und diese für das Routing nutzen.
Setzt voraus, dass man diese Annahme trifft (Verbindung zwischen Gehweg und Fahrbahn vorhanden). Aber das tun die Router bei sidewalk-Tags für gewöhnlich auch, obwohl diese Information gar nicht im sidewalk-Tag enthalten ist.
Sorry, aber das habe ich so noch nie beobachten können. Wenn die Zusteller geplante Routen fahren würden, dann wären die Fahrräder der Briefzusteller nicht auf dem Gehweg unterwegs. Ich hab da auch mal nachgefragt, ob die da irgendwelche Sonderrechte haben. Haben sie nicht, es interessiert einfach keinen. Und Briefe zu Fuß zustellen, ohne Fahrrad? Habe ich schon ewwig nicht mehr gesehen. Von daher halte ich Routing von Straßenseite A zu B immer noch für einen Spezialfall, den wir nicht mit künstlichen footway=link-Wegen zu lösen versuchen sollten.
Wie ich schon schrieb: Fie einzig wirklich 100% richtige Modellierung wäre das Erfassen von Fahrbahn, Geh- und Radwegen als area. Dort, wo sich eine Fußweg- und eine Fahrbahn-Area treffen und keine barrier=* dazwischen ist, kann man theoretisch kreuzen. Aber das wäre einfach Wahnsinn, das zu erfassen und bis dahin halte ich die beiden Kompromisse „Kreuzungsmöglichkeiten explizit erfassen“ oder „davon ausgehen, dass überall gekreuzt werden kann“ gepaart mit (dem unterstellten) gesunden Menschenverstand für gar nicht so schlecht.
3 Likes
Bei dem „davon ausgehen, dass überall gekreuzt werden kann“ müsste man dann aber festlegen, wer/was dort kreuzen kann. Meine Beobachtung ist, dass die meisten gesund und fit sind und das als Maßstab anlegen: “Ich kann hier lang, alles andere interessiert mich nicht!” Finde ich immer etwas schade.
Kam ja sogar schon bei Fahrradrouting diese Aussage: “Ich kann problemlos mit dem Rad über erhöhte Bordsteine fahren.” Tja, und das soll unsere Grundlage für das Mapping sein?
Das wäre für mich Sache des Routers, ob er nur an highway=crossing das Kreuzen anbieten möchte, oder überall. Eine ganz normale Einstellung, so wie eben auch „möchte ich mit dem Fahrrad über erhöhte Bordsteine geroutet werden“. Dass das kein Router so umsetzt ist ja ein ganz anderes Problem.
1 Like
Aber dafür müssen doch die Daten erstmal da sein und deren Bedeutung festgelegt sein.
Was bedeutet ein sidewalk=right/sidewalk:right=yes bezüglich Verbindung zwischen Fahrbahn und Gehweg? Kann ein Bordstein vorhanden sein? Welche Höhe darf er haben? Darf ein gemähter Grasstreifen dazwischen liegen oder eine Grünstreifen mit mehr Vegetation. Ein Wassergraben? Darf ein Leitplanke oder Absperrung dazwischen liegen? Usw. usf…
Aktuell kann sidewalk immer getaggt werden, sobald es ein Gehweg parallel zur Fahrbahn gibt. Was soll ein Router machen? Er weiß aktuell bei sidewalk einfach nicht, ob und wo man die Straße kreuzen kann.
Dafür müsste man festlegen: positives sidewalk-Tagging impliziert, dass ein Mensch ohne Einschränkungen jederzeit (oder mind. alle x Meter) zwischen Fahrbahn und Gehweg wechseln kann. Sollte das nicht der Fall sein, darf sidewalk:*=yes bzw. sidwalk=right/left/both nicht getaggt werden.
1 Like
Meiner Meinung nach müssen wir alle baulich vor Ort vorhanden Verbindung von Straße zu Gehsteig/Pfad usw einzeichnen, ob das nun Pfade, Zufahrten zu Grundstücken, Hofeinfahrten Feldern usw sind. Dazu entsprechend die Randsteine. Nur das hilft dem Blinden, Rollstuhlfahrer usw die Straße vernünftig und einigermaßen sicher zu queren.
Für alle anderen Personen kann man meines Erachtens erwarten die Augen zu benutzen um die Situation vor Ort und die Karte zu betrachten.
1 Like
Wie gesagt: weiß man nicht und deswegen wird angenommen, dass das Queren überall möglich ist. Wenn man das jetzt mit ein wenig gesundem Menschenverstand paart, sollte jemand, der nicht auf Querungsstellen angewiesen ist, innerhalb von ~50m schon eine geeignete Stelle finden. Alle anderen müssen auf highway=crossings warten. Ich finde das auch nicht optimal und tendiere eher zu getrennt mapen und
Aber da die eine Methode ungemein viel aufwendiger ist als die andere und deswegen viel seltener korrekt benutzt wurde, müssen wir das Beste aus den Daten machen, die wir derzeit haben. Und für mich heißt das: Router müssen zur Not nachfragen, wie gut jemand zu Fuß ist, was die Person sich zutrauen würde, usw. Es ist leider utopisch, zu glauben, dass die OSM-Daten innerhalb der nächsten 10 jahre perfektes Fußgängerrouting erlauben könnten, denn wie ja oft gesehen, erzeugen einige Mapper bei separatem Erfassen gerne Inseln 
1 Like
Mapper sind eben auch nur Menschen 
Hier würde allerdings vernünftige Software helfen die solche Fehler entdeckt.
Das die Router natürlich ebenfalls gefragt sind und verschiedene Profile anbieten ist für mich ebenfalls noch Zukunftsmusik, hier gibt es in OSM noch viel zu wenig Daten.
Mach einen Vorschlag, woher der Router wissen soll, dass sein Nutzer das erstens darf und zweitens physisch kann. Zwei Wege, die laut Koordinaten nur drei Meter auseinanderliegen, können real eine Mauer zwischen sich haben, einen Zaun, einen ungemappten Graben, oder fünf Meter Höhenunterschied.
2 Likes
Eben. Und das ist falsch. Daher verstehe ich nicht, wenn trotzdem immer wieder behauptet wird, dass sidewalk-Tagging angeblich besser sei als fehlerhaftes sidewalk-Mapping. sidewalk-Tagging wie es aktuell gemacht wird ist genauso zu kritisieren wie footways mit zu wenig gemappten Verbindungen.
Ein unverbunder footway und ein sidewalk:*=yes/sidewalk=right/left/both ist vom Fehler her aus Datensicht gleichbedeutend. Die Information über die Verbindung fehlt bei beiden Varianten. Beide Daten sagen das selbe: “Es gibt da ist einen Gehweg.” Bei der einen Variante wird einfach von einer durchgängingen Verbindung ausgeganen (obwohl der Tag so nicht definiert ist), bei der anderen von keiner Verbindung.
Beides ist falsch. Nur ist der zweite Fehler in der Karte auffälliger/offensichtlicher als der erste.
Mir ist das auch schon aufgefallen, ein gutes Beispiel ist für mich hier:
View Larger Map
Wo kann man hier zu Fuß gehen? Dass der Tunnel zwischen Ursulastraße und Turiner Straße mit foot=no getaggt ist, wird nicht gerendert, ebensowenig sidewalk=right u.Ä. Die Unterführung zwischen Eigelstein und Marzellenstraße kann man auch nur erahnen. Vom Fußgängerrouting gar nicht zu sprechen.
Ich hatte auch mal einen Thread im englischen Forum aufgemacht: Pedestrian-centric maps?
Eine allgemeine Karte hat da niemand gefunden, aber es gab ein paar interessante Lösungsansätze.
Die sieht gut aus, scheint aber leider nicht online nutzbar zu sein?
was auch immer Valhalla da falsch macht, die anderen routen korrekt.
Ich habe keine Fehler im Tagging gefunden :-/
Andere Router haben aber auch so ihren Tücken, z.B. wenn an der Hauptstraße sidewalk-Tags fehlen. Und weil Bürgersteige, die nicht separat gemappt sind, nicht gerendert werden, fällt das weniger auf. (Anders als z.B. cycleway Tags, wo ich in CyclOSM schnell sehe, wenn was fehlt.)
Scheint mir an dem service zu liegen. Sieht so aus, als würde Valhalla die als Einbahnstraßen ansehen:
Wenn man die Richtung umdreht, gehts.
Dazu passende Diskussion in Carto (dem standard Kartenstil) um das Rendering von Fußgängerüberwegen. Pedestrian crossings not visible · Issue #1943 · gravitystorm/openstreetmap-carto · GitHub
2 Likes
Nö, daran liegt es nicht. Wenn man etwas weiter im Service startet, dann geht es in beide Richtungen.
Es liegt offensichtlich nicht an einer Sperrung, sondern an der Gewichtung. Er bevorzugt scheinbar die foot=designated vor der “Parkplatznebenfahrgasse”, die eigentlich ein Zufahrtsweg ist. tagging angepasst und abwarten.