Und ich laufe mit dem GPS über eine große Area und zeichne diese “fiktiven” Laufwege ein. Wo ist der Unterschied? Fläche ist Fläche.
Entschuldigt mein abdriften, aber ich musste gerade an den Navionics ChartViewer denken. Ich hatte fälschlicherweise im Kopf, dass dort auch OSM-Daten verwendet werden, hatte mich aber offensichtlich getäuscht. Jedenfalls bekommen die bei einer Schiffsnavigation ein Routing über Flächen (Gewässer) hin. Im Beispielscreenshot mit “Umweg” wegen dem eingestellten Tiefgang von 10m. Haben die ein komplett anderes Datenkonstrukt, welches nicht auf Punkten und Linien aufbaut?
Ergänzung: Im Navionics Support Center ist zumindest ein Artikel über OSM, aber vielleicht beziehen die eher die POIs am Land von OSM, auch wenn ich OSM nicht in den Vereinbarungen finden kann.
Für Gewässer in OSM gibt’s nebenan in Should river lines be mapped through lakes, estuaries, gulfs, and other large water bodies? eine wunderbare Diskussion, ob man Flusslinien durch Gewässer-Flächen mit – Achtung – virtuellen Flusslinien verbinden sollte. Fast so wie Fußwege über Marktplätze 
.
5 Likes
da hab ich auch noch schönen Input zu (wurde von Descord hierher verwiesen):
ich hab gerade etwas Probleme mit dem Indoor-Tagging im Hamburger HBF:
Wir haben seit 13 Jahren einen eigenen OSM-Fußwegrouter für unseren ÖPNV-Router im Einsatz. Dieser kann schön über Plätze routen ( nicht nur die Außenkante benutzend, sondern den kürzesten Weg über die Fläche). Auch “Schwebende Punkte” wie Treppen die auf Flächen (wie Bahnsteige) hinauf- und herunterführen werden zukünftig berücksichtigt.
Im Hamburger HBF gibt es ein Ausgeprägtes Indoor-Routing. Auf auch Routebarkeit wurde hier meist Wert gelegt. Nur die Fahrstühle in der Wandelhalle sind seltsam. bsp: Node: 3504633106 | OpenStreetMap Das repeat_on wird hier mit level parallel benutz. Ist das normal? Welches soll der Router berücksichtigen? sollen die beiden Tags einfach zusammengefasst werden?
Generell halte ich das Tagging für Router sehr kompliziert.
Der Elevator ist als Raum getagt (Way: 733736682 | OpenStreetMap) dieser hat mehrere Levels. Die Tür “wiederholt” sich auf mehreren Ebenen. Der Router behandelt nun im Preprocessing den Raum als Fläche und versucht darauf zu routen.
Da der Raum nur einen Eingangsknoten hat der aber auf mehreren Ebenen wiederholt wird, muss dieser vorher aufgesplittet. Damit das Flächen-Routing damit umgehen kann, muss eine Routine gefunden werden, diesen Knoten aufzuteilen und die angrenzenden Wege den einzelnen Punkten zuzuordnen (in diesem Fall gibt es keine Wege in -1 , da er ein “Schwebende Punkt” auf dem Bahnsteig ist. Das wird auch noch lustig).
Das Debugging wird die Hölle.
3 Likes
leider findet man kaum noch Flächen ohne “Hilfswege”, um das zu teste.
Wer das testen will kann gerne auf der hvv - Fahrplanauskunft ausprobieren. (unter der Karte links ist ein Fußgänger-Symbol für den direkten Fußweg. Derzeit nur in und um Hamburg)
Bugs gerne an hvv - Kontakt (bitte mit link zur Suche, also das was in der URL steht)
2 Likes
Also wenn dann virtual:highway=pedestrian.
Da finde ich die OTG-Regel etwas überstrapaziert.
Die Straßenlinien in OSM sind Abstraktionen der Straßenfläche mit vielleicht noch einem width-Tag, der aber auch nicht überall so genau stimmt.
Bei komplizierten Umrissen nimmt man eben ein area:highway dazu, aber niemand ist da bisher auf die Idee gekommen, das z.B. in eine Routenrelation zu übernehmen oder die Straßenlinie zu löschen, weil man sie nicht sieht.
Bei pedestrian-Plätzen sehe ich da keinen prinzipiellen Unterschied, außer dass da oft zuerst die Fläche da war.
Weiter oben ist das Problem von Flüssen und Bächen durch Seen erwähnt. Da ist das noch viel extremer: Man sehe sich nur den Starnberger See an. Da sind die virtuellen Bachlinien zum (ebenfalls virtuellen) Zentralfluss fast immer länger als der Zufluss bis ans Ufer.
4 Likes
“wir” ist der HVV, nehme ich an, und er “eigene OSM-Fußwegrouter” ist nicht Open Source?