Relation „Taunusklub Routen“

(Als ich meinen Beitrag #5 aus der Vorschau hochgeladen habe, ist ein vorhergehender Beitrag von alo8, der in der Vorschau noch zu sehen war, verlorengegangen. Irnkwas ist da hochgradig buggy in der Forumssoftware. Kann das ein Admin wiederherstellen?)

–ks

(Es hing noch ein Beitrag von alo in der Freigabequeue, jetzt ist er vorhanden. Löst das Dein Problem)

Das tun die Autobahnen auch, dennoch haben wir keine Superroute „Autobahnen in Deutschland“. Die Straßen in Strinz-Margarethä bilden auch ein Straßennetz, dennoch machen wir keine Superroute daraus. Und es stimmt, bei Radwegen gibt es diese Unart noch. Wem das nützt, ist mir schleierhaft.

Welches Problem wird dadurch gelöst? Welche praktische Anwendung profitiert davon? Wenn der Taunusklub seinen Mitgliedern die Möglichkeit bieten will, das gesamte TK-Wegenetz auf einmal in Übersicht zu sehen, soll er entsprechende GPXe oder sonstwas verteilen. Den Nutzen in einer öffentlichen Datenbank sehe ich nicht.

Woran soll sie dies erkennen? Superrouten sind an sich (als Gesamtwege aus einzelnen, aneinanderhängenden Wanderwegen) nützlich und darstellenswert; bloße Zusammenfassungen von Netzen, die gegenüber der Summe der Einzelwege keinen Zusatznutzen bieten, sind es nicht. Wir brauchen bei type=superroute also noch ein Tag, ob es dargestellt werden soll oder nicht.

–ks

(Diese Freigabemimik erzeugt IMHO mehr Ärger, als sie vermeidet. Zum Beispiel ist mein Beitrag #5, auf den ich mich bezog, jetzt auf #6 gerutscht. Referenzen sollten einklich erhalten bleiben.)

–ks

Relativierend hinterher:

Ich habe gar nichts grundsätzlich dagegen, Netze zu erfassen, wenn es dafür praktische Anwendungen gibt. Aber dann gilt das für alle Netze, auch Straßen-, Strom- und Wasserwegenetze. Dafür wäre dann ein Relationstyp type=network einzuführen, mit network=hiking / waterway / power etcetera. Dann weiß auch jeder Renderer bzw. Overlayer, dass das keine Routen sind. Aber type=superroute dafür zu nehmen halte ich für einen Missbrauch.

https://wiki.openstreetmap.org/wiki/Types_of_relation sagt übrigens: „superroute contains (concatenable) routes only“, also Routen, die sich in eine Reihenfolge bringen lassen.

–ks

@Kreuzschnabel, danke für die Beispiele und die Erläuterungen!

Die Abbiegebeschränkungen habe ich noch gern, zumal man diese so schön mit dem Tool von Zartbitter ansehen und prüfen kann.
Dagegen bin ich kein Freund von “site”- und “associated-street”-Relationen…

Zu den Superrouten habe ich bisher noch keine Meinung. Allerdings stört mich, das diese, wie erwähnt,

beim JOSM aufleuchten. Ist das so gewollt?

Wenn die Relation 7029441 „Taunusklub Routen“ als Netzwerk nicht in die Datenbank gehört, dann gehört die Relation 5397134 “Mountainbikenetz Rhön” sicherlich auch nicht in die Datenbank. Wenn das so ist, werde ich die löschen. Oder?
Vor zwei Jahren hab ich damit mal angefangen.

https://mtb.waymarkedtrails.org/#route?id=5397134

Möchte ich für einen Fehler halten. Der Typ superroute ist sinnvoll und in Verwendung, um lange Wanderwege zu erfassen. Schau dir mal meinen vielzitierten E1 an. Eine normale Routenrelation ist http://www.openstreetmap.org/relation/4800671 (E1 Taunus Mitte), diese Relation ist Teil der Superroute http://www.openstreetmap.org/relation/36367 (E1 in Deutschland), und diese Superroute wiederum Teil der Superroute http://www.openstreetmap.org/relation/371743 (E1 komplett). Man sagt, dass aus Gründen der Übersichtlichkeit eine Routenrelation nicht mehr als 300 Members haben sollte. Da wären die Superrouten als normale Relationen viel zu groß.

–ks

Das scheint mir kein Netzwerk zu sein, sondern ein Rundkurs mit Alternativen. Das ist für mich eindeutig eine Route, man kann sie von A nach B fahren (bzw. von A nach A, als Rundkurs), wobei die Hervorhebung auf der Karte bei der Wegfindung hilft. Aber wem hilft eine Hervorhebung aller Taunusklub-Routen auf der Karte?

–ks

Nein, das ist kein Rundkurs. Das ist ein Netzwerk mit ganz vielen Abzweigen, Verbindungen und Varianten.
http://www.rhoen-active.de/mountainbiking.html

Dass das hier wie ein Rundkurs aussieht, liegt daran, dass ich erst diese Abschnitte nachgefahren bin. Und das ist nur ein kleiner Teil des Ganzen.

Wenn die ganzen verschiedenen Alternativen und Varianten jeweils mit eigenen Relationen beschrieben sind und die Netzwerkrelation nur diese Relationen enthält, dann ist sie überflüssig.

Wenn die Netzwerkrelation direkt die ganzen Ways enthält, dann ist es eine übliche Darstellung von netzwerkförmiger Routenführung. Die Wandernetzwerke z.B. in der Schweiz sind so dargestellt.

bye, Nop

Die Taunusklub Routen Relation und damit die Datenbank enthält keine Darstellungsanweisung “TR”. Die Darstellung mit “TR” ist eine (clevere) “Erfindung” des Waymarked-Trails-Kartenrenderer.

Mittels osmc:symbol, wiki:symbol und symbol gibt es IMHO diese Tags schon, die festlegen wie ein Wanderweg beschriftet werden soll.
Wenn eine superroute diese Tags nicht hat, sollten die Tags der subrouten verwendet werden. Im unschönen Fall das weder sub- noch superroute diese Tags haben kann der Renderer sich bei Bedarf selbst was ausdenken (wie hier “TR”).

Der Hinweis das type=superroute für die Taunusklub Routen nicht passt und durch type=network ersetzt werden sollte ist völlig richtig.

Der Kernpunkt der Diskussion hier ist für mich die Frage ob oder welche Netzwerke in den OSM Daten erfasst werden sollen.
Eins von vielen Beispiel: Ist es sinnvoll alle Buslinien in Frankfurt in einem Netzwerk zusammenzufassen (Relation 172258)?
Für typische Kartenrenderer (z.B. die klassischen OSM tiles) ist das nicht relevant. OSM als Geodatenbank kann damit jedoch Anwendern, die an mehr als eine reine Kartendarstellung interessiert sind, eine übersichtlichere Datenstruktur bieten. Wer als Anwendung z.B. Routing im Busnetzwerk betreiben möchte hat über eine Relation Zugriff auf das ganze Netz. Technisch könnte man natürlich mittels einer Overpass Abfrage oder einer extensiven Suche in JOSM jedes Netzwerk rekonstruieren/ersetzen (wenn denn alle Tags der Subrelation korrekt gesetzt sind).

Persönlich halte ich Netzwerke in OSM durchaus für sinnvoll.
Wanderwegnetze sind in OSM jedoch meistens nicht als Relation erfasst. Stattdessen gibt es Wiki-Seiten die dies etwas strukturieren (z.B. http://wiki.openstreetmap.org/wiki/WikiProject_Germany/Wanderwege-Netz)). Von daher weicht die Erfassung der Taunusklub Routen als ein Netzwerk in der Tat vom üblichen Vorgehen ab und kann entfallen.

Wie (als Vorschlag), ja. Aber nicht, ob er überhaupt dargestellt werden soll. Das meinte ich.

Das nehme ich ihm nicht mal übel. Aus seiner Sicht ist das ein zusätzlicher Wanderweg über den anderen, der muss ja irnkwie dargestellt werden. Wenn der E1 (type=superroute) auf dem X15 (type=route) verläuft, werden ja auch beide Schildchen an den Strich gesetzt, und das ist gut und richtig so. Hier verläuft für den Renderer ein Weg namens „Taunusklub Routen“ gemeinsam mit einem anderen Wanderweg, und das kann er nur darstellen, indem er noch ein TR dranbatscht.

–ks

Ich hab die fragliche Relation mal in type=network geändert. Damit ist sie noch nicht „weg“, falls sie noch gebraucht wird, wird aber in der Waymarked-Trails-Karte hoffentlich nicht mehr dargestellt.

Und da fällt mir auf, dass ich unbeabsichtigt schon vier weitere type=network-Relationen im Speicher habe, so ganz neu ist die Idee nicht :slight_smile:

–ks

In den Routen sollte doch schon lwn, … als network enthalten sein. Um das Netzwerk lwn - auch aus verschiedenen Routen bestehend zusammenfassbar zu machen, sollte vielleicht lwn=(Stadt, Kreis, Gemeinde, Verband) zugefügt und damit auswertbar werden.

Wir haben hier auch verschiedene Wanderrouten (Bergbaugeschichte, Stadt, Naturschutzverein) die somit z.B. eine Möglichkeit hätten lwn=Heimatfreunde Braunsdorf e.V. zu nutzen.

Ob Sammelrelationen in OSM gehören und ob sie schnellstmöglich entfernt werden sollten, gab es schon hitzige Diskussionen.
Sie ergeben keinen neuen Objekttyp, der nicht aus den Tags abgeleitet werden kann, können aber die Auswertung erleichtern.

Wenn sie schon angelegt werden, sollten sie aber nicht andere type=* missbrauchen, sondern z.B. als type=network kenntlich gemacht werden, type=collection (sic!) habe ich auch schon gesehen. Dass dann der JOSM-Validator meckert, muss man hinnehmen.

Das kodiert bislang aber nur die Bedeutung einer Route (von lokal bis international), nicht die Zugehörigkeit zum Wegenetz eines Betreibers.

Die Idee ist nicht übel. Wenn wir außer operator=Taunusklub auch noch rwn=Taunusklub dranschreiben, kann man das Wegenetz leicht selektieren.

–ks

Scheint nichts genutzt zu haben, das TR ist noch drin :wink:

Da fallen aber auch andere Merckwürdigkeiten auf, z.B. https://www.openstreetmap.org/relation/548324

–ks

nur zur Info und sicherheitshalber einfach mal Lonvia direkt fragen, aber sie nimmt (gnadenlos) die ersten Buchstaben der Wörter (leerzeichengetrennt) des Routennamens, wenn kein Symbol vorhanden ist. :wink:

PS: Deswegen gibt’s bei mir auch R(undwanderweg) T(alsperre) S(chönbrunn) und H(eimatgeschichtlicher) W(anderweg), wobei ich nochmal beim HW gucken muss, ob der nicht komplett mit weiße Fläche grüner Balken beschildert ist.

operator=* ist aber bestimmt der Landkreis oder die Gemeinde (Verantwortlichkeit).

Ist zumindest in Sachsen so festgelegt - auch die Festlegung über die verwendbaren Wanderwegmarkierungen für “lcn”, “rcn”, “ncn” und “icn”.

Die Betreuung erfolgt meist durch verschiedene Vereine. Die Instandhaltungspflicht wird manchmal an das Forstamt delegiert - z.B. Tharandter Wald.
Auch lokal gibt es Heimat- oder Dorf-Vereine die “ihre” Wanderwege betreuen und dort könnte z.B. dann lwn=Heimatverein … e.V. ihre Wanderweg “zusammenfassen”.