Wasserlauf zusammenfügen: Relation oder alle Teile taggen?

Ich schließe mich Ukundji voll und ganz an.

Als ich den Reutibach, der durch meine Gemeinde fließt, überarbeitet habe, wollte ich ihn nach einer Suche auf osm.org auch “an einem Stück” sehen und nicht scheibchenweise !!! Folglich habe ich eine Relation angelegt.

@malenki: Ja ich habe auch schon eine residential durch eine Relation zusammengefaßt. :slight_smile:

Grüße aus Oberschwaben
Peter

Mit overpass turbo bekommt man sowas auch ohne Relation:

way["name"="Reutibach"];
out body;>; out skel qt;

http://overpass-turbo.eu/s/gYp

Das ist sicher ein sehr schönes Beispiel von Nutzung und Darstellung von OSM-Daten für den Endbenutzer. In der Tat: Mehr davon!
Gibt es aber für viele Flüsse/Bäche noch nicht, auch nicht für “meinen” Öschenbach.

Mit diesem Beispiel zeigst Du meiner Meinung nach, dass es ein sehr sinnvoll ist, auf einer Karte einen gesamten Flusslauf von der Quelle bis zur Mündung dargestellt zu bekommen. Mit einer Relation haben wir das direkt auf www.openstreetmap.org nach zwei Klicks.

Ok, zugegeben. Aber wenn die Teilstücke einzeln bleiben, dann muss es die Darstellung übernehmen, aus den Stücken ein Ganzes zu bilden. Renderer aller Arten machen so etwas, und oft gut. Aber mit einer Relation hab ich das schon beim Betrachten und Suchen und Betrachten auf der OSM-Seite.

Einspruch! Viele “normale Nutzer” finden etwas auf einer Karte und schauen es sich an, indem sie (z.B. auf Googlemaps) den Ort, Fluss, etc. als Wort eingeben und danach suchen. Wenn sie dann nur irgendwelche kurzen Bachstücke im Wald - eben nicht vor der Haustür - finden, dann sind sie verwirrt und ggf. genervt. Mir ist das jedenfalls so ergangen.

Zusatzargument 1: Die Waterways-Relation bietet zusätzlich zum Zusammenfügen der einzelnen “ways” eines Flusses auch noch die Möglichkeit Altarme und unbedeutende Zuflüsse als side stream einzubinden und die Quelle(n) (die ja Nodes sind) mit dem Fluss zu verbinden.

Zusatzargument 2: Außerdem kann man die vielen internationalen Namen eines größeren Flusses einmal bei der Relation sammeln und dann es dann bei den einzelnen “ways” bei einem Namen belassen.
Bsp. Blauer Nil http://www.openstreetmap.org/relation/1657491

doch: http://overpass-turbo.eu/s/gYt

Das in deinem Beispiel eine Relation angelegt wurde, ist ja möglich.
Trotzdem hast du einzelnen ways mit name=* belassen - also den Eigenschaften die dieser Abschnitt hat.

Macht es aber Sinn, name=, short_name=, … von den ways zu löschen und in die Relation zu übertragen? Ich komme als Neumapper und sehe, das der Anschnitt keinen name=* hat und trage ihn nach.

Dann kann ich auch eine unbezeichnete Linie in die Relation aufnehmen ist ja dann alles waterway=stream, name=*.
Desweiteren müssten dann in die Relationen der Wasserläufe die Quellen, Teiche, Talsperren, Bojen, Anlegestellen …

Ja, das ist ein sehr hilfreiches Tool! Wer das benutzt, hat mehr von den OSM-Daten!
Nur wer kennt und benutzt das - außer den “Kennern”? Ich bin zum ersten Mal nach zwei Jahren eigenem OSM-Mappen darüber “gestolpert”. Blöd! Aber ich befürchte eben, dass es viele von dieser Sorte OSM-Benutzer gibt und dass man direkt über die OSM-Seite den maximal möglichen Nutzen bieten und haben sollte.

[so, jetzt halte ich erstmal den Mund und warte, was die anderen so zu sagen haben ;-)]

@Ukundji:
Dein Zusatzargument 1 wurde bereits ohne Relationen gelöst: Siehe die weiter oben verlinkte rivermap.

@fx99: Das ist aber keine Lösung für den unschuldigen Otto-Normalmapper. :slight_smile:

Es gibt viele einfache Nutzer, die ihr Unternehmen in der Karte verzeichnet sehen möchten. Deshalb werden viele Daten umgebogen und ein Kopiershop als Supermarkt eingetragen. Aber ganz einfach einmal fragen …

Es gibt viele Möglichkeiten - ich bin selbst kein Programmierer - eher Software-Nutzer.
Und da ein Automat nicht abgebildet wird und es aber kein Bio-Laden oder Supermarkt konnte die Frage so gelöst werden:

http://umap.openstreetmap.fr/de/map/milchautomat-volkersdorf_90457#17/51.14847/13.73583

Es sollte doch beim Mappen einfach->detailliert->speziell->kompliziert aufgebaut sein. Und fragen hilft bei vielen - auch wenn es unterschiedliche Antworten gibt, kann man seine “Entscheidung” finden. (Siehe auch fx99)

So, nun meld ich mich doch gleich nochmal:

Ich möchte kurz noch zwei Zusatzargumente “hinterherschieben” und dafür auf die Beiträge von Werner2101 im Talk des WikiProject_Germany/Gewässer verweisen. Dort auch Hinweise auf ausführliche internationale Diskussionen zum Sinn und Zweck der Flussrelationen. Es geht um Flüsse mit verschiedenen Namen für verschiedene Abschnitte (das ist gar nicht so selten, auch innerhalb eines Landes) und um das Anbringen von diversen Tags an eine Relation.

Gleichzeitig möchte ich mich - auch wenn ich das ursprünglich für den “Öschenbach” gerne gehabt hatte - nach etwas Nachdenken über die gelesenen Argumente Werner2101 anschließen: Es braucht nicht jeder Bach eine eigene Relation.
http://wiki.openstreetmap.org/wiki/Talk:WikiProject_Germany/Gew%C3%A4sser

Hallo Zusammen,

Solange und sofern man nur einzelne Gewässerläufe hat, man man sicher auch ohne Relationen auskommen. Ich habe vor Jahren bei mit in Spreewald ziemlich regelmäßig Gewässerlauf-Relationen angelegt. Zunächst waren sie äußerst hilfreich, um zu ermitteln, ob das Gewässer Vollständig ist. Neuerlich hat sie sich auch als äußerst praktisch erwiesen, als “J budissin” name:dsb und name:hsb bei Gewässern nachgetragen hat. Nur zu Erinnerung, um welche Gewässerausdehnung ich rede: Hier ein Blick auf OSMI: http://tools.geofabrik.de/osmi/?view=water&lon=14.02463&lat=51.88795&zoom=12&overlays=waterways_drain,waterways_canal,waterways_stream,waterways_river. Nicht alle Gewässer stecken aber in Relationen bei waterway=ditch habe ich in der Regel (nicht immer) darauf verzichtet.

Natürlich ergeben sich einige wenige Redundanzen, da Infos an Way und Relation sind. Ich hab aber Lieber ein paar wenige Redundanzen und dafür aber ein vollständiges Gewässerbild.

Sven

Aber auch nur, wenn wirklich an allen Stücken der Name eingetragen ist.
Außerdem kann oder will nicht jeder Abfragen per Overpass durchführen, insbesonderen “Nur-Nutzer” der OSM-Karten. Oder wollt Ihr “Nur-Nutzer” von OSM ausschließen ?

Grüße
Peter

Für mich stellt sich die Frage, ob die Standard-OSM Suche links oben mit Nominatim durch Overpass-Wizzard zu ersetzen/ergänzen wäre.

Ich persönlich sehe bei Wasserläufen kein entweder Relation oder nicht, sondern wie bei Straßen ein sowohl als auch:
Es kommt kaum jemand auf die Idee, ein paar hundert Meter langes Residential als Relation zu erfassen, bei Bundesstraßen/Autobahnen ist das aber absolut die Regel.

Es gibt dazu ein Github-Ticket für die OSM Seite, um zumindest alle Teile einer Straße mit demselben Namen als Suchergebnis anzuzeigen (auch mit Lücken bis zu x Metern).

Link: https://github.com/openstreetmap/openstreetmap-website/issues/866

Erst eben fiel mir beim Abzeichnen eines langen Flusses wieder ein: Ein weiteres Argument gegen extrem lange Wege und große Relationen ist die mit der Länge und der Größe steigende Konfliktwahrscheinlichkeit. Ein Konflikt entsteht, wenn zwei Mapper das selbe Objekt bearbeiten und der zweite dann seine Bearbeitung hochlädt.
Es gab schon öfter den Fall, dass hier einer um Hilfe bat, weil er versehentlich (nach einem Konflikt) eine Relation aller ihrer Member beraubt hatte.

Wer in der Lage ist, Flussteilstücke in eine Relation zu packen kann auch Flussstücke zusammenflicken.
Was anderes ist, wenn den Fluss nicht nur als Linie sondern als Fläche taggen will, oder wenn es Wehre oder Staustufen gibt. Dann mag es sinnvoll sein, ddas alles in eine Relation zu packen.

Danke für die Info – Wehre, Staustufen, Fischtreppen und solcherlei Sachen gibt es bei dem nächsten Fluss, den ich mir vornehmen werde. Die Karwe hat zwar auch min. ein Wehr, von dem ich weiß, aber dafür werde ich dann einen Node des Flusses entsprechend taggen, denke ich.

Erstmal mache ich die Karwe fertig (indem ich die Teilstücke verbinde und komplett tagge, also ohne Relation [entsprechend der hier vorherrschenden Ansicht]); den aus Osten kommenden Teil kenne ich nicht persönlich, auf dem Luftbild sind bestimmte Details nicht erkennbar und ich werd’s mir vor Ort ansehen müssen.

Vielen Dank für die rege Beteiligung :slight_smile:

“Flussstücke zusammenflicken” soll bedeuten einzelne “ways” zu einem zusammenzufügen, oder? Das ist nicht notwendig und oft nicht sinnvoll. Und es ist bei mehr als 2000 Nodes (die man ja bei einem Fluss schnell beisammen hat) auch nicht möglich.

Bitte nicht die Wasserflächen (nature=water + water=river bzw. riverbanks) zu einer Relation zusammenfügen. Das ist nach der OSM-Wiki Beschreibung nicht der Sinn der Waterway-Relationen und schafft ggf. Probleme.

Die wichtigsten Vorteile von Waterway-Relationen sind meiner Meinung nach:

  1. Zusammenfügen von Flussabschnitten mit verschiedenen Namen
  2. Zusammenfügen den Flusses mit der Quelle und ggf. kleineren Zuläufen und Quellbächen
    (evt. auch von Wehren und/oder Staustufen)
  3. Gemeinsame, übersichtliche Darstellung bei einer Nomatim-Abfrage über www.openstreetmaps.com
  4. Ggf. bessere Auswertungsmöglichkeiten durch Anwendungen wie die
    von werner2101 unter http://www.h-renrew.de/h/osm/osmchecks/07_watershed/index.html vorgestellten

Ich habe mit zusammenflicken gemeint, unverbundene Flussfragmente zu verbinden.

Was mich betrifft, war’s von Anfang an der Plan, zusammenzufügen, was zusammengehört. Meine Frage bezog sich rein auf das Taggen: Einzelne (dann miteinander verbundene) Teilstücken mit jeweils dem vollständigen Satz Tags versehen (soweit „vollständig“ mir möglich ist), oder die Teilstücke nur mit dem Nötigsten ausstatten und die über den gesamten Fluss hinweg konstanten Sachen in eine Relation schreiben, was ja aus verarbeitungstechnischer Sicht durchaus Vorteile hätte: weniger Redundanz, weniger Speicherplatz, weniger aufwändige DB-Abfragen zum Holen des gesamten Flusses – aber aus Bearbeitersicht offensichtlich überwiegend negativ bewertet wird.

Doch genau deswegen habe ich ja gefragt, und entsprechend habe ich nun angefangen, es umzusetzen, insofern sind so Spitzen unnötig.

@TrackerJack:
Leider finde ich die Quelle nicht mehr, aber vor längerer Zeit hat mal jemand was zu den “Kosten” beim Verarbeiten von OSM-Daten (war es beim Import in eine DB?) geschrieben. Das sah ungefähr so aus:
100 nodes = 10 way = 1 relation

Wie kommst du auf “Weniger Speicherplatz”? Ich habe zwar von DBs keine Ahnung, aber ich bezweifle, dass alle Tags, die dem Mapper am Weg angezeigt werden, pro way in der DB separat gespeichert werden.
Vielleicht könnte uns jemand Berufenes erleuchten?