See-MP mit komischen Rollen...

Fröhliche Weihnachten…

Was sind denn die Rollen “influent” und “tributary” in dem See-MP: http://osm.mapki.com/history/relation.php?id=216440

Meiner Meinung nach ist das Quatsch und dem unbedingten Willen geschuldet, alles zwangsweise in ein MP zu packen.

Ich habe Ersteller auch angeschrieben…

Nachtrag: Link: https://www.openstreetmap.org/changeset/65726963

Sven

Da bei Flüssen sowohl Abschnitte des Hauptstroms (main_stream) als auch Parallelarme (side_stream) als auch Zuflüsse (tributary) mit ihren Rollen angegeben werden, dachte ich, bei Seen wäre das auch richtig, wenn auch die Rollen noch nicht standardisiert sind.

Ich hätte die Zuflüsse natürlich auch ohne Rolle in das See-PM einbinden können, oder sie nur in die Relation des durchfließenden Fließgewässers einbinden können.

Gruß Ulrich

Die Fließgewässerabschnitte aber mit in die See-Relation aufzunehmen, halte ich für falsch. Ich bin auch dagegen, das aufzuweichen. Das See-MP ist zunächst ein rein geometrisches Objekt für Flächen, um die Inseln korrekt darzustellen. Dazu dann darin noch Gewässerkennzahlen, Zu- und Abflüsse in der Relation verbasteln zu wollen, halte ich für Falsch… Per Definition sind Gewässerkennzahlen auch im Zusammenhang von Fließgewässern zu Standgewässern hierarchisch aufgebaut und orientieren sich an Flußgebietseinheiten…

Sven

+1

Einfach mal die Doku lesen.

Wiki zu type=multipolygon:

Vielen Dank!

Dann heißt das also: Die Relation “See” umfasst nur dessen Uferlinien.
Der See, als Relation dargesetellt, darf Teil der Relation des hindurch fließenden oder abführenden Flusses sein, aber nicht umgekehrt.
Seine Zuflüsse sind in der Relationsverletziung tributaries dieses hindurch fließenden oder abführenden Flusses.

Frohes Fest!
Ulrich

Eigentlich heisst es “eine Relation vom type=multipolygon beschreibt nur die Fläche”. Das ist der einzige Zweck dieses Typs Relation, ganz unabhängig davon ob das ein See oder Wald oder ein Gebäude ist.

Vielleicht sind weitere Zutaten für Seen sinnvoll. Fall man das darstellen will, muss man sich aber was eigenes suchen (oder entwerfen, falls es noch nichts gibt) und den See als Mitglied dieser z.B. Relation (type=lake?) eintragen. Das hätte dann den Vorteil, dass es auch bei Seen funktioniert, die nur als Way gemappt sind.

Frohes Fest
Max

Hallo Chris,

Danke… Von der Sache her war es ja auch Klar!

Für weitere Auswertungen, die den See betreffen, sollten meiner Ansicht nach dann geometrische Auswertungen eines nachgeordneten Datenbestandes herhalten.

Dinge, wie

…kann man machen, man muß sich aber auch im Klaren sein, daß das ausgewertet werden kann und muß, ansonsten sind es unnütze tote Daten… Weniger ist manchmal mehr und mit der OSM-Datenbank nachgeordnete Datenbeständen kann mal viel mehr machen, als daß man es auf den ersten Blick der Daten meinen möchte…

Wenn es erst mal nur um die Erfassung der Gewässerkennzahl geht, muß man sich speziell auch hier Gedanken machen, wie man das mit der Auswertung händelt… OSM bietet ja z.B. die Möglichkeit Relationen mit type=waterway. Das ist erst mal ausreichend… Ansonsten fragt man alle erfassten Gewässer ab und gruppiert diese nach ihrer Gewässerkennzahl… Will man mehr, muß man sich zunächt Gedanken machen, was man bezwecken will… Gewässernetz? Routing? Flußgebietseinheiten? Für alles gibt es bereits Lösungen, auch ohne erfasste Gewässerkennzahl…

Im übrigen… in meinen Augen reicht eine Schreibweise aus: entweder: ref:gkz=9664 oder ref=GKZ:9664.( https://www.openstreetmap.org/relation/3126866 ) Letztere Variante halte ich für obsolet und Datenmüll.

Ansonsten grundsätzlich: https://de.wikipedia.org/wiki/Gew%C3%A4sserkennzahl_(Deutschland)

@ulamm: bitte bereinige das entsprechend, damit das geometrisch korrekt ist…

Sven

https://www.openstreetmap.org/changeset/65726963

Danke zusammen…

Sven

ob der See Teil eines ein- und ausfließenden Gewässers sein soll, ist auch nicht völlig klar, sofern das Fließgewässer durch den See durchgeführt wird (zeichnerisch als way), würde ich die Fläche dort nicht für sinnvoll erachten, bzw. höchstens mit spezifischer Rolle, sofern es eine entsprechende Definition gibt.

zu mindestens im Etablierten Tagging gibt es diese spezifischen Rollen nicht… Siehe Beitrag von Chris: #5. Das Aufnehmen von Gewässerabschnitten und die See-Relation mit spezifischen Rollen hatte ja korrekterweise zum MP-Fehler geführt…

In meinen Augen ist ein Erfassen der logischen Zusammenhänge in Gewässer-Relationen absolut unnötig (logische Zusammenhänge wie: ‘das Gewässer fließt in den See hinein, das Gewässer fließt hinaus’, ect.). Wichtig ist, daß die Zeichenrichtung eines Gewässers der Fließrichtung entsprechen sollte (sofern die Fließrichtung eindeutig bestimmbar ist; Es gibt Gewässer, wo das nicht eindeutig bestimmbar ist). Ansonsten fallen mir keine wesentlichen Dinge(*) ein, was, ein erweitertes Tagging nötig machen würde. Das betrifft auch spezifische Rollen in Fließgewässerrelationen…

Auswertungen der Flußgebietseinheiten wird gemacht: https://www.kompf.de/gps/rivermap.html
Routing funktioniert: http://routino.grade.de/visualiser.html?lat=53.37696;lon=12.22023;zoom=9

(*) Es gibt z.B. Netzwerkanalysen zur Verzeilung von Wassermengen, also um zu Ermitteln wie man eine Wassermenge, die in einem Gewässernetz auf der einen Seite reingeht, in einem Gebiet verteilen kann und wie sich das z.B. auf besiedelte Bereiche innerhalb des Gewässernetzwerkes auswirkt… in meinem heimatlichen Spreewald wird sowas gemacht erfordert aber andere Anforderungen an die Basis-Daten…

Sven