Eigentlich braucht es ja nur ein geeignetes Wildwasser Schwierigkeitstag…
waterway=hazard → whitewater:rapid_grade=* oder whitewater:section_grade=* - https://wiki.openstreetmap.org/wiki/DE:WikiProject_Whitewater_Maps
Hier mal ein paar Beispiele:
https://commons.wikimedia.org/wiki/File:Sandbach,Sohlgleite_bei_Iffezheim(3).jpg
https://commons.wikimedia.org/wiki/File:Wupper_Wehr_Reuschenberger_Muehle.jpg
Bild von: Biber15, Lizenz: Creative Commons Attribution-Share Alike 4.0
https://commons.wikimedia.org/wiki/File:%C3%96sperm%C3%BCndung_Sohlgleite_2015.JPG
Weiter lesen…
Ich hatte ja das Attribut rock_ramp=yes vorgeschlagen.
Man kann natürlich “rock_ramp” als Linie (“längs”) als Teil des waterway=* ausklammern (als unzulässig erklären) und “rock_ramp” nur als Fläche und Punkt zulassen…
… das ist irgendwie ein völlig theoretische Diskussion. Im Moment gibt es gerade mal 18 Objekte (https://taginfo.openstreetmap.org/tags/waterway=rock_ramp). Und im ersten Schritt wäre es gut wenn es überhaupt eine Wiki-Seite gibt. Vielleicht sollten wir das jetzt einfach mal so stehen lassen.
Zur Verdeutlichung, was EinKonstanzer und Mammi71 meinen:
http://overpass-turbo.eu/s/1c5X
Es entsteht eine Lücke im waterway=river.
Vielleicht vergleichbar mit einer Autobahnbrücke. Die soll ja auch weiterhin highway=motorway bleiben und nicht highway=bridge.
Ach, jetzt sehe ich Deinen Beitrag erst. Sorry, den hatte ich übersehen.
Ok, jetzt verstehe ich. man_made=rock_ramp wäre dann noch denkbar.
+1
Sehr anschaulich demonstriert …
Ich weiß was RogerWilco uns sagen wird: Es sind doch alle Flußteile in einer Relation vorhanden. 
Diese Fluß-Sammelrelationen sehe ich kritisch. Diese sind eher ein Hilfskonstrukt für was auch immer. Der Fluß muß auch ohne sauber definiert sein.
Nein, das war eine normale Frage. Ich wusste den Grund wirklich nicht.
Ich habe etwas darüber nachgedacht. Einerseits kann ich das Argument nachvollziehen, da ein highway sich auch nicht ändert, wenn er über eine Brücke oder durch einen Tunnel verläuft, andererseits wechselt der highway-Wert auch, wenn sich der highway entsprechend ändert: Ein hw=track wird zu hw=path sobald mehrspurige Fahrzeuge den Weg nicht mehr befahren können.
Für mich ist aber eine Tagging-Variante auch in Ordnung.
Haben wir also waterway=rock_ramp für das Tagging als Punkt oder als Linie quer zur Mittellinie und rock_ramp=yes als Tagging auf die Mittellinie (waterway=river/…)
Das sehe ich als ergänzende Beschreibung, analog zu sac_scale, mtb:sacale, etc.
Richtig, sowas haben wir bei waterway auch. Die meisten fangen klein an als Bach und manche schaffen es bis zum Strom. Im Unterschied zur Straße sagt waterway aber nichts über den Verkehr aus, sondern eher über die Wassermenge. Also nicht Wasserweg sondern Wasserlauf. Folglich sollten in Mitteleuropa die meisten Wasserläufe einen Graphenbaum ergeben, mit einem bis zu ein paar dicken Stämmen als Auslauf und Übergängen/Wechsel der waterway-Werte nur in eine Richtung.
Kannst es ja mal versuchen. Der Rhein z.B. ist spannend mit Durchfluss durch einen größeren See (für manche sogar ein Meer), parallelem Kanal und Mündungsarmen mit eigenen Namen.
.jpg){kind=link}
Das ist ist mir jetzt eindeutig zu pauschal und platt. 
Es wäre halt schön, daß man das wofür man plädiert auch irgendwie begründen könnte!
Also, welche Gründe sprechen dafür?
Weißt du eigentlich wo Rhein-Kilometer 0 ist? Antwort: In einer Stadt am “Schwäbischen Meer”. Und rat mal was das mit meinem Benutzernamen zu tun hat… Aber danke für die Aufklärungsarbeit.
Du hast ja weiter oben (Beitrag #32) von einem Graphenbaum gesprochen. Dann verstehe ich nicht was du mit den Sammelrelationen möchtest.
Die Routen die Busse fahren haben direkt nichts mit der mit der Straße an sich zu tun. Dazu kommen noch Haltestellen, usw. …
Wir brauchen also Flußrelationen weil die Abschnitte vom Fluß nichts mit dem Fluß zu tun haben. Oder wie?
Nun wenn man einiges in OSM Erfasste im Detail betrachtet, könnte man eine ordentliche Liste aufmachen, was man als S…-Relationen ansehen kann… Ich hab aber lieber in Teilen solche Relationen um Objekte/ Objektegruppen einigermaßen strukturiert ansprechen zu können, als mit recht hohem Aufwand sich die Abschnitte versuchen zusammenzuslesen oder sich auch erst mal ein S-Relationsfreies Tagging zu überlegen…
Um beim Flußlauf zu bleiben… Ich hab dann lieber die Relation type=waterway mit den Elementen die direkt zum Flußlauf gehören… Wenn man sowas nicht hat, müsste man sich überlegen, welche waterway-Tags alles vorkommen könnten, um z.B. die Achse eines Flußlaufes abzufragen, wenn z.B. nun dieses watereay=rock_ramp verstärkt zum Einsatz käme (was ich durchaus verstehen würde). In wieweit dann auch andere Auswertungen/Tools beim Fehlen solcher Relationen betroffen wären, kann ich nicht einschätzen…
Ich sehe solche und vergleichbare Relationen in Maßen eingesetzt, als als notwendiges, ordnendes und strukturierendes Mittel, vor allem bei der Datenpflege und Editieren neuer und vorhandener Daten…
Sven
Kuck mal hier: https://www.openstreetmap.org/relation/10837595#map=12/51.3008/6.8695
Sieht doch nett aus. Auf einen Blick wird der gesamte Bach angezeigt.
Meinst du sowas?
Ich bin kurz davor die Relation zu löschen!
Um es mal knallhart zu auszudrücken: Wir mappen nicht für Router, nicht für Renderer, und auch nicht weill es nett auf osm.org aussieht.
Mit overpass bekommst du das gleiche Ergebnis: https://overpass-turbo.eu/s/1c8c
Informatik-Technisch: Würde man versuchen Gewässer auf Basis von OSM-Daten auszuwerten würde man das mit Graphen machen. Also von der Quelle bis zum Ziel die ganze Verästelung durchlaufen. Auf die Art bekommt man auch die Reihenfolge der Flußabschnitte richtig zusammen was über Sammelrelationen absolut nicht gegeben ist. Für die Fließrichtung braucht man auch keine Relation da sich diese aus der Richtung von Weg ergibt.
Argumtiert wird teilweise, daß man Relationen bei großen Flußsystemen braucht. Inzwischen wird jeder Bach in einer Sammel-Relation zusammengefaßt. Auch bei Flußsystemen mit mehreren Armen braucht es das technisch nicht.
Ja… Für mich ist das ein maßvoller Einsatz… Das stört nicht.
Deine overpass funktioniert aber nur, solange das Gewässer einen einheitlichen Namen hat… Die Ucker/Uecker https://www.openstreetmap.org/relation/409071hat in Brandenburg den Namen Ucker, in MeckPom den Namen Uecker!
Ob das ein Einzelfall ist, kann ich dir nicht sagen.
Ich hab hier im Spreewald sehr viele große und kleine Gewässer ich habe es beim laufenden Editieren, vor allem Schiffbarkeit/ Befahrbarkeit mit Kahn/ Paddelboot schätzen gelernt, solche Relationen zu haben. En Verzicht, wäre für mit eine Verschlechterung der Daten und der Editierbarkeit.
was z.B. kein maßvoller Einsatz war, waren diese Relationsmonster, die es mal einige Zeit gab, Stchwort Rolle tributary…https://overpass-turbo.eu/s/1c8f
Sven
Nein, ist es nicht. Darum habe ich ja auch oben nach dem Rhein gefragt.
Ich sehe da auch noch eine Referenz und ein wikidata Eintrag. Beide passen nicht wirklich als Tag an jedem Mitglied.
Auch wenn ich Dir Recht gebe, ist das kein gutes Argument, denn das gilt für fast jede Sammelrelation. Den Unterschied sehe ich eher dadurch, dass eine Relation hier einem Objekt entspricht, dem Wasserlauf, wie auch z.B. eine Autobahnrelation. Während eine Sammlung aller Berliner U-Bahn-Linien eben eine Sammlung ist und kein Objekt darstellt.
Richtig… Mindestens alle (Staats-)grenzüberschreitenden Flüsse sind irgendwie betroffen…
+1
Alle route-Master-Relationen im ÖPNV-Tagging wären in meinen Augen defakto Sammelrelationen und nein hier hab ich nichts dagegen… (ich mach nicht weiter, da hier OT)
Sven