Fußgängerrouting auf der OSM

Im Rahmen des vom BMBF geförderten Terrain-Projekts zur Unterstützung von Menschen mit Blindheit in Stadtgebieten, haben wir in einem Teilprojekt ein Fußgängerrouting auf Basis der OSM entwickelt. Aktuell geht es natürlich um die speziellen Bedürfnisse für Menschen mit Sehbehinderungen, in Zukunft könnten wir aber ganz unterschiedliche Personengruppen unterstützen.

Im Unterschied zu den aktuell öffentlich verfügbaren Lösungen (Apple, Google, OSRM, …) oder sehr ambitionierten und vorbildhaften Projekten wie AccessMap oder Namo verlangen und erfassen wir keine dedizierten Wege für Bürgersteige, um die Fußgänger sinnvollerweise auf den Straßenseiten zu routen und passende Kreuzungsmöglichkeiten vorzuschlagen. Gleichzeitig wollen wir alle möglichen Zusatz-Informationen nutzen, soweit sie flächendeckend vorhanden sind. Wir korrigieren oder ergänzen natürlich, wenn wir Probleme finden.

Ähnlich wie bei den Ansätzen von Schmitz/Ertl und später auch Nathanael Lang und Naumann/Kovalyov erzeugen wir intern ein erweitertes Netz. Jedoch wählen wir einen effizienten topologischen Ansatz, der uns ein transparentes Arbeiten auf Live-OSM-Daten ermöglicht.

Ich hatte unseren Ansatz im Mai 2018 auf der 18. Gulaschprogrammiernacht im Vortrag Nicht mitten auf der Straße! Oder was bringt uns die OSM für uns Fußgänger und Rollis? vorgestellt, und wir haben erste Ergebnisse auf der ICCHP18-Konferenz präsentiert. Das zugehörige Paper Robust and Incremental Pedestrian Path Network Generation on OpenStreetMap for Safe Route Finding ist leider Closed-Access, aber sobald wir vom BMBF den erforderlichen “Request for Self-Publication” erhalten, werden wir alle Pre-Prints mit Springer lizenzkonform auch auf der Seite des Projekts publizieren, und natürlich im Podcast und Blog noch mehr dazu erzählen.

Auf der Seite https://www.terrain-projekt.de/pedestrian-routing/ haben wir seit Mai ein Test-Interface für unseren Router online, das auf dem von der Geofabrik täglich zur Verfügung gestellten D-A-CH-Datensatz beruht.

Das Ganze ist ein früher Blick auf den Stand der Entwicklung, aber ich denke man sieht, dass der Ansatz im Live-Einsatz auf der OSM grundsätzlich sowohl in Bereichen mit robuster Datenlage bis hin zu den detailliertesten Gehweg-Mappings funktionieren kann. Die Bewertungen, wann welche Route bevorzugt wird, sind noch in einem sehr frühen Stadium und werden in Zukunft mit Mobilitätstrainern und betroffenen Personen abgeglichen. Genauso gibt es noch keine Auswahlmöglichkeit für unterschiedliche Profile. Auch ist das Routing bisher nur ein langsames A*-Verfahren und die Gehweg-Erzeugung kann hier und da noch zu verbessern sein. In Bereichen von hauptsächlich separat ausgeführten Gehwegen werden womöglich zusätzlich gepflegte Relations zur Zuordnung von Gehwegen zu ihren Straßen jetzt noch nicht ausgewertet, wodurch diese Gehwege in den Beschreibungen dann keinen Namen mehr haben.

Es stellt sich heraus, dass Straßen mit Sidewalk-Tags sehr große Vorteile haben, da sie ohne viel Aufwand eingesetzt werden können und daher uns das Bürgersteige-Netz robuster zur Verfügung stellen. In Fällen, wo der Bürgersteig aber entweder geometrisch von der gedachten Straßenseite abweicht oder es durch das Bündelproblem im Wegenetz zu geometrischen und topologischen Problemen kommt, erscheinen separate Footways eine Lösung. Wie hier im Forum auch häufig diskutiert, können separate Footways zu einer Vielzahl von Verbindungsproblemen führen, und das kann man dann im Routing auch schnell erkennen. Grundsätzlich sind alle zusätzlichen Informationen zur Ausstattung von Kreuzungen und Wegen natürlich immer sehr sinnvoll, aber nur wenn sie flächendeckend eingesetzt werden, können wir sie in einer so allgemeinen Lösung berücksichtigen.

Danke für eure tolle Arbeit hier, und ich hoffe wir können damit die großartige Abdeckung in der OSM für Fußgänger jetzt nutzbarer machen.

Danke erst einmal auch für das Vorstellen.

Ich habe es einmal für den “Sicheren Schulweg” in unserer Stadt (mit detaillierten Fußwegen) genutzt. Es gibt zwar ein paar “kleine” Fehler. Das Routing ist allerdings sehr genau mit den Angaben zu Übergängen. Auch deckt sich fast der persönliche Vorschlag mit dem Routing.

Günstig wäre das Erzeugen eines “Permalinks”. Da mit könnte man auch die “kleinen” Fehler im Routing klären. Und eventuell auch helfen, Problemchen zu klären. So wird “auf” einer Straße linksseitig geroutet, obwohl rechts ein footway vorhanden ist mit der dortigen Querung ca 10 m längeren Weg benötigt.

Es sollte jeder einmal in seiner näheren Umgebung mit Sicht auf “sicheres Routing” testen.

Danke geri-oc für den ersten Eindruck. Ja, Permalinks sind auch bei mir ganz oben auf der Wunschliste, dabei hatte ich zuerst an die aktuelle Position der Karte gedacht (aktuell starten wir immer in Karlsruhe), aber natürlich wäre es sehr gut, wenn wir auch fertige Routen so verfügbar machen können- das hatten wir bisher immer mit Screenshots gemacht. Ich werde das mit den Kollegen diskutieren. Diese Dinge werden wir aber frühestens im September nach der Urlaubszeit angehen können.

Für Schulwege brauchen wir natürlich ein etwas anderes Bewertungsprofil gegenüber der Anwendung für Menschen mit Blindheit: Da zählen weniger die Ausstattung von Ampeln mit Vibration und taktilen Bodenbelägen, dafür sind Nebenstraßen und Zebrastreifen vorzuziehen. Sobald wir verschiedene Profile anbieten können, ist Routing für Kinder auf jeden Fall auch eine wichtige Rubrik.

Intern werden Straßenseiten nicht wie bei Nathanael Lang gelöscht, aber sehr negativ bewertet, wenn explizit ein sidewalk dort ausgeschlossen oder als “separate” angegeben ist. Hat die Straße keine Angabe, so werden explizite Wege leicht präferiert; dann hängt es von den lokalen Gegebenheiten ab. Muss man schauen, was bei dir der spezielle Fall war, auf jeden Fall haben wir viel Optimierungspotential; in den Bewertungen und in den Daten. Der Schwerpunkt liegt aber klar auf der generellen Route, die exakte Lokalisierung der Wege können wir nur im Rahmen von Heuristik und der Daten abschätzen.

Bei mir zu Hause klappt es auch nicht mit dem idealen Schulweg, aber da fehlt aber schlicht noch ein Zebrastreifen mit Verkehrsinsel, den ich nur mal eintragen müsste.

Ich finde es aber auch für Kinder durchaus angebracht, das nur an sicheren Stellen gewechselt wird. So unterschiedlich ist das Profil nicht. Auch als Rollator-Benutzer ist passt dies schon besser mit den Angaben.

ist aber in OSM sehr dünn. Am meisten bei Haltestellen genutzt; bei uns sind fast keine Kreuzungen damit ausgestattet.

Da stimme ich voll zu, natürlich geht es bei Kindern und bei bewegungseingeschränkten Menschen ebenso um die sicheren Wege und Kreuzungen! Die Unterschiede sind nicht groß, aber wir können sie sehr detailliert abbilden und wollen das in Zukunft durch unterschiedliche Profile auch tun.

Hier geht es mir auch um das Henne-Ei-Problem: Ohne ein Routing mit Straßenseiten machte es kaum einen Unterschied, ob erweiterte Informationen zu Kreuzungspunkten vorhanden waren oder nicht. Jetzt können wir zeigen, dass wir damit etwas anfangen. Wenn die OSM-Daten fehlen, gibt es halt einen Fallback auf sinnvolle Annahmen.

Hi,

fein, dass sich bei dem Thema was tut und sogar getestet werden kann.

Ich habs mal in meiner kleinen Testumgebung hier ausprobiert, wo sidewalk=* häufiger vorkommt. Erwartet hätte ich sowas wie die blaue Linie im Bild, bekommen habe ich die rote:

Der Umweg über die Ampel ist Geschmacksache. Es scheint aber auch so, als ob die beiden Gehwege der Ismaninger Str. nicht so richtig berücksichtigt werden oder der Router den Einstieg auf die Bürgersteige nicht findet. Die Routing-Anweisung verwirrt auch eher mit ihren 4 Querungen der Ismaninger Straße:

Irgendwie werden die Gehwege schon erkannt, aber zu viele (oder so…) und angezeigt wird die Strassenmitte.

Grüße
Max, der sich über jeden freut, der erst mit dem Vorhandenen rechnet und dann überlegt, wie man mappt :wink:

Irgendwie war mir alles zuvor so theoretisch und lokal, und damit wollte ich mich für das Projekt nicht abfinden. Ich bin echt froh, dass die Idee dann am Ende auch geklappt hat. Deswegen ist mir die Live-Demo auch so wichtig.

Das ist ein tolles Beispiel: Kannst du mir erklären, wie die Ismanginger Straße B471 als Hauptstraße ein foot=yes bekommt, und was soll das hier heißen? Bisher haben wir foot=yes wie foot=designated, also als Fußgängerzone, behandelt und laufen daher zentral. Und das bringt den Router hier völlig aus der Rolle, da natürlich so eine Bundesstraße klassisch überquert gehört. :roll_eyes:

Ähnliches haben wir in Karlsruhe in Tempo30-Anwohnerstraßen gesehen, wo man aber eher die explizit ausgeführten Sidewalks als die Straße nutzen sollte.

Die Routenbeschreibung hat noch so ein paar Macken, da sind Beispiele wichtig, dass man das ausbügeln kann. Hier liegt es aber sicher am foot-Tag, der offensichtlich falsch interpretiert wird, oder da nicht hingehört.

Gerne, aber idealerweise fangen wir gar nicht groß global mit künstlichem Mappen an, sondern nutzen das optimal, was da ist. Und arbeiten wie alle nur lokal, wo wir uns selbst auskennen. Bisher kriegt die OSM-Community das mit dem guten Erfassen der Situation ja schon verdammt gut hin.

foot=yes heißt schlicht, dass Fußgänger auf der Straße erlaubt sind. Ist aber bei highway=primary eh der default.

Nicht von mir :wink:

Aber ich finde es hier auch nicht verkehrt. Die Straße ist ohne separate Rad- und Fußwege gemappt, die Tags beziehen sich also auf die gesamte Straße mit 2 Autofahrstreifen, 2 Radstreifchen und 2 Gehwegen. Da ist foot=yes auch angebracht, man darf und soll ja einen der Gehwege benutzen. Bis vor 2 Jahren stand da “foot=use_sidepath”, was ich für unglücklich halte, wenn besagter use_sidepath nicht in OSM steht (und ich denke, er stand damals auch nicht drin).

Ja, diese Warnung fehlt leider in der deutschen Version.

Nun, sie ist secondary.

Und richtig “erlaubt” habe ich mich (de-facto) bisher mitten auf solchen Straßen nicht gefühlt- daher wundert mich diese Interpretation. Es geht aber natürlich nicht um meinen Eindruck, sondern es soll natürlich das Verständnis der Mapper umgesetzt werden.

  1. Bist du sicher, dass die deutliche Mehrheit der Mapper foot=yes so versteht?
  2. Wie sollte man dann foot=designated interpretieren, und wie erklärt sich das Verhältnis zum Wert yes?
  3. Wenn es eher um die theoretische Erlaubnis geht, wo sollte man es überhaupt aufführen?

Bisher kamen wir mit foot=yes als tatsächlich und ungefährlich für Fußgänger frei verfügbare Fläche gut zurecht, aber es gab auch fragliche Stellen. Die Frage ist am Ende, was für eine Auswirkung hat diese Angabe für Fußgänger, an die sich die Angabe offensichtlich richtet, sofern sie angegeben wird gegenüber wenn sie fehlt.

Bei zwei angegebenen Gehwegen braucht es noch ein foot=yes der Straße? Also wenn ich das falsch interpretiert habe (mit Unterstützung eines langjährigen Mappers), so fühle ich mich zumindest nicht ganz so schuldig. :slight_smile:

Foot=yes sollte vom Router ignoriert werden, wenn er nicht auf highways steht, die implizit ein foot=no haben (siehe https://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions )

Es braucht es nicht, ich halte es für unnötig und verwirrend, aber wenn man unbedingt ausdrücken will, dass man da laufen darf, ist es ok.

Wenn ich mir die highway=primary/secondary/…/residential mit foot=yes in meiner Gegend so ansehe, kann man daraus keine Attraktivität für Fußgänger ableiten. Was die Leute dazu motiviert, weiss icgh nicht, ich vermute einen Drang, Formulare vollständig auszufüllen :wink:

Bei foot=designated siehts anders aus. Das sind Wege (allerdings selten Straße, oft path oder footway), wo jemand sagt (oder die Behörde widmet), das sei ein Fußweg und vielleicht sogar ein blaues Schild hinstellt. Die würde ich auch als für Fußgänger attraktiv berücksichtigen.

Eher würde ich noch die anderen access-Werte heranziehen. Ein innerstädtischer Weg mit (motor_)vehicle=no wäre zum Beispiel ein schöner Fußweg.

Ah, sehr schade, jetzt wird es klar. Aber warum… :roll_eyes: Sei’s drum. Vielen Dank auf jeden Fall für den Hinweis auf die de-jure Interpretation auf der Wiki-Seite zu Access-Restrictions, das werde ich im nächsten Update (…nach der Urlaubszeit…) korrigieren.

Bis dahin kann der Router bei solchen Fällen von foot=yes falsche Ergebnisse liefern. Im Fall von maxbe (und sicher vielen anderen) könnte der redundante Eintrag natürlich gelöscht werden, weil es ohnehin default ist. Dann wäre morgen das Routing dort in Ordnung.

Danke an Alle für den Hilfe!

Ja, da gibt es auch sicher regionale Unterschiede, wie Tags genutzt werden, daher ist es auch so wichtig, das System auch mit Ortswissen an anderen Stellen zu testen. Ich werde das auf jeden Fall im nächsten Update korrigieren. Danke, dass dir das so schnell aufgefallen ist.

Wir versuchen so viel zu nutzen, wie geht. Aber ich glaube vehicle=no war noch nicht auf meiner Liste, toller Vorschlag! Aber leider kommt er nicht sooo oft vor. Update: Bei motor_vehicle=no sieht es besser aus, großartig!

Seltsamer Umweg in Kiel:

Woran liegt das?

Ich sehe gerade, dass die “richtige” Fußgängerampel gar nicht als “crossing” eingetragen ist, damit könnte es wohl zu tun haben.

Hier der Kartenausschnitt. Die gewählte Überquerung ist (eingetragen&) für Blinde besser ausgestattet (tactile_paving=yes), und die Anzahl der unkontrollierten Übergänge bleibt gleich. Ein Umweg ist da vertretbar.

Es liegt also an dem aktuellen Fokus auf Personen mit Blindheit. Mit einem anderen Profil käme sicher die nähere Überquerung heraus.

OK, danke für die Info. Laut Wiki wohl eine falsche Verwendung für das Tactile-Paving-Tag? Die Rillen begleiten hier ja nicht den ganzen Überweg. Müsste man das nicht an die Bordsteinkanten mappen, wie hier?