Taunusklub-Wanderwege

Er existiert als Verbindung zwischen den Punkten, ist aber eben OTG nicht gegenüber dem Umfeld hervorgehoben.

Vergleiche die Situation mit einer Wiese: Wenn auf der Wiese ein gut erkennbarer Trampelpfad ist, ist das für mich highway=path. Ist aber auf der Wiese nichts zu erkennen (weil pro Woche nur fünf Leute diesen Weg nehmen), oder handelt es sich im einen Schotterplatz oder sonstwas Robustes und die “Anweisung” des Wanderwegs lautet “gehe von da nach da”, ist es eher ein virtueller Weg. Er dient dann nur der Anwesenheit in der Route, hat aber gegenüber seiner Umgebung ansonsten keinen Sonderstatus (durch Hervorhebung o. ä.).

@glglgl
Ich dachte dafür wäre trail_visibility
https://wiki.openstreetmap.org/wiki/Key:trail_visibility
zuständig und kein zusätzlich verkomplizierender highway-Tag?

Halte ich für einen falschen Gebrauch dieses Tags. Ein virtueller Weg über einen festen Platz müsste dann trail_visibility=no haben (er hebt sich ja null von seiner Umgebung ab), ein Wert, der laut Wiki als „meist weglos“ charakterisiert wird und „ausgezeichnetes Orientierungsvermögen“ erfordert. Fußgänger-Router werden Wege mit diesem Tag vermutlich nach Möglichkeit meiden, wofür hier aber überhaupt kein Grund besteht.

Ich bin der Meinung, dass Auswerter langsam mal lernen sollten, dass ein highway=* + area=yes in OSM eine frei routbare Fläche darstellt, zwischen deren Nodes nach Belieben Verbindungen gedacht werden können, ohne dass man diese Verbindungen zusätzlich eigens als virtuelle Wege einmappen muss. Das kann doch nicht so schwierig sein.

–ks

Ich würde es einfach als way über die Fläche mit highway=pedestrian eintragen. Dort lassen sich noch access (z.B. bicyle=dismount) eintragen, die auch auswertbar sind. Ist an vielen Stellen auch nachvollziehbar, wenn man einmal eine Weile die Bewegungen der Menschen verfolgt (besonders bei Neuschnee).

https://www.openstreetmap.org/directions?engine=fossgis_osrm_bike&route=51.05928%2C13.74198%3B51.05871%2C13.74300#map=19/51.05896/13.74244&layers=N

https://www.openstreetmap.org/#map=19/51.05914/13.74198&layers=ND

Ist das “richtiger”: https://www.openstreetmap.org/directions?engine=fossgis_osrm_foot&route=50.22735%2C8.62726%3B50.22743%2C8.62769#map=18/50.22703/8.62836

hw=virtual finde ich auch nicht richtig. Dann doch trail_visibility=no, wie von Jo vorgeschlagen, wenn es unbedingt sein muss.

Hm, aus der Tatsach daß es noch niemand kann, auch nicht kommerzielle Lösungen, würde ich eher folgern, daß es doch schwierig ist.

Wenn ich nach “route over polygon” im Netz suche, würde ich aus der Masse der wissenschaftlichen Arbeiten und untersuchten Algorithmen folgern, daß es noch eine ganze Ecke schwieriger ist.

Um Deine Behauptung zu untermauern würde ich Dich bitten, einen Algorithmus vorzuschlagen, der den optimalen Weg zwischen beliebigen Punkten findet in einem beliebig geformten Polygon, das beliebige Löcher und Hindernisse enthalten kann. Und zwar so performant, daß er in Routingengines ohne Leistungseinbruch verwendet werden kann.

Abgesehen davon spielen in der Realität bei der Wahl eines Weges noch ganz andere Faktoren eine Rolle, z.B. Gruppen von Hindernissen wie Bänken, wo man sich normalerweise nicht einfach durchquetscht, Fahrbahnen oder andere markierte Flächen, an denen man sich orientiert, Lampen, Wegweiser, Schilder, unterschiedliches Pflaster usw. Vielleicht ist es da doch sinnvoller, echte, in der Realität beobachtete Laufwege sinnvoll zu mappen.

Das ist mMn z.B. im Hochgebirge sinnvoll und führt woanders leicht zu Fehlinterpretationen.

Als gangbar sehe ich die Variante, bei der die Wege denselben Tag haben wie die Fläche, in der sie liegen (Beispiel Haupt"straße" in Dresden).

Besser wartbar wäre hw=virtual bzw. virtual:hw. Das sehe ich nicht als falsch taggen für den Router an, sondern als Hilfe für ihn, denn sonst muss er alle Verbindungen zur routbaren Fläche abklappern. Dieses wäre ggf. jedenfalls leichter zu finden und zu beseitigen als das missbrauchte trail_visibility.

Das Routen über die Flächenbegrenzung wie im 2. Beispiel ist ein Notnagel, ob überhaupt eine Verbindung besteht, für ein tatsächliches Routing aber fast immer unbrauchbar. Da müsste ein Router selber temporär virtuelle Verbindungen über die Fläche legen, wäre bei komplizierter Geometrie aber ziemlich gefordert, da er ja weder über die Blumenbeete noch durch den Brunnen routen soll (s.o.) ;). Dann schon lieber derweil virtuelle Wege als Hilfsmittel.

Du siehst mich erstaunt. Ich habe mich damit zugegebenermaßen noch nicht wissenschaftlich befasst, aber bei einem Fortschrittsstand der Informatik, an dem jede billige Knipskamera bereits ein lächelndes Gesicht von einem nichtlächelnden unterscheiden kann und mir mein Hosentaschencomputer in fünf Sekunden die schnellste Radroute nach Moskau berechnet, sollte es doch möglich sein, in einem n-eckigen Polygon, auf das man an einer definierten Ecke stößt, aus (n−1) möglichen Freizielen das beste rauszusuchen und dorthin gegebenenfalls einen virtuellen Weg zu modellieren, der keine Außen- und Innengrenzen überschreitet.

Hätte ich so was zu programmieren, würde ich den kürzesten Weg entlang der Außengrenze nehmen und diesen so lange nach innen verschieben und vereinfachen, bis er entweder wieder länger wird oder eine Innen- oder Außengrenze des Polygons berührt. Diese Heuristik führt nicht notwenigerweise zur kürzesten Verbindung (weil sie an der ersten Inneninsel hängenbleibt), aber zu einer rout- und gehbaren.

Möglicherweise kann man sogar den Algorithmus nehmen, mit dem die OpenTopoMap die Beschriftung von Seen hinbiegt :slight_smile:

–ks

Man könnte das machen, was heute viele Mapper tun, um ein vernünftiges Routing über Flächen zu bekommen: einen Punkt im Innern des Polygons setzen, diesen mit allen Ecken des Polygons verbinden, von denen Wege abgehen, den so erzeugten Wegen die Attribute des Polygons geben und dann routen wie immer.

Das erscheint mir aber zu einfach zu sein, sonst hätte es sicher schon jemand gemacht. Ich habe da bestimmt etwas übersehen.

Geht nicht, wenn eine große Sperrfläche (z.B. Gebäude) in der Mitte der Routingfläche liegt. Kann man natürlich auch in den Griff bekommen, aber mit jedem Spezialfall wird es halt noch komplizierter.
Ich würde mir als Router-Programmierer schon die Frage stellen, ob sich der Aufwand lohnt, insbesondere wenn ich nicht dafür bezahlt werde.

Hallo beisammen,
da mich das Thema lineare footways und 2D-Fußgängerflächen schon länger beschäftigt,
habe ich großes Verständniss dafür, wenn man diese footways “anders” mappen möchte.

Gegen einen Zusatztag mit der Bedeutung: “dieser Abschnitt verläuft auf einem Platz” bzw. “dieser footway verläuft auf einer in OSM auch 2D-erfassten Fußgängerfläche” hätte ich keinerlei Einwände, ganz im Gegenteil (und nein, ich halte “trail_visibility” dafür nicht geeignet, eher etwas analog zu bridge=yes).

Was mir Bauchschmwerzen bereitet, ist wenn wir in Ermangelung eines geeigneten Zusatztags den Haupttag verbiegen, um irgendetwas zu erreichen. Da würde ich alle bitten, das mal zu Ende zu denken. Soll das tagging für den Renderer werden oder tagging für den Router und ist das die Sache wirklich wert?

Mal als Gedankenspiel andersherum, ein Mapper findet die Lauflinien aka footways eines Parks vor, und möchte 2D-Flächen ergänzen, soll er dann die footways löschen, und die in Relationen enthaltenen per “Mystery-Tag” ins Datennirwana verschieben? Was würden seine “Vorgänger” dazu sagen, die diese ways möglicherweise (weiterhin) auswerten wollen - ist das langfristig Projektförderlich?

Diese meine Gedanken zum Thema in die Runde
Jo

Warum dann als hw=virtuell und nicht den Weg den (die meisten) Menschen benutzen. Über eine Wiese sehen wir den Pfad auch nur, weil dort nichts wächst. Im Winter über eine Fläche weil dort der Schnee “weggetreten” ist.

Ist übrigens auch die Idee von area:highway - Fläche und Weg erhalten die gleiche Bezeichnung.

Sehe ich auch so - war ein Vorschlag von Jo - aber zur Unterscheidung eventuell sinnvoll. Ob der Weg über eine Geröllhalde oder ein Pflasterfläche führt.

Das kann man mit area:highway machen - ich habe das in irgendeinen Park auch schon gesehen (Detailmapping).

+1

Ok, das Argument der Vorwärts-/Rückwärtskompatibilität sehe ich ein. Ich hatte das ja schließlich auch als eine mögliche Variante gesehen.

Man hat dann zwar das Problem, bei Änderungen nicht nur die Fläche, sondern auch alle darin enthaltenen Wege umtaggen zu müssen, aber in irgendeinen Apfel muss man halt beissen.

Und warum jetzt obige “Idee” und nicht diese andere “Idee” aus dem OSM-Ideen-Sortiment:
https://wiki.openstreetmap.org/wiki/Tag:area:highway=footway
vgl. auch https://wiki.openstreetmap.org/wiki/User:Jo_Cassel/Oweia

Vielleicht wäre es das einfachste,
ein Mapper (der offensichtlich an einer 2D-Fläche gar nicht interessiert ist) ließe diese Fußgängerfläche einfach in Ruhe und Frieden,
und verlängere stattdessen nur die linearen Elemente (die ihn interessieren) über diese Fläche.
Das Weg-Tagging ergibt sich aus den benachbarten Parkwegen, (hier highway=footway, surface ist surface der Fläche)

Gedanke dahinter: KISS + keiner zerstört die Arbeit eines anderen

Das würde ich User Stubenkater für den Park in Bad Homburg raten, und genau dieses Tagging habe ich in einem Park bereits kilometerweit umgesetzt, mit mehreren Wanderwegsrelationen im Wegenetz.

Zumindest bis die “richtige Lösung” (wie auch immer die aussieht) Konsens, Dokumentation und Verbreitung gefunden hat… irgendwann…

In #54 war das konkrete, verlinkte Objekt (https://www.openstreetmap.org/way/37811796) aktuell als pedestrian gemappt. Daher konnte ich den Vorschlag von geri-oc gut nachvollziehen.

Ich finde area:highway=* für die Fläche und highway=* für den Weg technisch sauberer und weniger verwirrend für Router als virtual:highway, highway=virtual & Co.

Grüße
Andreas

Guten Morgen unixasket,

danke für den Tipp, welchen ich mir aufgeschrieben habe.

LG Stubenkater

Guten Morgen glglgl,

danke für Deine Hilfe, welche ich schon im Laufe der Woche fand.

Heute Morgen (mein Besuch schläft noch) wollte ich mich dann dranmachen, um alle Relationen auf diesen neuen Weg zu bringen und siehe da: Das hat schon jemand für mich erledigt. Da ich alles im JOSM mache & auch dort nicht fit bin, bin ich natürlich auch nicht in der Lage, dem freundlichen Helfer direkt zu danken.

Die Korrekturen habe ich in meinem Logbuch vermerkt. Vielen Dank noch mal & ein schönes WE.

Hallo alle Zusammen,

an Eurer “theoretischen” Grundsatzdiskussion kann ich mich nicht beteiligen, möchte aber allen für Ihre Meinungen ganz herzlich danken.

Meine Kontrollseite ist die https://hiking.waymarkedtrails.org, welche jetzt die ganzen Wege korrekt über den Platz anzeigt: https://hiking.waymarkedtrails.org/#routelist?ids=55669,79322,153821,900563,934499

Somit möchte ich Euch danken & sehe erst einmal keinen weiteren Handlungsbedarf von mir in diesem Augenblick.

Schönes WE vom Stubenkater

Warum nicht einfach:
hw=pedisterian → 584151 x highway=pedestrian ( 2822 x area:highway=pedestrian) → https://wiki.openstreetmap.org/wiki/Tag:highway%3Dpedestrian

statt neues hw=virtual → 230 x highway=virtual → WIKI ???

Klar macht es Sinn für die Wander-Route - aber routen?

https://www.openstreetmap.org/directions?engine=fossgis_osrm_foot&route=50.22791%2C8.62642%3B50.22836%2C8.62584

@geri-oc
Diese Lösung (Wander)Weg als highway=pedestrian auf highway=pedestrian, area=yes findet sich beispielesweise
in Frankfurt an der alten Oper:
https://hiking.waymarkedtrails.org/#?map=18!50.1157!8.6709
ob dahinter allerdings ein durchdachtes Konzept, oder nur der Wunsch/Gedanke stand, die Wegebeziehungen auf der Standardkarte zu “verstecken” kan ich nicht sagen :wink:
Sicher bin ich mir allerdings, dass wir den ganzen Komplex hier und heute nicht werden lösen können.

@Stubenkater
Du solltes dich durch diese “Metadiskussion”, die ich hier etwas ungewollt angezettelt habe keinesfalls abschrecken oder aufhalten lassen. Habe nicht vor das hier weiter fortzusetzen und wünsche Dir gutes Gelingen für dein Projekt!

Jo