Dein Beitrag kam als ich noch meinen Nachtrag geschrieben hatte, weshalb die Antwort über dir steht: Wie in Mainz schon geschehen kann man an die Line Buslinen und andere Relationen packen, was bei einer Fläche eher schwierg wird.
Ein anderes Beispiel ist die Hörn (die Sptze der Kieler Förde) die aktuell als landuse=common erfasst ist. Ich unterstelle einfach mal dass ich da außenrum geroutet werde, auch wenn man da lang gehen kann. (Wobei landuse=common eher eine Krücke ist wie man an deser vier Jahre alten Note sieht: Note: 2061677 | OpenStreetMap )
OSM ist nicht dazu da, um Software zu bedienen, wir wollen die Realität erfassen und die Software soll sich dann überlegen, was sie mit unseren Daten macht. Dass wir Straßen als Linien erfassen hat nicht den Grund, dass wir damit Routing-Engines das Leben vereinfachen wollen - das haben wir schon so gemacht, lang bevor es überhaupt Routing-Engines für OSM gab. Wir sind halt mit dem GPS eine Straße entlanggefahren und haben das später als Linine eingezeichnet. Luftbilder hatten wir damals ja noch gar nicht.
Natürlich müssen wir hie und da ein bisschen pragmatisch sein und einige unserer Regeln ein bisschen “verbiegen”, damit OSM brauchbar ist. So mappen wir ja zum Beispiel auch Admingrenzen und PLZ-Gebiete und verstoßen damit oft gegen unsere “on the ground”-Regel. Dennoch hielte ich das Hinzufügen von “Hilfslinien” für Router für einen Schritt zu weit. Wo soll das enden - wenn es irgendwo einen separate gemappten Bürgersteig gibt, von dem man jederzeit über die Straße auf den Bürgersteig auf der anderen Seite laufen kann, zeichnen wir dann alle 10 Meter eine Router-Hilfslinie quer über die Straße ein?
Und selbstverständlich ist ein Router mangelhaft, wenn er sich als Fußgänger-Router ausgibt und dann am Rand eines Platzes entlangroutet statt über den Platz drüber. Das Problem ist vielleicht nicht trivial (wie flohoff sagte, es könnten ja Hindernisse auf dem Platz stehen, die aber nicht “ausgestanzt” sind, dann muss der Router auch nach Bäumen und Parkbänken schauen, und nach Gebäuden sowieso…), aber ein Router, der das nicht kann, sollte einmalig in der Software repariert werden statt millionenmal im OSM-Datensatz.
Ich hab das bislang auch nur in Talks über Studienarbeiten und “experimentelle” Software gehört. Die vielversprechendste Methode ist wohl, so eine Fläche in eine Art “Pixel” aufzuteilen, dann die “Pixel”, auf denen ein Hindernis steht, zu eliminieren, und dann Routing-Kanten zwischen Mittelpunkten benachbarter Pixel zu generieren. Ich vermute, dass es in der Praxis noch nicht umgesetzt wurde, weil es für die meisten Zwecke doch eher von theoretischem Interesse ist. Wenn ich als Fußgänger den Platz erreiche, ist da eh gerade Markt und ich muss umdisponieren
Meiner Meinung nach sollten wir die Hilfslinien fürs Routing beibehalten solange es keinen Router auf osm.org gibt, der das kann.
Wir wollen doch, dass unsere Daten benutzt werden. Dafür müssen wir eben auch an die Nutzer denken. Solange es keine Standardrouter gibt, die über Flächen routen können, macht man es sich meiner Meinung nach zu einfach, wenn man sie dann „kaputt“ nennt und dass sie „repariert“ werden müssen.
Das ganze ist sowohl überhaupt nicht “neu”, wie auch nicht zum x-ten mal besprochen worden. Es war doch gerade vor ein paar Monaten eine Diskussion dazu.
Bitrot, bei einer Version 0.0.1 nach 6 Jahren auch nicht verwunderlich.
[INFO ] - Creating default configuration at plaza_preprocessing_config.yml
Traceback (most recent call last):
File "/tmp/plaza/bin/plaza_preprocessing", line 8, in <module>
sys.exit(plaza_preprocessing())
^^^^^^^^^^^^^^^^^^^^^
File "/tmp/plaza/lib/python3.11/site-packages/plaza_preprocessing/__main__.py", line 21, in plaza_preprocessing
config = configuration.load_config(config_file)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/tmp/plaza/lib/python3.11/site-packages/plaza_preprocessing/configuration.py", line 164, in load_config
config = ruamel.yaml.load(f, ruamel.yaml.RoundTripLoader)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/tmp/plaza/lib/python3.11/site-packages/ruamel/yaml/main.py", line 1085, in load
error_deprecation('load', 'load', arg=_error_dep_arg, comment=_error_dep_comment)
File "/tmp/plaza/lib/python3.11/site-packages/ruamel/yaml/main.py", line 1039, in error_deprecation
raise AttributeError(s, name=None)
AttributeError:
"load()" has been removed, use
yaml = YAML(typ='rt')
yaml.load(...)
and register any classes that you use, or check the tag attribute on the loaded data,
instead of file "/tmp/plaza/lib/python3.11/site-packages/plaza_preprocessing/configuration.py", line 164
config = ruamel.yaml.load(f, ruamel.yaml.RoundTripLoader)
Das problem ist wenn man sich die algorithmen ansieht das die ergebnisse eher so “meee” sind - Also ja - da kommen quasi im präprozessieren neue kanten für den Graph bei raus aber schön ist was anderes.
Ich bin eben so jemand der gerne einen Automaten machen lässt wenn man den dann auch mit expliziten daten overriden kann.
Und für mich wäre sowas eben eine linie über einen platz. Der Automat kann über die Aussenkante gehen - das ist je nach Fläche extrem ineffizient, oder ich kann dem mit expliziten informationen helfen in dem ich kanten einführe die die ein/ausgänge des Platzes miteinander verbinden.
Richtig ist das wir nichts vorgaukeln wollen wo nichts ist.
Ich wäre schmerzfrei wenn wir das als “highway=virtual” “virtual=pedestrian” eintragen würden oder so in der Form.
Nicht im Rendering - da gehörts nicht hin - Aber als hint für den Router.
Ich kann mich Deiner Argumentation nicht anschließen. Jede Straßenlinie auf einer mehrspurigen Straße ist eine fiktive Linie.
Ich sehe es so: ways sind für’s Routing und für die Kartendarstellung in niedrigen Zoomstufen, Flächen für’s Kartenbild in hohen Zoomstufen.
Ich habe z.B. diese Straße sowohl als area:highway eingetragen als auch als way.
Ich sehe da keinen Widerspruch sondern beides ergänzt sich (auch wenn area:highway bislang von den Renderern weitgehend ignoriert wird.
Bei diesem Markplatz habe ich vor Jahren versucht, das Routing durch sinnvolle ways zu ermöglichen. Ich habe dafür ganz normale highway=footway genutzt. Ich könnte mich aber durchaus damit anfreunden, sofern man sich auf ein entsprechendes Taggingschema geeinigt hat, daraus virtuelle Fußwege zu machen, so wie es flohoff vorschlägt.
Das Problem ist vielleicht nicht trivial (wie flohoff sagte, es könnten ja Hindernisse auf dem Platz stehen, die aber nicht “ausgestanzt” sind, dann muss der Router auch nach Bäumen und Parkbänken schauen, und nach Gebäuden sowieso…), aber ein Router, der das nicht kann, sollte einmalig in der Software repariert werden statt millionenmal im OSM-Datensatz.
es gibt ja auch Plätze die von Mauern, Zäunen oder Stützwänden begrenzt werden, da ist ein Routing über den Umriss mindestens ein bisschen komisch, und wenn dann noch ein verschlossenes Tor in so einem Zaun ist wird es vermutlich die meisten Router davon abhalten überhaupt auf dieser Kante zu routen.
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.
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).
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)
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.
