Fußgängerrouting auf der OSM

Inwiefern? In beiden Fällen heißt er: „Fußgänger dürfen hier langgehen“.

Merke: Der OSM-Way der Hauptstraße steht für das gesamte Verkehrsbauwerk inkl. aller Fahrspuren und Bürgersteige, nicht nur für die Mittellinie. Freilich gilt das foot=yes in dem Fall für die Bürgersteigbestandteile, die im Way ebenso enthalten sind wie die Fahrbahnen. Das vor Ort zu entscheiden trauen wir dem Fußgänger zu.

–ks

Vielen Dank für den guten Hinweis. Für Menschen mit unterschiedlichen Fähigkeiten liegen die praktischen Bedeutungen meilenweit auseinander, und darum muss ich mich kümmern. Dass es eine logische Darstellung gibt, in der die angegebene Informationen einen Sinn macht, sehe ich doch völlig ein. Wir brauchen über das Thema aber nicht diskutieren oder uns gegenseitig belehren. Was zählt, ist, wie es in der OSM genutzt und verstanden wird, und entsprechend wird die Interpretation ab dem nächsten Update korrigiert, damit in diesen Spezialfällen bessere Routen herauskommen.

In Reaktion auf die hilfreichen Hinweise von maxbe, discostu36 und kreuzschnabel habe ich die bisherige Bewertung von foot=yes zumindest in der topologischen Erweiterung und dem Routing auf Rad- und Pferdewege beschränkt. Dadurch wird im Beispiel von maxbe nun die erwartete Ampel benutzt.

Wie im Video auf der GPN18 beschrieben, ist der Erweiterungsprozess aber zweistufig: Deshalb ist die die Darstellung und Beschreibung noch bis zum nächsten Serverupdate leider in diesem Beispiel noch nicht ganz so gut, solange der eigentlich nicht benötigte und falsch interpretierte Tag foot=yes beibehalten wird.

Danke für eure Hilfe!

M.E. sollte aber ähnlich wie bicycle:lane=both/left/right auch sidewalk=both/left/right an so eine Straße, wenn ich schon mit foot=yes den default-Wert überschreibe.

Was ist , wenn nur einseitiger sidewalk vorhanden ist? Dann muss ich die Straße queren, was routingmäßig erschwerend wirken sollte. Ist dazu kerb=* als Erleichterung eingetragen?

Der Router benutzt im Moment track=cycleway. Zumindest in Deutschland ist der Standard für diese Wege foot=no (siehe Wiki-Link, den ich auf Seite 1 gepostet habe). Diese Wege sollten also nicht genutzt werden, wenn sie kein explizites foot=yes haben.

Mir sind gerade zwei Dinge aufgefallen, die auf jeden Fall schnell geändert werden sollten:

  1. Der Router weigerte sich an einigen stellen über highway=service zu routen. Er schick dafür sogar durch den Wald mit tracktype=grade5.
    An einer anderen stelle schickte er dagegen über einen highway=service, der zusätzlich mit maxspeed=30; surface=sand und tracktype=grade5 getaggt ist.

  2. Der Router scheint Barrieren(Im getesteten Fall: barrier=gate; access=no) noch nicht zu beachten.

Nach der bisherigen Diskussion hat foot=yes außer bei Radwegen oder Pferdepfaden (und Autobahnen) keine Information und ist dann immer redundant. Ich vermute, dass es aber häufig anders gemeint war, aber soweit es auch an Hauptstraßen verwendet wird, muss ich es explizit ignorieren.

Ja, wenn ein sidewalk nur auf einer Seite ist, so wird man erst eine Überquerung machen müssen. Das ist ja die Grundidee.

Die meisten kerb-Tags müssten übrigens für Nutzer mit Blindheit eher negativ gewertet werden: Diese helfen Rollstuhlfahrern, aber erschweren das Ertasten der Kanten mit dem Langstock. Dazu gibt es eine lange Diskussion zwischen den beiden Nutzergruppen über die Mindest- und Maximalhöhe. Es wäre daher tatsächlich relevant bei kerb die Höhe mit aufzuzeichnen.

Aktuell werte ich kerb nicht aus.

Tatsächlich gibt es überhaupt keine grundsätzlichen Verbote, sondern eine Abstufung in der Bewertung. Aber tatsächlich werden auch cycleways relativ präferiert genutzt, weil das meines Erachtens der praktischen Realität entspricht. Gibt es in der Nähe einen Fußweg, so sollte dieser vorgezogen werden. Das ist ein Maß der Abwägung.

Wenn der cycleway aber ein foot=yes hat, so ist er äquivalent mit einem footway.

Danke für das Testen! Dass highway=service irgendwo komplett vermieden wird, muss ich mir ansehen. Das sollte nicht so sein. Der grade5 ist definitiv ein Fehler, das hatten wir schon früher mal, aber vielleicht ist uns das wieder untergekommen. Kannst du einen Beispiel-Track als Bild oder Start und Ziel-Koordinaten posten?

Ja, bei den Barrieren sind wir noch nicht alle genau durchgegangen, welche in Ordnung sind und welche nicht. Kannst du mir den Fall wie oben als Testkandidat zur Verfügung stellen?

Ich weiß nicht so genau, was du damit meinst. In wie fern entspricht es der praktischen Realität, dass man auf ausgezeichneten Radwegen laufen sollte? Hier in Kiel begibt man sich damit zumindest in Lebensgefahr - und als Blinder wohl erst recht.

Geschieht hier anscheinend nicht (auf der anderen Straßenseite von Wilhelmplatz ist ein getaggter Fußweg, wird aber meist nicht verwendet).

Ich habe es mir angesehen, diese starke Trennung nach Seiten gibt es hier in Karlsruhe eher nicht. Ausgezeichnet, dass wir hier so unterschiedliche Orte testen! Ich habe die Penalty für den Radweg (ohne foot=yes…) so erhöht, dass es nicht mehr dazu kommen sollte. Wird spannend, ob dann in Karlsruhe einige erwartete Routen brechen…

Da fällt mir auf, dass der Überweg genau des Fußwegs über die Eckernförder Straße kein Crossing hat, dabei glaube ich da im 3D-Satellitenbild eine Fußgänger-Ampel zu sehen. Dadurch wird an der Kreuzung die Radfahrer-Seite benutzt, da es da zumindest laut OSM tactile_paving und Ampeln gibt. Das hatte den zusätzlichen Effekt das Routing auf die Radfahrseite zu ziehen, und dann den auch zuvor schon etwas schlechter bewerteten Radweg trotzdem zu nutzen, statt dann wieder zu queren. Sehr gut, dass sowas jetzt auffällt. :slight_smile:

Ich sollte wohl lieber mal anfangen, die Crossings in meiner Gegend zu prüfen, bevor ich mich über das Routing beschwere.

Ich hab das foot=yes vorgestern gelöscht, schaun wir mal nach dem nächsten Update.

Kann es sein, dass Ihr surface=gravel recht schlecht bewertet und das eher nichtssagende surface=unpaved recht gut? Ich vermute zwar, Ihr interessiert Euch eher für Städte als für Wanderwege in der Wildnis, aber auch im Stadtpark könnte der Kiesweg interessant sein…

Ich wollte den Weg am Kanal entlang (hw=path, bicycle=yes, smoothness=bad, surface=gravel) laufen. Alternativ hätte ich auch den etwas breiteren parallelen Weg (track, grade2, surface=gravel, smoothness=good) genommen. Ihr lasst mich einen halben Kilometer weiter laufen, nur um den Trampelpfad (footway, surfce=unpaved, width=0.5, bicycle=yes) zu nutzen. Das wird vermutlich keiner Zielgruppe gerecht, nicht mal den Trampelpfadliebhabern:

(Diese Gegend)

Fallsdieses Ergebnis wirklich an der Gewichtung von surface und smoothness liegt: Ich würde bei surface=gravel|unpaved… die smoothness genauer ansehen. “smoothness=good” halte ich für recht fußgängerfreundlich.

Grüße
Max

PS: Jo, Link auf 2 Koordinaten wäre echt gut, grad zum Testen :wink:

Wozu man wissen muss, dass surface=gravel häufig für wassergebundene Decken aus verdichtetem Mineralgemisch verwendet wird, was damit zusammenhängen dürfte, dass man das im Deutschen umgangssprachlich als „geschottert“ oder „Schotterweg“ bezeichnet. Einklich ist surface=gravel nur lose geschütteter Schotter (schwer zu gehen), während eine wassergebundene Decke (gut zu gehen) in OSM surface=compacted sein sollte.

–ks

+1 … war übrigens auch einer meiner Anfängerfehler, zu sehr auf die “Übersetzung” geachtet, als auf die eigentliche Definition … habe zwischendurch einige meiner surface=gravel durch surface=compacted ersetzt.

Hier Screenshots und die Koordinaten:

Routing um highway=service, hier mit service=parking_aisle:


https://www.openstreetmap.org/#map=17/52.58590/13.17672

Routing um highway=service:


https://www.openstreetmap.org/#map=18/52.57280/13.19845

Routing über highway=service mit surface=sand und tracktype=grade5. Außerdem etwas fehlplatzierte Linie.


https://www.openstreetmap.org/#map=18/52.56931/13.21074

Die Barriere ist hier:https://www.openstreetmap.org/#map=19/52.57544/13.19276 (Inzwischen in access=private geändert.)

… das, nebenbei bemerkt, falsch ist. Die Zufahrt zu einem bzw. Durchfahrt über einen Parkplatz bekommt kein parking_aisle, nur die kleinen Parkgässchen von da zur einzelnen Parkposition haben es. Im Wiki ist ein deutliches Bild dazu.

–ks

Wie kommen denn diese Zacken zustande, statt den Übergang zu verwenden?

Was anderes: Ich habe mir über Routing für Blinde noch nie Gedanken gemacht und bin auch nie mit Sehbehinderten unterwegs. Sind für die Kurven unangenehm? Ich habe nämlich den Eindruck, dass der Router gerne abbiegt statt ein paar Schritte mehr zu laufen. Diagonal über den Hofgarten kann ich entweder am Rand mit einer 90-Grad-Kurve gehen oder dem Router folgend quer durch mit 8x Abbiegen, 2 Viertelkreisen um die Brunnen und einem Halbkreis um den Pavillion in der Mitte. Der Weg durch die Mitte mag schöner sein, aber die Gefahr der Verwirrung ist auch hoch.

(ist schon klar, dass wir hier mühsam die wenigen fiesen Grenzfälle suchen und die eine falsche Strassenüberquerung anmeckern und die 1000 richtigen gar nicht erwähnen?)

Danke, aktuell läuft er aber noch auf der Straße, ich weiß aber nicht, ob die Änderung schon beim Provider durch ist, und ob unser täglicher Update womöglich hängt (hoffentlich nicht).

Das wird etwas komplizierter. Zunächst einmal sollte laut deutschem Wiki ein “nicht einmal Trampelpfad” eher kein “Footway” sein: Hier wird highway=path für “Mehrzweck-Pfade” (Rad-/Fußwege, Wanderwege, Trampelpfade) empfohlen. Der zentrale Weg ist als Track in der Bewertung als “Wirtschaftsweg” einer wenig befahrenen Straße gleichgesetzt- das überflüssige foot=yes ist hier sicher als gut gemeinter Hinweis gemeint, wird aber wegen der bisherigen Diskussion nun ignoriert. Dieser Fall lässt mich auch überdenken, ob man nicht doch den Tag entgegen der “Regeln” etwas vorteilhafter ansehen sollte. Der direkte “track” wird nicht besser als ein “path” bewertet, weil Trampelpfade nicht für die betrachtete Klientel in Frage kommen. Tatsächlich sind die Unterschiede aber nicht so groß, je nach Start- und Endpunkt ging bei mir der vorgeschlagene Pfade oft über den mittleren “path”.

Schwierig wird es in der Abwägung, welche Bodenqualitäten und Wegtypen man wie gegeneinander abwägt. Hier sind eigentlich alle Wege relativ schlecht für Menschen mit Blindheit, daher wundert mich etwas komischeres Verhalten nicht so sehr. Aber wenn man später sehende Personengruppen berücksichtigt, muss man das irgendwann angehen, und dabei auch berücksichtigen, dass nicht alle Mapper gleich die Wege eintragen, man also alles auch mit etwas Unschärfe betrachten muss.

Hey, im Screenshot wären die Koordinaten ja zu sehen, wenn du sie nicht löscht… :smiley:

Ich habe gerade wenig Netz, daher kommen meine Antworten aktuell nicht so schnell.