Soll für jeden Fluss/Bach/Graben etc. grundsätzlich eine waterway-Relation angelegt werden? Auch wenn diese nur aus einer Linie besteht?
Z.B.: Relation: Alter Gohbach (14736394) | OpenStreetMap
Ich frage mich, warum wir bei Straßen keine Relationen verwenden, Flüsse und Bäche aber Relationen benötigen.
Auch Straßen haben Relationen: https://www.openstreetmap.org/relation/2166961
Ich denke, man kann das auch für Bäche machen, auch wenn es anfangs nicht sehr lohnt. Aber auch die werden eventuell mal aus mehreren Stücken bestehen.
Ein “muss” ist es bei einem kurzen Wasserlauf, der sich mit einem einfachen Linienzug darstellen lässt, sicher nicht, aber sobald das Bächle in mehrere Segmente unterteilt wird (z.B. durch culverts) macht es m.E. Sinn. Straßen gehören vielfach gleich mehreren Relationen an, z.B. einer Autobahn-Relation und einer Europastraßen-Relation.
Benötigen jedenfalls nicht. Man kann, muss aber nicht.
Bei Bächen und kürzeren Flüssen, auch wenn sie aus mehreren Stücken bestehen, halte ich Relationen für verzichtbar.
Bei Straßen macht man das ja auch höchstens bei klassifizierten Straßen, nicht bei Ortsstraßen, Zufahrtsstraßen und Feldwegen.
Sinnvoll bei längeren Flüssen, die u.U. unterwegs den Namen wechseln, Seitenarme haben und bei sonstigen Besonderheiten.
OK, wenn man an einen Fluss, der aus mehreren Elementen besteht, Daten wie wikipedia, wikidata etc. taggen möchte, dann macht eine Relation schon Sinn, damit man diese Tags nicht an jedes Teilstück taggen muss.
Aber wenn der Wasserlauf nur aus einem way besteht, sehe ich keinen Sinn darin.
An die Relationen der größeren Straßen habe ich tatsächlich gerade nicht gedacht. Aber wie seichter schon schrieb: Das ist ja nur ein Teil des Straßennetzes.
Nein - Relationen sind nicht zum sammeln von Objekten.
Das ist schon hunderte male besprochen worden. Auch die relationen von Bundesstraßen oder Autobahnen sind eigentlich ein Missbrauch von Relationen.
Relationen heissen Relationen weil sie English eine “Relation” oder Deutsch “Beziehung” von unterschiedlich artigen Objekten zueinander beschreiben.
D.h.
Es ist nicht dafür da alle Aldi Filialen oder alle Straßenschnipsel einer Bundesstraße zusammenzusetzen. Das geht über andere Methoden viel einfacher.
Und das Relationen von Flüssen einfach unnötiger Datenmüll und Pflegeaufwand ist sieht man an Karten wie die von Martin Kompf zu Mündungsdeltas Europäischer Flüsse. Für nix davon brauchte man eine Relation.
Flo
bei Flüssen ist es halt so, dass sie oft die Namen ändern wenn sie eine (Sprach-)Grenze überschreiten, und manchmal “gewinnt” an einem Zusammenfluss auch der kleinere Zufluss (z.B. weil man sich früher über die Mengen getäuscht hatte, d.h. es gibt auch kulturelle Faktoren und nicht nur physische, die bestimmen, was man als einen Fluss bezeichnet, ob es da bei unterschiedlichen Kulturen für denselben Fluss sogar verschiedene Einschätzungen gibt, weiß ich nicht, wäre aber interessant wie man dann die Alternativen mappen würde. Da waterway=river in OSM alles ist, wo man nicht mehr drüberspringen kann, würde sich daher beim Haupttag wenig ändern). Die Relationen sind hilfreich, damit man nicht weitere Attribute für den gesamten Fluss (wikidata z.B.) an alle Einzelteile taggen muss.
Relationen sind aber nicht dazu da, gemeinsame Eigenschaften “auszulagern”.
Anwendungen sollten sich schon darauf verlassen können, dass die Eigenschaften direkt am Objekt getaggt sind und nicht erst Relationen dazu geholt werden müssen.
Das läuft auf die (ur)alte Problematik hinaus, ob hier Redundanzen eher förderlich als hinderlich sind.
Eine Relation oder Beziehung können generell nicht nur Objekte unterschiedlicher Art zueinander haben, sondern auch gleichartige Objekte, wie z.B. Teilstücke einer Straße, die in einer direkten Beziehung zueinander stehen. In der Datenbank gibt es sicher eine Menge Datenmüll, aber ob man diese Relationen dazu rechnen will, ist m.E. Ansichtssache.
Ich hätte aber auch kein Problem damit, wenn es einen dokumentierten Konsens gäbe, der das Erfassen von Straßen- und Wasserlaufsegmenten in einer Relation als unerwünscht festhalten würde. Lasse mich da gerne von der korrekten Mappingstrategie überzeugen.
Wie sieht das denn Deiner Meinung nach bei Routenrelationen für Wander/Radrouten aus, in denen alle zu einer Route gehörenden Wegsegment und Objekte “gesammelt” werden?
Ich sehe eher das eine Abfrage “highway=primary && ref=B 64” halt viel einfacher ist als die relation aufzulösen. Also algorithmisch.
Dazu kommt das die einen machen die variante über die highway=primary && ref=B 64 die anderen über die relation und schwups kommen unterschiedliche Ergebnisse bei raus.
Typischerweise sind die relationen IMMER kaputt - Wenn man relationen nicht permanent überwacht und streichelt und validiert rotten die halt so vor sich hin weil das nicht offensichtlich ist was die relation macht.
Für den normal-mapper sind relationen nicht zu handhaben zeigen die letzten 10 Jahre.
Flo
Das trifft in manchen Fällen zu (Straßenabschnitte gehören für mich beispielsweise nicht in eine gemeinsame Relation), in anderen Fällen trifft es eher nicht zu. Klassische Gegenbeispiele wären hier Routen (Wandern, Fahrrad, ÖPNV etc.). Dort sind gemeinsame Eigenschaften “ausgelagert”.
Damit fangen die Probleme dann an.
Eine Bundesstraße muss nicht nur primary sein, sondern kann auch trunk oder, bei geringer Verkehrsbedeutung, auch secondary oder noch weniger.
…oder Knotenpunktnetzwerke… Hier möchte ich nicht drauf verzichten, da nur so (und mit dem entsprechenden Auswertetool) eine saubere Qualitätssicherung möglich ist…
Appropos Relationen für Wasserläufe… der geneigte interessierte Mapper kann ja mal bei Relationen vom type=waterway nach Elementen schauen, die z.B. die Rolle “tributary” haben und sich dann das ganze Geschachtel reinziehen…
Eine saubere Relation z.B. eines längeren Gewässerlaufes von Punkt A nach Punkt B ist hingegen z.B. für eine leichtere Datenpflege nicht verkehrt… Andere Dinge wurden bereits genannt.
Sven
Und der straßenbegleitende Fuß- und/oder Radweg gehört eigentlich auch noch dazu. Es fahren ja nicht nur Autos da lang.
Kann aber einfacher über den Ref zusammengesetzt werden.
Flo