Benachbarte Flussufer verbinden?

Beim Speichern eines Segments kam eine Warnung, weil ein (von anderen) eingezeichnetes Flussufer-Band aus mehreren Teilen besteht. Sollten in diesem Fall die Uferteile zu einem Ufer verbunden werden oder ist es sinnvoll, sie getrennt zu lassen?

Hier der Link: http://www.openstreetmap.org/?lat=49.473996&lon=10.999058&zoom=18&layers=M

Etwa in der Mitte

Im Wiki http://wiki.openstreetmap.org/wiki/DE:Tag:waterway%3Driverbank wird riverbank als Fläche beschrieben. Da diese für Flüsse als einzelne Fläche zu ausgedehnt würde, wird in Abschnitte geteilt. Das ist zwar eigentlich nicht korrekt, da das Flussufer an den Segmentgrenzen jetzt quer durch den Fluss geht, aber es bleibt einem nichts anderes übrig, wenn man mit geschlossenen Flächen arbeitet (so wie es z.B. JOSM verlangt).

Sauberer wäre es, die einzelnen Uferabschnitte (nicht Flächen) per Relation zu verbinden, dafür gibt es auch ein Proposal, wird aber nur selten gemacht.

Ich habe mal die fragliche Segmentgrenze entfernt und etwas flussabwärts ans Wehr verlegt (das falsch als dam getaggt war), aber das passt nicht immer so gut. Im Normalfall würde ich an den riverbank-Segmenten nichts machen.
Die Warnung hatte übrigens ziemlich sicher nichts mit diesen riverbank-Flächen zu tun.

hey, danke dir seichter, jetzt versteh ich das Problem :slight_smile: Das mit den Flüssen ist also nicht trivial :wink:

Hi,

Man kann es auch so betrachten: Falsch ist nur die Bezeichnung Flußufer/Riverbank. Angegeben wird die Wasserfläche. Teilt man sie auf, dann grenzen eben Wasserflächen aneinander. Das hört sich doch viel besser an als “Das Flußufer geht quer durch den Fluss” :slight_smile:

Weide

gutes bild, wiede, damit kann ich was anfangen, danke dir :slight_smile:

So gesehen klingt “Flussflächen grenzen aneinander” schon viel besser. Der genutzte Name sowohl deutsch wie englisch ist aber weiterhin ziemlich irreführend, daran wird sich jedoch kaum noch etwas ändern.

Aber selbst in der Interpretation “Wasserfläche” ist das Aufteilen unschön: Niemand käme auf den Gedanken, einen Acker oder eine Wiese einfach mittendrin aufzuteilen, sondern würde dafür Wege oder zur Not erkennbare Nutzungsgrenzen verwenden. Beim Fluss gibt es halt den pragmatischen Grund, dass die Fläche einfach zu lang würde, um noch vernünftig behandelt werden zu können. Eine Interpretation als Uferlinie rechts/links würde nur die von “coastline” sattsam bekannten Probleme ins Binnenland exportieren, ist m.E. also auch keine erstrebenswerte Alternative.

Ich plädiere nur dafür, diese “Wassergrenzen” wenigstens soweit möglich an einigermaßen logischen (und unauffälligen) Stellen wie Stauwehr, Brücken oder Einmündung von Nebengewässern zu machen.

Hi,

ganz vergessen: es gibt auch noch eine alternative Formulierung:
natural=water zusammen mit water=river anstelle von waterway=riverbank.

frohes Mappen
Weide

Das nicht, aber bei ausgedehnten Wäldern muss man es auch. In Südschweden findet man grauenhafte Beispiele kaum noch verstehbarer Monster-Multipolygone und hier gibt es ja auch gerade einen Thread zu dem Thema.

Das sehe ich auch so.

frohes Mappen
Weide

OK, das vermeidet auf jeden Fall die Fehlinterpretation “Ufer” und bildet den Sachverhalt “Fläche” besser ab.
Wird zwar kaum verwendet, beißt sich aber nicht mit dem alten Tagging und jeder kann es verwenden, dem es logischer erscheint.

Aber auch hier mein Wunsch, die Flächengrenzen von natural=water nicht an x-beliebige und unnatürliche Stellen zu legen.

Die Probleme sind mir bekannt (daher habe ich auch Wald nicht als Beispiel genommen), selbst bei Seen kann man in Schweden und Finnland gezwungen sein, eigentlich ununterbrochene Wasserflächen aufzuteilen. Aber auch dort sollte man das an einigermaßen logischen Stellen wie Grenze des Fostbezirks machen. Aber da sind wir uns ja im Prinzip einig (s.u.).

@seichter:
+esse -sunt http://de.wikipedia.org/wiki/Accusativus_cum_infinitivo

zwar OT aber: auch bei Plural?

Einmal Infinitiv, immer Infinitiv.

Baßtölpel

Auch wenn es schon lange her ist mit dem großen Latrinum Latinum:
tibi assentior