Relation „Taunusklub Routen“

Relation 7029441 „Taunusklub Routen“ (nur echt mit fehlendem Bindestrich) scheint mir eine reine Sammelrelation ohne direkten Nutzen zu sein. Der einzige Erfolg ist, dass die Waymarked-Trails-Karte im Taunus mit TR-Etiketten nur so gepflastert ist: https://hiking.waymarkedtrails.org/#?map=13!50.143!8.4229

Spricht was dagegen, die Relation einfach zu löschen? Relationen sollen funktionale Gruppierungen abbilden, nicht inhaltliche.

–ks

Nö, mMn nix.

Gruss
walter

Ich hab den Ersteller mal per http://www.openstreetmap.org/changeset/46531781 hierher eingeladen.

–ks

@kreuzschnabel: Danke für die Einladung an mich als Ersteller der Relation.
Die Frage ob die Taunusklub Routen als Ganzes eher eine Relation oder Kategorie sind ist durchaus berechtigt.

Für eine Relation spricht aus meiner Sicht:

  • Die einzelnen Tracks bilden zusammen ein Wanderwegnetz, sind lokal und geographisch zusammenhängend
    (analog zu anderen Wanderwegen, Radwegnetzen oder Relationen der Netze des öffentlichen Nahverkehrs)
  • Über ein einziges OSM Objekt kann damit auf das komplette Wanderwegnetz des Taunusklub zugegriffen werden

Für eine Kategorie (und damit ein Löschen der Relation) spricht aus meiner Sicht:

  • Übersichtlichere Darstellung in der Waymarked-Trails-Karte
    (jedoch sind OSM Daten eigentlich als unabhängig von späteren Visualisierungen gedacht. Im Prinzip könnte die Waymarked-Trails-Karte dies erkennen und korrekt/übersichtlich darstellen)

Gibt es noch weitere Argumente pro/contra?

Für mich ist beides OK, bestehen lassen oder löschen.

Gruß
alo

Ich verstehe die Abgrenzung auch nicht immer so recht, hättet Ihr für beide Varianten mal 3 Beispiele?

Ist eine inhaltliche Gruppierung etwa eine “site”-Relation?

Nebenbei, was ist der Hintergrund der Warnmeldung des JOSM-Validators im Prüfergerbnisse-Fenster:
Warnungen >> Relationstyp unbekannt >> superroute (“xxxxxx”)

Relationen setzen OSM-Elemente zueinander in Beziehung, um Sachverhalte abzubilden, die nur in der Beziehung bestehen und nicht am einzelnen Element abbildbar sind. Bestes Beispiel dafür ist die Abbiegebeschränkung. Der Sachverhalt „von hier über diesen Punkt nach hier darf man nicht abbiegen“ lässt sich nicht an eines der Elemente taggen, dafür müssen wir die drei in Beziehung setzen, in eine Relation halt, vom Typ restriction. Auch wenn man jedes Element benutzen darf, in dieser Reihenfolge darf man es halt dann nicht. Auch ein gutes Beispiel ist die Abbildung von Wanderrouten, die über Dutzende oder Hunderte von ways verlaufen. Wir setzen alle Ways in der Relation hintereinander und bilden so die virtuelle Route auf den physischen Wegen ab, so ergeben sie ein größeres Ganzes, das mehr ist als die Summe seiner Teile.

Sammelrelationen dagegen bilden keine funktionalen Beziehungen ab, keine „Zusammenarbeit“ von Elementen, sondern stellen nur Schubladen dar. Beispiele wären „Telefonzellen in NRW“, „Briefkästen, die vor 7 Uhr geleert werden“ oder „Obstplantagen im Bodenseeraum“. Also nicht „die ergeben zusammen einen wichtigen Sachverhalt“, sondern „die haben ein gemeinsames Merkmal“. Das Ganze ist in diesen Fällen nicht mehr als die Summe seiner Teile, die Elemente werden nicht in funktionale Beziehung zueinander gesetzt. Wer diese Daten haben möchte, bekommt sie auch über eine gebietsbezogene Datenbankabfrage.

Ich gebe zu, dass es Grenzfälle gibt. Die site-Relation sammelt nicht, sondern ordnet separate Flächen einer Einrichtung zu. Man könnte sie als Spezialfall eines Multipolygons betrachten. Ein noch vagerer Grenzfall ist IMHO die associated-street-Relation, sie bildet ab, welche Elemente in einer bestimmten Straße liegen, auch Elemente ohne postalische Anschrift (bei Häusern reicht ja auch addr:street dafür).

Im hier diskutierten Fall haben wir eine Relation vom Typ superroute, die aus einzelnen Routenrelationen ein Wanderwegenetzwerk abbildet. Das ist meiner Ansicht nach keine funktionale Beziehung, sondern bildet nur das gemeinsame Merkmal „wird vom Taunusklub unterhalten“ ab. Dazu ließen sich aber auch einfach die operator-Tags der einzelnen Routenrelationen auswerten (wenn die ordentlich gesetzt sind, was sie natürlich sollten).

Der Typ superroute ist zwar durchaus zur Zusammenfassung von Routenrelationen gedacht, aber ähnlich, wie eine normale Routenrelation Ways zusammenfasst: zu einer Gesamtroute. Zum Beispiel bestehen die europäischen Fernwanderwege aus einzelnen nationalen Routen, die dann in einer Superroute zum Gesamtweg verbunden werden. Funktionale Beziehung, nicht nur Sammlung, denn das Ergebnis ist ein Gesamtweg, der dazu gedacht ist, als Ganzes gelaufen zu werden. Das ist deshalb sinnvoll, weil eine einzige Routenrelation für alle Teil-Ways schnell zu groß wird. Die Wege des Taunusklubs ergeben aber keine Gesamtroute. Der etwas skurrile Ehrgeiz, jeden TK-Weg einmal abzulaufen, lässt sich auch anders lösen.

Die Frage ist also: Müssen wir das Wegenetz eines Wandervereins als eigenes Element in der Datenbasis haben? Kein Mensch läuft das ab, also wem nützt das? Ich denke nicht, dass wir das müssen, denn die Wege des Taunusklubs lassen sich, wie gesagt, auch über das operator-Tag der einzelnen Routen abfragen. Einen Nachteil habe ich bereits genannt: Die genannte Karte wertet korrekterweise die Superroute als Wanderroute aus (was wir ihr auch nicht abgewöhnen wollen, sonst würden da die internationalen Wege fehlen, die korrekterweise Superrouten sind) und nimmt sie ins Overlay, mit verwirrendem Ergebnis. Das ließe sich natürlich technisch unterbinden, aber wozu, wenn eine solche Superroute gar keinen echten Nutzen bietet, weil sie keine Funktionalität abbildet?

Ein anderes Argument ist die On-the-ground-Regel: Keine dieser Routen ist in der Realität mit „TR“ für „Taunusklub-Route“ ausgezeichnet, sondern jede einzelne nur mit ihrer individuellen Markierung. Warum sollten sie dann alle zusammen nochmal als „TR“ in die Datenbank?

–ks

(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