Routing in Fußgängerzone

Hallo,
zu dem Thema habe ich mehrere Themen gefunden, die keine befriedigende Lösung bieten. OSRM und GraphHopper routen entlang der Ränder von Fußgängerzonen, was hier https://www.openstreetmap.org/directions?engine=fossgis_osrm_foot&route=49.79913%2C9.93436%3B49.80139%2C9.93565#map=17/49.80039/9.93596 einen besonderen Unsinn erzeugt, wenn man den Startpunkt nicht in die Mitte der Straße legt.

Mir geht es aber hauptsächlich um den Bahnhofsplatz. Hier würden also auch Sehbehinderte entlang der Ränder geführt, obwohl es auf dem Platz Spuren für sie gibt. Sollten auf dem Platz, obwohl es ja eine area ist, zusätzlich Wege entlang der Pflasterung für Sehbehinderte gemappt werden?

Praktisch wäre, wenn es in OSM auf der Karte unsichtbare Wege gäbe, die nur fürs Routing auf diesen Flächen verwendet werden. Gibt es etwas Vergleichbares oder eine laufende Diskussion darüber?

Gab da mal ein Proposal dazu:
https://wiki.openstreetmap.org/wiki/Proposed_features/virtual_highway

In Verwendung ist der Tag aber wenig laut Taginfo. Ob es einen Router gibt der sowas verwendet? Keine Ahnung.

Das Thema ist uralt (siehe https://forum.openstreetmap.org/viewtopic.php?id=7959 und umfangreicher hier: https://forum.openstreetmap.org/viewtopic.php?id=23129 ). Es gab sogar schon einmal eine Lösung des Problems am Ende des zweitgenannten Threats ( https://forum.openstreetmap.org/viewtopic.php?pid=385276#p385276 )…

Praktisch findet man immer noch sehr häufig wichtige Wegebeziehungen zusätzlich über den Areas - insbesondere, wenn es für “Routen” genutzt werden soll. Einfach, weil’s funktioniert :stuck_out_tongue:

Ich habe nach “vesteckt” und “hidden” gesucht, auf “virtual” bin ich nicht gekommen. Das ist ja genau, was ich gesucht habe. Was passiert denn mit einem solchen Proposal? Gibt es einen “Dienstweg”, wie so etwas weiterentwickelt und angenommen oder abgelehnt wird?

Puh, das wird’s ja richtig kompliziert.

Ich glaube, ich muss mich erst mal damit begnügen, auch wenn’s auf Karten nicht schön aussieht.

Eine
area=yes +
highway=pedestrian
kann nicht immer alle linear sinnvollen Wegebeziehungen ersetzen.
Das dürfte den meisten auch klar sein, völlig ungeklärt, ist allerdings wie diese Wegebeziehungen konkret ausgeformt sein sollten,
meine OSM-Forschungen zur OSM-Praxis in D aus 2020-01:
https://wiki.openstreetmap.org/wiki/User:Jo_Cassel/Fu%C3%9Fg%C3%A4ngerfl%C3%A4chen_und_Wegelinien
in Forum angesprochen:
https://forum.openstreetmap.org/viewtopic.php?id=68493

Allerdings wird auch ein gut abgebildetes linieares Wegenetz einen schlecht programmierten Router nicht davon abhalten, stattdessen “an Rändern langzulaufen”.

Danke für die Links.
Deshalb nochmal meine Frage, ob es eine Möglichkeit gibt, den Vorschlag mit den “virtuellen Wegen” voranzubringen.

Wie soll ein Router von hier https://www.openstreetmap.org/way/508227859 nach hier https://www.openstreetmap.org/way/198934304 kommen?
https://www.openstreetmap.org/directions?engine=fossgis_osrm_foot&route=49.80088%2C9.93525%3B49.80094%2C9.93491

Dazwischen einfach einen Weg (path, footway?) mit https://wiki.openstreetmap.org/wiki/DE:Key:informal oder highway=pedestrian → https://www.openstreetmap.org/#map=19/51.05929/13.74317&layers=ND

Klar, du kannst den Ersteller fragen ob du es übernehmen darfst oder einfach selber ein neues anlegen (und evtl. den Inhalt rüberkopieren). Dann RFC und Abstimmung wie hier beschrieben: https://wiki.openstreetmap.org/wiki/Proposal_process

Natürlich ist die Frage, ob die Routing-Entwickler das dann auch wirklich einbauen, wenn es akzeptiert ist – Innovationsstau auf deren Seite ist ja die Wurzel des Problems. (Es ist nämlich durchaus kein unlösbares Problem, virtuelle highways über eine Fläche automatisch zu generieren.) Aber das wäre dann so einfach und mundgerecht zurechtgelegt dass sie es hoffentlich einbauen würden.

(Falls du das angehst, würde ich übrigens virtual:highway= bevorzugen. Aber das nur am Rande.)

Offen gesagt halte ich nicht viel davon das Mapping hier virtual zu verkomplizieren aus dem Proposal:
“Rationale […] Creating a separate highway tag instead of using existing ones has the advantage that it can be rendered or routed independently.”
Das Routing geht auch (bzw. nur) mit normalen highways, und was das Rendering betrifft, habe ich ein Gebiet mit kilometerlangen linearen highway=footway auf 2D-Fußgängerflächen - wobei die highways mehrere Wanderwegsrelationen repräsentieren.
Da ich diese highways (und nur diese) auf gerenderten Plänen nicht sehen will, rendere ich die Fußgängerflächen über highways - und weg sind sie, irgendwelche “vitual” bzw. “dont-render-me”-Tags sind dafür nicht notwendig.

Das verstehe ich nicht. Erklärst du mir bitte genauer, was du damit meinst?

https://www.openstreetmap.org/way/236254492 über (unter)
https://www.openstreetmap.org/relation/3176704#map=17/51.05995/13.74318&layers=N
so
https://www.openstreetmap.org/directions?engine=fossgis_osrm_foot&route=51.05981%2C13.74261%3B51.05969%2C13.74322#map=19/51.05977/13.74291&layers=N

Das würde ich verstehen, wenn ich bei dem Weg oder der Area einen Tag für drüber oder drunter finden würde. Wie ist das hier bewerkstelligt?

ohne drunter und drüber: Fläche erfassen, Weg erfassen, beachten das die Wege Anschluss an andere Wege und diese Fläche haben.

Das Übermalen von Linien und Flächen ist eine unzuverlässige Krücke, wie sich ja vor etlicher Zeit beim Übermalen von inneren Flächen über die äußeren Flächen gezeigt hat (z.B. See im Wald). Da wollte man sich dadurch MPs ersparen, was letztlich nicht funktioniert hat.

Hier geht es wohl darum, die Hilfswege verschwinden zu lassen, ohne die Routing vor allem bei komplizierteren Flächen nur schwachsinnige Ergebnisse liefert.

Wege (Grenzen, Straßen, (Gebäude), …) gehen immer über Flächen. Flächen in Flächen sollten durch MP gelöst werden.Hier sollte aber auch auf die Größe des outer geachtet werden, die durch Detaillierung entsteht und es sollte eine (möglichst sinnvolle, an Straßen- oder Flußverlauf) Teilung erfolgen.

Du schreibst in #5
“Ich glaube, ich muss mich erst mal damit begnügen, auch wenn’s auf Karten nicht schön aussieht.”
und ich vermute Du meinst hier die Darstellungskombination:
sichtbare highway=footway auf Fußgängerflächen der Standardkarte auf OSM.org

Dies ist aber kein Naturgesetz, ein Renderer kann - wenn denn vom Anwender gewünscht(!) - hier highway=footway unterdrücken OHNE dass auf Mapper- bzw. Erfassungsseite irgendwelche verkomplizierenden neuen highway-Tags notwendig sind. Dies geschieht indem highway=footway beim Rendering durch die Fußgängerflächen überdeckt wird (so wie auf der Standarkarte gegenwärtig Gebäude durch Fußgängerflächen überdeckt werden).

Ich vermute dass die Kombination unsichbare highway=pedestrian auf Fußgängerflächen, die sich häufig in D-Innenstädten findet, dem Wunsch geschuldet ist, diese auf der Standardkarte zu unterdrücken.

@seichter: Dass hier das “See vers. Insel”-Dilemma auftaucht kann ich nicht erkennen.

Ich glaube eher, dass das Problem darin liegt, dass “Fußwege” über “Fußgängerzonen” gelegt werden. Das ist dann sichtbar. In Wirklichkeit müsste aber (zumindest in den meisten Fällen) der “Fußweg” auch als Fußgängerzone erfasst werden.

Mal ein praktisches Beispiel, warum man in Einzelfällen nicht um einen way auf einer area herumkommt:

Auf dem Hauptmarkt ( https://www.openstreetmap.org/way/136698909 ) ist Radfahren verboten. Seit etwa vier Jahren darf man aber auf genau einer Route dort fahren: https://www.openstreetmap.org/way/23113737 Das kann man über die Fläche einfach nicht abbilden.
Ähnliches gilt für https://www.openstreetmap.org/way/160983142

Ansonsten gibt es ja auch den erwähnten Ansatz zuerst die (high-)ways und darauf die highway-areas zu rendern .

Vielen Dank für eure ausführlichen Antworten. Ich werde es probieren.

Es sind genau dann keine neuen Tags notwendig, wenn sich die OSM-Community darauf einigen kann, dass highway-Linien, die über eine highway-Fläche auf demselben Layer führen, immer virtuelle Hilfslinien sind. Ist das so? Dann sollten wir das international festlegen und dokumentieren.

Falls wir aber manchmal virtuelle Hilfslinien fürs Routing und manchmal andere Sachverhalte abbilden wollen, bräuchten wir doch irgendeine Art der Unterscheidung dieser Bedeutungen, z.B. eben ein Anhängsel am Schlüssel.