Es gibt aber sehr viele Wege in dieser Sparte, ich müsste das überall einpflegen und bei Änderungen überall ändern. Da ist die Gefahr, dass man beim Ändern ein paar Wege vergisst.
Gibt es eine Möglichkeit, bestimmte Attribute nur einmal in eine Relation einzutragen, die dann für alle Mitglieder gelten und wird das von Routern unterstützt?
Mit welchen Relationstyp? Eine Site-Relation verlangt ja, dass das Ganze einen gemeinsamen Namen hat.
Bislang hatte ich sowas auch an jeden der 20 Wege getaggt, aber ich stelle mir gerade die Frage, ob es besser ist, das an 20 Wegen zu pflegen oder einmal an einer Stelle.
Grundsätzlich ja, wobei es hier meherer Gartensparten mit unterschiedlichen Regelungen sind und das Auswählen der jeweiligen zugehörigen Wege schon Aufmerksamkeit verlangen.
Ändert das sich denn so häufig? Über welchen Zeitraum sprechen wir? 1x/Jahr, alle paar Jahre oder wöchentlich?
Eine Relation kann zwar einfacher gepflegt werden, heißt aber auch: Jeder muss wissen, dass es sie gibt, sonst trägt der nächste Mapper die Daten am Weg ein (“fehlen ja”).
Obwohl ich gerne Relationen verwende, sehe ich hier keinen Vorteil. Die Mitglieder müssen genauso erst einmal alle richtig eingepflegt und gewartet werden und das zerlegen der Merkmale macht es nicht übersichtlicher. Klingt für mich schon ein wenig nach Sammelrelation.
Mit entsprechender Suche oder Filter sollte es doch kein Problem sein, die Tags zu setzten und zu kontrollieren.
Also ich verstehe eure Antworten so, dass man das lieber überall dran taggt und beim Aktualisieren dann aufpasst, also Nachteile der Relation überwiegen die Vorteile. Danke, ich werde das jetz so machen.
Trotzdem wäre es für mich spannend, ob und wie man das in anderen Fällen das macht oder ist das immer unsinnig?
Nu eine Alternative ist ja, das was dafür sorgt das die Wege nur zu bestimmten Zeiten offen sind, zu taggen. Also die Schranke oder Tor oder Schild.
Dopplung von Informationen an jeden dahinterliegenden Weg ist auch keine sehr logische Lösung. Dopplung der Informationen an das Wegstück auf dem die Barriere liegt, macht ja vielleicht noch Sinn.
Ansonsten wird’s ziemlich unübersichtlich- weil Du dann in jedem Zoo, in vielen Friedhöfen und Parks die Information an jeden einzelnen Weg pappen musst.
Nu und kann man zu dem Weg nicht hin, ist er ja automatisch gesperrt.
Zum Beispiel haben ja auch viele Autobahnparkplätze Fusswege, Toiletten, Mülleimer, Bänke etc - und einen Zaun drumrum, so dass man defakto nur mit dem KFZ anreisen kann (dass die Autobahn befahren kann). Bevor wir jetzt ein Access-Tag für “nur für im KFZ transportierte Personen” erfinden und an jedes einzelne Objekt pappen, macht es doch Sinn, sich auf den Zusammenhang zu verlassen…
Kurze Antwort: Nein. Kein Router würde so eine Relation erkennen und auswerten.
Und nochmal nein, weil dieses Verfahren den Datenbestand gänzlich uneditierbar machen würde. Das Fachwort dafür in der Datenbanktechnik lautet “Normalisierung”, will heißen es hängen keine Attribute mehr direkt am Objekt, sondern die Beziehung zwischen Attributen und Objekten wird über ein weiteres Dingsbums - in dem Fall die Relation - hergestellt. Wenn man das einmal anfängt normale Attribute in Relationen auszulagern, kann man das natürlich für jedes Attribut machen. Der Name einer Straße oder das Maxspeed bleiben ja auch über mehrere Wegabschnitte gleich usw usf. Das müßte natürlich jeder Editor unterstützen und diese Relations-Attribute alle finden und darstellen, sonst herrscht totales Chaos weil sie massenhaft übersehen, doppelt eingetragen oder bei Updates vergessen werden. Und man kann natürlich weiterhin Attribute direkt an die Objekte taggen und mehrere Relationen mit demselben Attribut erzeugen, dann ist völlig unklar welches eigentlich gilt. Als Nebeneffekt wird auch die Änderungshistorie des Objektes nutzlos, weil man Änderung an Attributen in Relationen natürlich dort nicht sieht…
Also kurz zusammengefaßt: Für ein Crowdsourcing Projekt ohne verpflichtend vorgeschriebenen Editor und Datenstrukturen eine extrem schlechte Idee. Barocke Multipolygone sind schon schlimm genug.
