Als fläche definierte (Fuß)wege nicht gerendert, und entlang als Relation definierten Flächen-Fußwegen kein Routing.

[osmidal]

Ahoj,

ich stelle fest, dass "area highways" (`highway=*` mit `area=yes`, wie z.B. auch oft in Fußgängerzonen verwendet) nicht gerendert werden.

Und, dass wenn soetwas als Relation definiert ist, auch nicht entlang dessen Kante geroutet wird (bei "nomalen" area highways scheint entlang derer Kante geroutet zu werden.)

Bezüglich Routing: GraphHopper hat das Problem auch, siehe hier.

Hier mal ein Beispiel von der Haltestellenanlage "Infineon Süd" in Dresden (Position: O 13.772, N 51.104) -- dort gibt es einen zentralen Platz, der über eine Relation als Area-Highway definiert ist (das Gebäude in der Mitte gehört nicht dazu) und die Wege drumherum sind auch als `highway=footway` und `area=yes` definiert.

Im Anhang ein Screenshot, was zeigt dass sowohl das Rendering die Wege nicht rendert, als auch das "kaputte" routing.

Im Anhang auch wie es im OpenStreetMap-Standardrendering aussieht.

Rendering und Routing bei wanderreitkarte.de.

Rendering bei openstreetmap.org.

Lieber Gruß!

[Nop]

Das ist ein lustiges Thema - und wie die Wiki Seite schon sagt "there is no clear consensus".

Relations-Footways werden schlichtweg von keiner Routing-Engine unterstützt. Die erfordern eine Sonderbehandlung die einfach niemand implementiert hat. Wenn sich da alle 4 aufgezählten Routing-Engines einig sind, ist das auch ein ziemlich deutliches Statement, und kein Bug.

Aus meiner Sicht sind Flächen-footways sinnlose Objekte. Entweder es ist ein linearer Weg, dann sollte es auch so gemappt werden und nicht als area. Oder es ist ein Platz, dann ist footway ein falsches Tagging. Fußgängerzonen sind highway=pedestrian. Und Routen entlang der Außenkante ist eine realitätsferne Notlösung. Wie auch immer Du über so eine Fläche gehst, Du wirst nicht an der Außenkante balancieren.

Ich bin ein Verfechter der Fraktion in so einem Fall die Fläche nur als Dekoration zu sehen und für das Routing mehrere realistische Laufwege über den Platz als normale highways einzuzeichnen. Von daher ist keine Unterstützung von Flächenwegen geplant, bzw. falls das funktioniert ist es ein zufälliger Nebeneffekt von Graphhopper, das area-Tag wird einfach komplett ignoriert.

Ich dachte mir man könnte solche Flächen wenigstens als Dekoration rendern, aber nach kurzem Nachdenken will ich falsches Tagging von Plätzen als Wegen nicht unterstützen.

[osmidal]

Aus meiner Sicht sind Flächen-footways sinnlose Objekte. Entweder es ist ein linearer Weg, dann sollte es auch so gemappt werden und nicht als area. Oder es ist ein Platz, dann ist footway ein falsches Tagging.

Ich nehme ja diesen Teil aus dem OSM-Wiki wo steht

Differentiation area:highway vs. area=yes on a highway
area:highway=* had been proposed to describe the non-routable, detailed shape of a (typically linear) highway. The tag requires the linear, routable direction of the highway mapped in addition as lines with highway=*.

area=yes on a highway=* describes a routable highway area on which the dedicated traffic can route omnidirectionally; i.e. from any point along the edge to any other. This is typical for pedestrian areas, or service areas where vehicles drive without prescribed lanes. The rationale is that routing engines should consider those omnidirectional objects in addition to nodes and edges in classical graph theory; thus no linear highway lines would be required within. However, as of 2019, OpenTripPlanner is the only OSM-based router that supports routing over areas. It does so by computing a visibility graph over the area. [1]

Fußgängerzonen sind highway=pedestrian.

Wie macht man dies eigentlich korrekt nicht als Relation, wenn in der Mitte ein Objekt ist was ein "Loch" in die Fläche stanzt?

zufälliger Nebeneffekt von Graphhopper, das area-Tag wird einfach komplett ignoriert.

Ah, damit heißt es implizit, dass wanderreitkarte.de GraphHopper als routing backend verwendet.

Ich dachte mir man könnte solche Flächen wenigstens als Dekoration rendern, aber nach kurzem Nachdenken will ich falsches Tagging von Plätzen als Wegen nicht unterstützen.

Lineare Wege quer über einen Platz zu zeichnen ist halt auch unschön, und es gilt ja das Prinzip dass man nicht für externe tools taggen soll -- also wenn da wirklich ein großer Platz im Zentrum der Stadt ist ohne dedizierte Wege, wären die Wege ja die "Krücke" um es anderen Tools schmackhaft zu machen, aber realitätsfern. So verstehe ich die OSM-Philosophie.

Routing am Rand von Kanten von Flächen-Wegen ist eine Notlösung, aber ausreichend denke ich.

Lieber Gruß!

[Nop]

Wie macht man dies eigentlich korrekt nicht als Relation, wenn in der Mitte ein Objekt ist was ein "Loch" in die Fläche stanzt?

Die Fläche als Multipoly-Relation abbilden. Rein für die Optik, nicht routbar.
Die routbaren Laufwege zusätzlich als highway darüberlegen.
Der Erlanger Schloßplatz ist ein funktionierendes Beispiel.

zufälliger Nebeneffekt von Graphhopper, das area-Tag wird einfach komplett ignoriert.

Ah, damit heißt es implizit, dass wanderreitkarte.de GraphHopper als routing backend verwendet.

Genau. Es ist ein für das Reiten modifizierter Graphhopper.

Ich dachte mir man könnte solche Flächen wenigstens als Dekoration rendern, aber nach kurzem Nachdenken will ich falsches Tagging von Plätzen als Wegen nicht unterstützen.

Lineare Wege quer über einen Platz zu zeichnen ist halt auch unschön, und es gilt ja das Prinzip dass man nicht für externe tools taggen soll -- also wenn da wirklich ein großer Platz im Zentrum der Stadt ist ohne dedizierte Wege, wären die Wege ja die "Krücke" um es anderen Tools schmackhaft zu machen, aber realitätsfern. So verstehe ich die OSM-Philosophie.

Das sehe ich anders. Wenn etwas von keiner existierenden Routingengine unterstützt wird - und das wurde ja für vier Engines geprüft und bestätigt- gibt es höchstwahrscheinlich einen guten Grund. Entweder ist es technisch nicht möglich, nicht sinnvoll, ein unverhältnismäßiger Aufwand, schädlich für die Performance oder ähnliches.

Realitätsfern ist es dann es trotzdem zu mappen und zu fordern, daß jemand anders das halt umsetzen muß. Hier sagt der Open Source Gedanke, daß diejenigen, die es haben wollen, sich auch die Arbeit machen sollten es zu bauen und einen entsprechenden Pull Request für die Routing Engines einreichen.

[osmidal]

Relations-Footways werden schlichtweg von keiner Routing-Engine unterstützt.

Ein Fakten-Update:

Die vorliegende Fläche ist laut diesem Beitrag ein korrekt definiertes Multipolygon und multipolygon-footways sind per Quasistandard vorgesehen (halt normale "area-footways").

Multipolygone werden über relations definiert, seien aber als flächen zu interpretieren.

Also ja, auch wenn Routing-Engines es nicht unterstützen, ist es zumindest so vorgesehen dass das so gemeint sein sollte.

Ich persönlich gehe sehr mit mit diesem Kommentar:

For new areas I’m adding myself, my personal mental rubric is more-or-less:
“Can this space for pedestrians be reasonably represented by a single centerline?” → `area:highway=*`
“Does this space for pedestrians exist to facilitate arbitrary connections between any two points on its border?” → `highway=pedestrian`+`area=yes`

Dementsprechend werde ich die fragliche Gegend gleich aktualisieren; den Platz in der Mitte als Multipolygon belassen, aber die Wege drumherum um-taggen.

Und dies hier auch als "issue" für Wanderreitkarte schließen, da Wanderreitkarte GraphHopper benutzt ist es wenn dann dort relevant.

Lieber Gruß!

[osmidal]

Realitätsfern ist es dann es trotzdem zu mappen und zu fordern, daß jemand anders das halt umsetzen muß. Hier sagt der Open Source Gedanke, daß diejenigen, die es haben wollen, sich auch die Arbeit machen sollten es zu bauen und einen entsprechenden Pull Request für die Routing Engines einreichen. ;-)

Addendum:

Ich sehe nicht, dass ich etwas gefordert habe.

Ich habe in meinem Verständnis dessen, wie OpenStreetMap features als "valide" definiert gemappt und routing engines, die dies nicht umsetzen, darauf aufmerksam gemacht. Ob und wann die das umsetzen ist den Projekten überlassen; schön fände ich natürlich wenn Dinge, die im Datenlieferant als "valide" gelten, im Datenverarbeiter auch bearbeitet werden, aber fordern kann ich das nicht.

Ich finde der Open Source-Gedanke ist auch offen für Menschen, die nicht die Programmierkenntnisse haben, etwas umzusetzen, aber mitteilen, wenn irgendwo eine Unstimmigkeit ist.

Ich habe ja nach Deiner Antwort hier sogar bei OSM im Forum zurückgefragt, ob das überhaupt korrekt sei, und die genannte Fläche sei ein korrektes Multipolygon für das `highway=footway` definiert sei.

Wo meinst Du hätte ich eine Forderung gestellt?

Lieber Gruß!

[mtb-Herten]

Hallo zusammen,
so wie es jetzt (18.04.25 um 21:38Uhr) gemaped ist, kann ich keinen Fehler entdecken.
Das Routen sollte so funktionieren. Ein Routing braucht immer eine Linie, alles andere
macht keinen Sinn. Aber, dass ist nur meine Meinung/Erfahrungen beim Karten erstellen.

Wenn es da andere Vorgaben gibt, wäre das aber blöd.

[Nop]

Wo meinst Du hätte ich eine Forderung gestellt?

Das war jetzt nicht unbedingt auf Dich persönlich gemünzt, sondern auf alle die sich irgendwas theoretisch ausdenken und gleich mal so mappen und ins Wiki schreiben, ohne zu verstehen daß es technisch irgendwo zwischen unmöglich bis ein irrsinniger Aufwand ist (und es eine viel einfachere Lösung gäbe), aber die Erwartungshaltung haben dass andere Leute sich dann darum kümmern und das dann irgendwie zum Funktionieren bringen sollen. Davon habe ich in über 15 Jahren OM leider schon zu viele getroffen und bin daher auch ein wenig dünnhäutig geworden.

Für mich geht das irgendwie zusammen: Entweder ich definiere einen neuen Tagging-Standard und zeige selbst bzw. mit einem beteiligten Entwickler mit mindestens einer Referenzimplementierung wie das sinnvoll auszuwerten ist. Oder ich bin nicht in der Lage, so eine Auswertung zu machen, dann liegt aber auch nahe daß ich nicht qualifiziert bin die Tags dafür zu definieren und sollte das auch lassen. (Ich z.B. halte mich konsequent aus MTB-Tags raus, davon habe ich einfach keine Ahnung).

Ich verstehe allerdings auch daß Du das Tagging aufgrund des Wikis als "valide" wahrgenommen hast, obwohl ich es eher als "umstritten" und "nicht unterstützt" bezeichnen würde, und da letztendlich nichts dafür kannst. Den nicht unterstützten Taggingvorschlag haben andere ins Wiki geschrieben. Nix für ungut.

[osmidal]

Ich glaube die hier diskutierte Routing-Sache ist eine Instanz hiervon:

https://github.com/osmlab/fixing-polygo ... /issues/33

-- dort wird "offiziell"(?) von Deprecation von old-stylе multipolygons geschrieben, so dass die Tags bei multipolygons nicht mehr an den Weg selber, sondern an die multipolygon-Relation kommen.