Nahmd,
an dieser Stelle macht sich auch die Unzulänglichkeit des OSM-Datenmodells bemerkbar: neben den elementaren geometrischen Objekten Punkt und Linie (wir haben noch nicht mal einen Typ “Fläche”) gibt es nur den Datentyp Relation. Da ist nichts anderes. Wer Zusammenhänge zwischen OSM-Objekten darstellen will, dem bleibt nur die Relation. Jegliche Argumentation vom Type “Relationen sind nicht dies und das” läuft da ins Leere, wenn sie nicht die Frage beantworten kann: “Wie soll ich dies und das darstellen?”
Der Wiki-Eintrag “Relationen sind keine Kategorien” geht an der Realität vorbei und wäre besser gelöscht. Das ist meine Sicht, deshalb werde ich sicher nicht löschen.
Man könnte sich (mal ganz ins Unreine gedacht) etwas vorstellen wie eine umgekehrte Relation: statt dass die Relation auf die Member verweist und mit jedem Neumitglied eine neue Version bekommt, verweisen die Member auf die Relation bzw. einenneuen Typ, nennen wir ihn mal “Entity”, der keine geographische Bedeutung mehr hat oder haben muss. Damit kann man z.B. einen Verein erfassen. Oder ein Projekt. Oder eine Sammlung. Oder was auch immer.
Dazu lässt man als Values für Keys nicht wie bisher nur Stringwerte zu, sondern auch Verweise auf Entities. Die werden in der DB als Referenz abgebildet, sind also eindeutig, sicher gegen Tippfehler (anders als “operator=” und dann ein “Saualändischer GebirgsVerein” in zehn verschiedenen Schreibweisen) und haben auch referentielle Integrität, d.h. solange es eine Referenz gibt, kann man das Entity nicht löschen.
Damit würde man im hier besprochenen Beispiel ein Entity anlegen mit Namen “Projekt Erdhöhlen da und da”, und den Höhlen ein “is_in” (oder ähnlich) geben mit Verweis auf das Projekt-Entity.
Der Vorteil dabei ist, dass das Entity unabhängig von der Anzahl der Verweiser ist und klein bleibt, und auch nicht hunderte bis tausende Versionen hat, weil es sich bei Aufnahme eines Verweisers schlichtweg nicht ändert.
Außerdem muss es nicht in der Relationsbox dargestellt werden; mit sieht statt dessen in der Tag/Value-Box einen Pfeil und die dann den Namen des entsprechenden Objektes.
Ich denke, dass auch die Größe der JOSM-Relationsbox viel dazu beiträgt, die Nutzung von Relationen kritisch zu sehen. Eine kleine Ecke einer Stadt geladen, und die Box quillt über.
Man kann langsam und schrittweise für Key/Value-Paare, über deren Nutzung ein breiter Konsens besteht (z.B.: “highway=residential”), entsprechende Entities schaffen (Straßentyp=Wohnstraße-Entity) und dann die Key/Value auf Key/Pointer umstellen: “highway → Straßentyp=Wohnstraße-Entity”) und genießt danach die Vorteile strukturierter Daten, u.a. Eindeutigkeit und Sicherheit gegen Tippfehler.
Weiteres Beispiel: man könnte auch statt einer Postleitzahl eine Referenz auf ein Postleitzahlbezirk-Entity hinterlegen. Womit eine saubere Beziehung definiert ist. Und man ohne Suche alle Objekte mit dieser PLZ per Index aus der DB ziehen kann. Ginge auch mit einer Relation, aber wer mag eine Relation mit 45764582734653 Mitgliedern haben?
Doch zurück zu den Sammelrelationen: als Alternative zu einer Relation “Berchtesgadener Alpen”, die die dortigen Wege und Hütten und und und enthält, würde ich ein Entity “Berchtesgadener Alpen” vorziehen und dann von den Objekten ein Key “gehört zu” mit Link auf das Entity. Bietet die gleichen Vorteile (sauschnelles Laden aus der Datenbank über Index statt über spatiale Suche) ohne den Nachteil der großen Relationen mit ihren hunderten Versionen.
Und über Höhlen mit einem “Bestandteil des aktuellen XYZ-Projektes”-Attribut wird sich kaum jemand beklagen, insbesonders wenn das verlinkte Projekt-Entity die Beschreibung des Projektes und die Mitarbeiter enthält, so dass man leicht Kontakt herstellen kann.
Entities und Links sind die strukturierte Version der Alternativvorschläge zur Höhlen-Projekt-Sammelrelation.
Nicht ausgegoren und ins Unreine, just my 2.38¢ und zum Weiterspinnen.
Gruß Wolf