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