Dafür ist eigentlich area:highway erfunden worden. 
Ein paar Connections hab ich schon eingezeichnet.
Ja, das ist ein bekanntes Manko aller bisherigen Routing-Loesungen. Die brauchen Linien um einen routingfaehigen Graphen erstellen zu koennen, und muessten dafuer bei Highway-Flaechen die Kominationen aller moeglichen Verbindungen zwischen mit der Flaeche verbundenen Wegen als Unterbaum aufbauen.
Den Aufwand macht sich aber soweit ich weiss bisher kein Router. Betrifft ja vor allen auch “nur” Fussgaenger oder maximal Radfahrer und damit nicht das Hauptpublikum … :o
Und damit braucht es tatsaechlich immer noch Hilfswege ueber die Hauptachsen von Strassenflaechen fuer brauchbares Routing. Statt “Tagging for the renderer” nun also “Tagging for the router”
PS: Ein aehnliches Problem hat unter anderem auch die Stadt Bielefeld hier: sie selbst haben Strassen nur als Katasterflaechen, aber nicht als routingfaehigen Graphen. Deshalb nutzt die Stadt dafuer schon seit einiger Zeit OpenStreetMap-Daten, u.a. auch fuer den Strassennetz-Layer im offiziellen Online-Stadtplan.
Naja - das ganze ist schon in Ordnung. Viele Flächen haben “Löcher” wie Springbrunnen etc in der Mitte. d.h. die komplexität steigt ziemlich schnell ins unermessliche wenn man versucht da automatisch linien für den Graphen über die Fläche zu legen - den man ja für das Routing braucht.
Es gibt da Paper zu, es gab da IMHO auch mal auf der SoTM oder FossGIS talks zu. Das ganze Thema ist ziemlich kompliziert. Es ist vermutlich deutlich besser einfach explizite ways zusätzlich einzuzeichnen. Das verhindert eben auch das es immer mal so random mäßig mal kaputt geht.
Lieber ex als implizit.
Flo
3 Likes
Aber explizit bitte nur wenn der Weg “on the ground” als solcher sichtbar ist, nicht einfach eine random Linie über den Platz a la “mapping for the router”. Das wäre Daten verhunzen für schlechte Software - das wollen wir nicht.
1 Like
Da fallen mir dann aber etliche Kreuzungsbereiche ein, wo die Linie OTG ebenfalls nicht eindeutig ist.
Wie erzeugt ihr den in der Geofabrik einen routingfähigen Graph bei Flächen?
Hallo,
Wie erzeugt ihr den in der Geofabrik einen routingfähigen Graph?
Die Geofabrik benutzt 08/15-OSRM und Graphhopper, und wenn die außenrum
um einen Platz rumrouten dann ist das halt so. Hat sich noch nie ein
Kunde beschwert und wenn sich einer beschweren würde, dann würde ich
denen sagen, dass die Software das halt nicht kann. Ich würde sicherlich
keine Kanten quer über den Platz einzeichnen nur damit sich die Kunden
freuen
Bye
Frederik
Aus einem ähnlichen Grund gibts im ATKIS die sogenannte “Gewässerstationierungsachse”. Das ist nämlich eine fiktive Achse die in ein flächenförmiges Gewässer gelegt wird, damit das Gewässernetz immer und überall als Linien vorhanden ist. Dazu wird noch über die Attribute zwischen “Genäherte Mittelline in Gewässern”, “Fiktive Verbindung in Fließgewässern” und “Fiktive Verbindung in Seen und Teichen” unterschieden.
Im Grunde könnte man das gleiche auch auf OSM übertragen und fiktive, aber routbare, Verbindungslinien in die flächenförmigen Highways (und andere betroffene Objekte) legen. Von mir aus kann das ganze dann auch wirklich als “Fiktive Verbindung” oder ähnliches getaggt werden.
Nachtrag: Diese fiktiven Wege wurden in der Mainzer Altstadt im Grunde schon genau so umgesetzt. Dort sind die ganzen Fußgängerzonen als Flächenförmige highway=pedestrian und zusätzlich ligen in den Flächen linienförmige highway=pedestrian über die auch noch Buslinien und andere Relationen verlaufen. Das einzige was dort “”“fehlt”“” ist ein Tag á la “Fiktive Verbindung im flächenförmigen Highway”
4 Likes
Hallo,
ich sehe nicht, wie man solche fiktiven Linien rechtfertigen könnte.
“Ich will gern eine mangelhafte Software einsetzen, deswegen brauche ich
diese Zusatzlinien in OSM, ignoriert sie doch bitte wenn sie Euch
stören, ich hab extra ein fiktiv-Tag drangemacht”, das ist üblicherweise
nichts, was wir uns lange anhören…
Bye
Frederik
Was ist denn daran mangelhafte Software? Mit der Argumentation können wir auch anfangen sämtliche Straßen nur noch als Flächen zu erfassen. Es ist für Router einfach ein anderes Datenmodell erforderlich. Und warum soll man nicht beide Datenmodelle bedienen?
2 Likes
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.
2 Likes
kennst Du eine Router, der das kann?
1 Like
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
Integrating Open Spaces into OpenStreetMap Routing Graphs for Realistic Crossing Behaviour in Pedestrian Navigation hatte dazu schöne Grafiken:
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.
1 Like
Du kannst z.B. das pre-processing von GitHub - PlazaRoute/plazaroute: Routing through pedestrian areas nehmen, dass sollte mit jedem OSM Router funktionieren.
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.
Flo
4 Likes
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.
2 Likes
Der hiesige Marktplatz ist schon seit 10 Jahren so gemappt (Fläche + virtual:highway=pedestrian).
Ich sehe gerade dass foot:Valhalla überhaupt nicht über pedestrian-Flächen routet (auch net am Rand),
das is natürlich kappes.
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.
1 Like