Sinnvolles Maß an Abstraktion bei der Modellierung von Gehwegen an Kreuzungen?

Da es bei mir in der Gegend mehrere Stellen gibt, wo Knotenpunkte, welche einen Fußgängerüberweg markieren, entweder nicht Teil des zugehörigen Fußwegs (Beispiel: Node: 6808017013 | OpenStreetMap) oder fälschlicherweise gleichzeitig Teil einer Straßeneinmündung sind (Beispiel: Node: 296962018 | OpenStreetMap), mache ich mir schon länger Gedanken darüber, wie man diese Probleme sinnvoll lösen könnte.

Mein bisheriger Lösungsansatz sieht folgendermaßen aus:

Kreuzung 2:

Orientiert habe ich mich an den auf Key:sidewalk bzw. Key:crossing gezeigten Beispielen, aber da ich in freier Wildbahn kaum Kreuzungen finden konnte, welche so einen hohen Detailgrad aufweisen, frage ich mich, ob ich mit obiger Umsetzung nicht doch ein wenig über das eigentliche Ziel hinausschieße und würde mich freuen zu hören, wie ihr das seht.

Aktuell wird der Zebrastreifen jedenfalls von den gängigen Routern noch verschmäht:

1 Like

Die Zebrastreifen nutzen macht den Weg länger… Die Router tun das, wofür sie erschaffen wurden, den kürzesten Weg finden. Die meisten Leute werden damit zurecht kommen. Es gibt das hier Routago Demosystem - das hat auch seine Macken, aber die Idee ist, dass nicht der kürzeste, sondern der sicherste Weg gesucht wird. Was spuckt der denn an den Stellen aus?

1 Like

Das sieht doch gut aus.
Leg los.

2 Likes

Dagegen spricht eigentlich nichts.
Wenn sidewalk an der Straße erfasst ist, dann reicht die Information über die Position der Querungsmöglichkeit vollkommen aus. Damit ist auch straßenseitengenaues Fußgängerrouting möglich.
Ich bin von der getrennten Erfassung von Fußwegen, falls diese nicht baulich getrennt sind, eher abgekommen.
Eine Auswahl möglicher Nachteile:

  • Obwohl die Straße an eigentlich fast jeder beliebigen Stelle überquert werden könnte, ist man evtl. in einem separat gemappten Fußweg “gefangen”.
  • Ein Navi kann, da der Straßenname nicht direkt dem Fußweg zugeordnet werden kann, nur “In 50 Metern rechts” ansagen, anstatt “In 50 Metern rechts in die Hauptstraße”.
  • Auch die Vermeidung von Gehwegen an Hauptverkehrsstraßen ist nicht mehr so direkt umsetzbar.

Die getrennte Erfassung hat für mich derzeit eher mehr Nachteile, also Vorteile.

1 Like

Das Problem* ist ja, dass an diesen drei Kreuzungen nach aktueller Datenlage durchgängige Gehwegrouten ohne Ampelknoten existieren, welche es so in der Realität eigentlich nicht gibt.

Das kannte ich noch gar nicht. Danke!

Der schlägt sich deutlich besser: routago.de - This website is for sale! - routago Resources and Information., routago.de - This website is for sale! - routago Resources and Information.

*) wobei sich in Anbetracht des Demosystems die Frage stellt, ob das wirklich ein Problem ist.

Wobei es in der Praxis offenbar vom Abstand der Fußgängerampel zur Kreuzung abhängt, ob es funktioniert oder nicht. An Kreuzung 3 scheitert das Demosystem aktuell: routago.de - This website is for sale! - routago Resources and Information.

Angenommen, ich würde die Gehwege in allen drei Fällen nur in unmittelbare Umgebung der Kreuzung getrennt erfassen. Wären dann nicht die Vorteile beider Welten optimal vereint? Also quasi so:

Meiner Ansicht nach macht das durchaus Sinn, an Kreuzungen mit 50 oder 100 m Durchmesser, wo fünf, sechs oder mehr Straßen aufeinandertreffen, also wo die Gehwege und die Fahrbahnen in einem Ausmaß voneinander abweichen, dass von dem Einen nicht mehr auf das Andere geschlossen werden kann. Vom Routing her allerdings, wer wird in so etwas hineinlaufen, nur weil ein Router das ansagt? Menschen mit speziellen Bedürfnissen?

Auf jeden Fall braucht es Gehwege dort, wo Richtungsfahrbahnen getrennt gemappt sind, um die beiden Übergänge untereinander zu verbinden.

Ich muss mich korrigieren. Das Demosystem scheitert vermutlich nur, weil auf dem Stück zwischen highway=traffic_signals und der eigentlich Kreuzung aktuell ein sidewalk:left=yes fehlt.

Es geht eher darum, dass man mit BRouter in einem Fall wie bei Kreuzung 2 keine Chance mehr hat zu erkennen, ob die Straßenüberquerung günstig oder ungünstig ist. Oder dass es beim Fußgängerrouting durch die grundsätzlich falsche Bewertung der Kosten bei längeren Routen dann zu erheblichen Abweichungen von der optimalen Route kommen kann.

@Quaternion Wenn du dich fürs detaillierte Mappen von Gehwegnetzen interessierst, kannst du mal einen Blick auf diese Empfehlungen zum Mappen von Gehwegen aus Berlin werfen. Da sind auch ein paar Kreuzungssituationen illustriert, allerdings eher einfache Fälle. Vielleicht hilft dir das dabei, ein Gefühl zu entwickeln, wie andere dabei vorgehen.

2 Likes

Vielleicht noch als Ergänzung: Bei reinen Fußgängerampeln müssen nicht unbedingt zwei Ampeln an die Haltelinien gesetzt werden wie bei deinem Beispiel.
Laut Wiki ist auch ein einfaches crossing=traffic_signals am Überweg ausreichend.
Wenn die genaue Haltepositionen ein highway=traffic_signals bekommen sollen, wäre dort auf jeden Fall noch traffic_signals=pedestrian_crossing sinnvoll. Es kann dann für Datennutzer leichter zwischen Fußgängerampeln und “normalen” Ampeln unterschieden werden.

1 Like

BRouter ist der einzige, der halbwegs vernünftige Zeiten für Wanderungen ausgibt. Auch graphhopper liegt oft daneben und OSRMF zielt ganz offenbar auf Welt-Elite-Läufer, zumindest hier in den Bergen. Von daher schätze ich den sehr.

Wenn es nun dein Ziel ist, dass BRouter in deinem städtischen Bereich tauglicher wird, dann führt wohl kein Weg darum herum, das Berliner Konzept anzuwenden. Also Fahrbahnen und begleitende Gehwege separat zu mappen, und zwar durchgehend, nicht nur an Kreuzungen.

Im Prinzip, zwei getrennte “Netze” für Auto- und Fußverkehr erstellen. Immer aufpassen dabei, dass der Router nicht irgendwo auf die Fahrbahn entwischen kann :wink:

Ich schreib das so bestimmt, weil Gehwegübergänge beachten, oder einbeziehen, auf welcher Seite der Straße man sich befindet, da gehört mehr dazu als nur Kosten für Schienen addieren.

1 Like

OsmAnd versucht die Marschzeit mit der (evtl. leicht veränderten) Naismith’s rule realistischer zu berechnen.

So was in der Art macht auch Graphhopper. Sogar besser als OsmAnd. Dessen Ergebnis ist näher an der Realität als OSMRF, zumindest wenn man Ele an hat, aber trotzdem ein Witz. Aber das lenkt ab vom Thema hier. Hier geht es um Fußrouting in städtischen Umgebungen und die Frage, ob BRouter dafür das Maß der Dinge ist?

Definitiv. Ganz herzlichen Dank für den Link!

Der Erklärtext im Wiki: “A traffic light that only turns red to let pedestrians cross” ist also so zu verstehen, dass alle Ampeln, welche ausschließlich auf Anforderung von Fußgängern auf Rot schalten - unabhängig davon, ob sie in der Grundstellung Grün oder Dunkel signalisieren - in diese Kategorie fallen?

Wobei die (Fahr)zeitberechnung bei BRouter komplett vom eigentlichen Routing entkoppelt ist.

Genau genommen ist das Ziel, den Kreis derer, die einen Nutzen aus den Daten ziehen können, zu maximieren.

Aber um noch mal auf das Demosystem von Routago zu sprechen zu kommen. Das System scheint hervorragend dazu geeignet zu sein, Fehler in der Gehweglogik aufzuspüren, scheitert aber teilweise - selbst in vergleichsweise einfachen Situationen - grandios.

Jedenfalls werde ich zunächst versuchen, erst mal nur die vorhandenen Logikfehler zu beseitigen und dann - abhängig davon, wie zufrieden ich mit dem Ergebnis bin - entsprechend der oben verlinkten, wirklich sehr gut gemachten “Empfehlung zum Mappen von Gehwegen” weitermachen.

Hallo,
ich setze zur Fußgängerampel eine Ampel mit traffic_signals:direction=both dazu.
Beispiel:

Gruß
Danfost

Das trifft ganz genau meine Beobachtungen, beides :slight_smile:

Hallo,
die Entwicklung der App ist jaut Webseite auch beendet.
https://www.routago.de/

Gruß
Danfost