Taunusklub-Wanderwege

Super, das hat geholfen. Mir scheint es mit dem Quelltext sicherer zu sein, auch wenn es ein bisschen komplizierter ist.

Die Schaltfläche “Bild einbetten” gibt es bei mir nicht … Das Bild möchte ich ja in die Tabelle an der richtigen Stelle einbetten.

Oh je: Wie soll ich denn den Satz verstehen? Oder war der erst einmal die Diskussionsgrundlage?

Das sollte heißen, dass du die freie Wahl hast und ich da keine Einschränkungen mache. Beim Hochladen wäre die Auwahl “PD-textlogo” das am besten passende.

Doch: geht nach deutschem Recht nicht. Alternative wäre CC0 oder aber die WTFPL. :slight_smile:

Wikimedia benutzt die Begriffe weitestgehend synonym in ihren Lizenztexten, CC0 gibt es dort gar nicht. “PD-self” hat diese Problematik im Kurztext enthalten.

Hallo Zusammen,

und gesundes Neues noch! Lange habe ich mich nicht mehr gemeldet, aber die Korrektur der Relationen samt der Umbenennung nach der neuen Namenskonversion hat mich ordentlich beschäftigt. Das Ausfüllen der WiKi-Tabelle habe ich dafür erst einmal außen vorgelassen.

Jetzt weiß ich jedoch nicht weiter & wollte Euch fragen, was ich tun soll …

Welche Stelle? - Bad Homburg, im Kurpark gibt es den Platz vor der Spielbank Bad Homburg mit Kaiserbrunnen, welcher Bestandteil von ein paar Wanderrouten ist.

Welcher Wegverlauf? - Diese laufen von links oben am Platz, vorbei am Kaiserbrunnen und gehen dann zu dem Weg, der einen Kreis um den nächsten Brunnen macht.

Wenn ich den ganzen Platz in die Relation einbinde, dann erscheint mir das viel zu groß, da der Platz ja auch noch um das Golf-Feld läuft, was sehr vom Weg abführt.

Wie würdet Ihr in diesem Fall vorgehen? Soll ich einen Weg quer über den Platz zwischen meinen beiden Punkten legen, um darüber die Relationen zu führen? Oder gibt es noch eine elegantere Lösung.

Vielen Dank für Eure Hilfe. Stubenkater

Hallo,

keine Beantwortung deiner Frage, sondern nur ein kleiner Tip: Wenn du Fragen zu bestimmten Stellen stellst, dann ist es immer gut und hilfreich diese Stelle per Link anzugeben, damit man nicht so lange suchen muß. Daß kannst du indem du auf openstreetmap.org nach Auswahl des richtigen Kartenausschnittes rechts auf “Teilen” gehst (der Pfeil der aus dem Kästchen rausgeht). Dann den Kartenmarker setzen und an die richtige Stelle der Karte schieben und dann die im Textfeld angezeigte Url kopieren:

https://www.openstreetmap.org/?mlat=50.22819&mlon=8.62641#map=18/50.22819/8.62641

Zum Inhalt deiner Frage denke ich können andere mehr sagen.

Schöne Grüße
unixasket

Also der Platz da https://www.openstreetmap.org/way/37811796? Hier rüber?

Genau das ist hier die bevorzugte Lösung, die habe ich jetzt mal grad eingebaut.

Dabei habe ich den (ja eigentlich durch den Platz abgedeckten) Weg als “virtuellen” Weg eingetragen und ihn mit virtual:highway=foot getaggt.

Edit: Nach einer Forensuche stieß ich auf diesen Thread, wo neben virtual:highway=* auch highway=virtual erwogen wurde. Ich hab nun mal beides eingetragen.

Warum denn überhaupt den highway=footway irgendwie verstecken/verkomplizieren, wenn er doch als etablierter Laufweg von Punkt a zu b zweifelsfrei existiert?
Jo

Als “Laufweg” ja, aber nicht als on the ground erkennbarer Highway.

Ich kann Stubenkater gut verstehen, denn erst unlängst ist meine bevorzugte Outdoor-Routing-App (Mapy.cz) an einer Footway-Area gescheitert und wollte mir kilometerlange Umwege aufbrummen

Zur Klarstellung: den Weg der über den Platz statt über die Wiese führt auch auszubilden, statt eine Fläche in eine Wanderwegsrelation einzubauen, halte ich für richtig und wünschenswert.

Ich frage nur:
Warum soll das tagging des Weges mit Sonder-Keys (unnötig) verkompliziert werden?
Welche Vorteile sollen sich denn daraus ergeben?

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.