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/#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 
–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.