Riverbanks

Hallo,

auf der tagging-Mailing-Liste habe ich gefragt [1], wieso im Wiki [2] sowohl

waterway=riverbank

als auch (alternativ)

natural=water
water=river

als Schema für Flüsse verwendet werden kann.

Zuletzt kam der Hinweis, dass eine lokale Community sich dafür aussprechen könnte, das eine Schema vor dem anderen zu bevorzugen.

Daher möchte ich gerne die Diskussion führen: Möchten wir in Deutschland

waterway=riverbank

als Tagging-Schema bevorzugen?

Viele Grüße
dktue

[1] https://lists.openstreetmap.org/pipermail/tagging/2020-July/054089.html
[2] https://wiki.openstreetmap.org/wiki/Tag:waterway=riverbank

Was wird denn wie häufig genutzt? Und gibt es technisch gesehen Vor- und Nachteile?

Ich bevorzuge eindeutig natural=water + water=*

Hat auch einen einfachen Grund: nur mit natural=water + water=* ist es möglich den Gewässerlauf überhaupt zu strukturieren: water=river|oxbow|canal|… ist mit waterway=riverbank nicht möglich.

Wegen mir kann waterway=riverbank als veraltet gesetzt werden.

Sven

?

Geht es hier um den Flußlauf oder das Flußufer / Flußbett ?

Es geht um die Gewässerfläche.

Als Linie (man kann auch Mittelachse des Gewässers sagen) sind die Haupttypen waterway=river, waterway=canal oder waterway=stream, waterway=brook, waterway=drain sowie waterway=ditch.

waterway=riverbank ist hingegen für Flächen und Flächenrelationen.
Die Alternative und detailliertere Taggingweise ist natural=water + water=* Siehe: https://wiki.openstreetmap.org/wiki/DE:Key:water

Sven

https://taghistory.raifer.tech/#/waterway/riverbank&/water/river

waterway=riverbank gibt es seit mindestens 2007, water=river wurde 2011 “approved”, aber kaum genutzt.
Die meisten water=river sind erst im letzten Jahr ergänzt worden wegen der “Werbung” durch iD.

Ich nutze in den letzten Jahren zunehmend natural=water + water=river. Einfach weil es datenlogischer ist.
riverbank ist die Uferlinie, daher wäre waterway=riverbank in sich logisch, wenn man nur die Uferlinie mit einem way in OSM mappen und darstellen würde. Die Realität ist eine andere: es wird ein geschlossener way, also ein area gemappt mit der Konsequenz, dass an mindestens zwei Stellen eine Uferlinie gemappt ist, die quer durch den Fluss geht. Das ist unlogisch, eigentlich sogar falsch.
Genaugenommen mappt man keine Uferlinien, sondern die Wasserflächen. Genau dort hat das natural=water - Proposal angesetzt und ist für mich zwingend logisch.
Natürlich ist riverbank wesentlich älter und hat schon allein deshalb viel mehr Einträge in OSM. Und Umtaggen ist verpönt, solange es ein zulässiges Tag ist. Insoweit wäre ich auch dafür, es als veraltet zu markieren.

Das ganze stammt von dem 2011er Proposal “Water Details”:

https://wiki.openstreetmap.org/wiki/Proposed_features/Water_details

Für mich ist das ein bisschen wie Wege als Linien oder als Flächen zu mappen. Wir mappen ja Linien…
In gewisserweise heiß das die Logik (den Fluß als Linie) von der Darstellung (Fläche) zu trennen.
Ich finde das mit den flächen daher eher unpraktikabel.
Was ich aber gerne hätte, wäre die Flächen dennoch als waterway=riverbank zu taggen, da sie eben nicht ein x-beliebiges Stück stehendes Wasser sondern ein fließendes. Also das beste aus zwei Welten. wayerway=river + waterway=riverbank

Es gibt Tagging-Vorgaben für waterway-Flächen, die für andere Wasserflächen nicht gelten. Etwa, dass sie in regelmäßigen Abständen in Teilflächen zerlegt werden, oder dass sie eine waterway-Linie enthalten müssen.

So etwas ist m.E. einfacher zu dokumentieren, wenn diese Flächen ein eigenes Tag nutzen, als wenn ein Tag (wie natural=water) abhängig von einem Unter-Tag (water=*) unterschiedlichen Mapping-Regeln folgt.

Wenig überraschend ist der derzeitige Zustand der Dokumentation im Wiki für Tags wie water=canal auch ziemlich schlecht – die Aussagen dort widersprechen denen, die z.B. für water=river zu finden sind.

Von daher: Am liebsten wäre mir ein komplett eigenes Tag, aber da das unrealistisch ist, muss zumindest die m.E. deutlich bessere Dokumentation von waterway=riverbank zu den neueren Tags sowie natural=water und water=* hinübergerettet werden, wenn diese jetzt vorrangig benutzt werden sollen.

Letztendlich ist es für mich mit waterway=river im Vergleich zu waterway=riverbank vs. natural=water + water=river genauso wie mit highway=primary zu area:highway=primary.

Die Eigenschaft waterway=river repräsentiert für mich den Linienvektor fürs Routing und für eine vereinfachte Darstellung in kleinen Maßstäben, genauso wie im Vergleich dazu highway=primary.

Im Gegensatz dazu repräsentiert area:highway=primary die reale flächige Ausdehnung des Straßenobjekts für einen großen Maßstab, wie es auch waterway=riverbank vs. natural=water + water=river ist.

Ich sehe da nur das Problem, als daß man mit waterway=riverbank die Fläche des Gewässers nicht weiter unterteilen kann, im Gegensatz mit natural=water + water=* . Mit water=* kann ich festlegen, ist es river, ditch, oxbow, canal, oder was auch immer (Stichwort ‘Flußseen’, also seeartige Abschnitte eines Flusses, die durchaus als water=lake erfasst sein können/sollten…)

Für mich muß da auch nichts neu erfunden, es muß nur natural=water + water=* konsequent angewendet werden, ich sehr da keine Probleme, außer dem Willen.

Sven

PS: ich hab es hier der Einfachheit nur auf river/ primary beschränkt, es betrifft natürlich auch alle alle anderen, in OSM etablierten Straßen- und Gewässerkategorien.

Von Vorgaben fürs Zerlegen ist mir nichts bekannt außer den Empfehlungen im Wiki, die für riverbank tatsächlich deutlich ausführlicher sind als für water=river.

Ich ziehe natural=water & water=river dem Tagging mit waterway=riverbank vor.
Dass das letztere bei den Quer-Aufteilungen eigentlich logisch falsch ist, könnte man noch verschmerzen, aber ich kann mich erinnern, dass die waterway(=riverbank)-Linien gelegentlich in Konflikt mit anderen Linien kamen.
Dazu kommt noch das Abgrenzungsproblem von Flussaufweitungen zu Seen. Bei natural=water & water=river wechselt dann nur das Subtag.

Weiterer Vorteil von waterway=river ist die vereinfachte Längenberechnung für einen Fluß. Auch wenn das mit Flächen sicherlich auch irgendwie geht.

Ein Vorteil gegenüber was? Dir ist schon klar, dass natural=water + water=river nur das riverbank ersetzen kann, aber waterway=river trotzdem und weiterhin benötigt wird.

Ich würde in D auf riverbank verzichten.

Für mich ist riverbank Uferlinie, nicht Fläche. Man braucht dafür mindestens zwei Uferlinien.
In D zeichnen sich Flüsse aber überwiegend dadurch aus, parallele Ufer und eine relativ geringe Variabilität in der Breite über eine längere Strecke (bis zur nächsten Einmündung) aufzuweisen. Hier reicht überwiegend eine Linie - die der Wasserstraße entspricht.
Seen oder Neben- und Altarme können ebenfalls ohne riverbank beschrieben werden.

Uferlinien sehe ich eher dort als sinnvoll an, wo man im Grunde nur eine Uferlinie eines Flusses (Durchmesser hundert Meter bis mehrere Kilometer) beschreiben möchte. Die beiden Uferlinien können dabei sehr unterschiedlich lang ausfallen. Nutzung (Routing!) wäre beispielsweise der Spaziergang am Ufer oder das Abfahren der Uferlinie mit dem Kanu. Wasserstraßen müssten dort ohnehin gesondert eingetragen werden.

Für mich fühlt sich riverbank (als Polygon!) falsch an. Wie Mammi71 oben schon geschrieben hat: mindestens zwei Seiten queren den Fluss, ohne Ufer zu sein.