[Talk-de] Braucht es gemappte Flusseinzugsgebiete?

Werner Hoch werner.ho at gmx.de
Di Aug 28 17:41:35 UTC 2012


Am Dienstag, den 28.08.2012, 01:42 +0200 schrieb Stephan Wolff:
> Am 27.08.2012 17:11, schrieb Werner Hoch:
> > Hier müsste man nur die Wasserflächen mit auswerten. Ein See hat nunmal
> > meist mehrere Zuflüsse und ein Abfluss. Die Auswertung wird zwar ein
> > bischen komplizierter, aber es ist nicht unmöglich. Ein virtueller
> > Zusammenfluss in einem See vereinfacht natürlich die Auswertung.
> 
> Ein durchgehender virtueller Fluss vereinfacht die Zuordnung deutlich,
> insbesondere wenn mehrere Seen aneinandergrenzen (siehe 5-Seen-Fahrt)
> oder ein See mehrere Ausflüsse hat.
> Man müsste aber virtuelle Flüsse durch ein Zusatztag von normalen
> Flussstrecken unterscheiden.
> 
> >> Bei Kanälen muss man unterscheiden, ob es eine eindeutige Richtung
> >> des Wassers gibt.
> >
> > Das lässt sich mit geeignetem Tagging erledigen.
> 
> Hast du einen Vorschlag dafür? Bei Kanälen mit mehreren Schleusen
> muss man berücksichtigen, dass die Scheitelstrecke zu beiden
> Seiten, die anderen Teilstrecken nur zu einer Seite entwässern.

Wenn der Fluss immer in eine Richtung fließt dann ist die Way-Richtung
ja schon vorgegeben.

Ansonsten ein oneway=no, direction=both, ... 

> >> Eine Auswertung über waterway-Verbindungen ist keinesfalls trivial.
> >> Wenn wir Flusseinzugsgebiete aus den OSM-Daten ableiten wollen,
> >> erscheinen mir explizite Verbindungen über Relationen sinnvoller.
> >
> > Mir nicht. Selbst mit einer einfachen Auswertung (ohne Seen-Auswertung)
> > lassen sich die Einzugsgebiete größtenteils auswerten:
> >
> > http://www.h-renrew.de/h/osm/osmchecks/07_watershed/index.html
> 
> Die Auswertung sieht schon gut aus, aber es gibt auch einige Fehler.
> In Schleswig-Holstein sind mir folgende Probleme aufgefallen:
> bei Kanälen wird (willkürlich?) eine Flussrichtung angenommen.
> Der Oberlauf der Eider fließt in den Nord-Ostsee-Kanal, der Unterlauf
> aber in die Nordsee. Der Fehler betrifft auch alle Nebenflüsse der
> Untereider.

Bei diesem Spezialfall muss auch ein explizites Relationsmodel (bzw.
dessen Auswertung) einen Fallunterscheidung machen.
Die Darstellung als Baum (wie bei mir in der Übersicht) reicht dann
nicht mehr.

In der Detailauswertung sieht man auch, dass die Eider in den NO-Kanal
fliest und daraus gespeißt wird:

http://www.h-renrew.de/h/osm/osmchecks/07_watershed/de/407956.html

In der Baum-Darstellung ist der Fluss halt nur einmal aufgeführt, weil
ich eine Relation als zusammenhängendes Objekt (Graphen-Knoten)
betrachte.

> Das Wasser der Wakenitz fließt normalerweise durch den Dükerkanal und
> einen Düker unter der Kanal-Trave hindurch in die Trave, nur bei 
> Hochwasser in die Kanal-Trave. Den aktuellen OSM-Daten kann man diese
> Information nicht entnehmen.

Ein Relationsmodell für diesen Fall will ich erst mal sehen.

> Selbst deine "einfache Auswertung" enthält schon mehr Code, als für eine
> rekursive Relationsauswertung nötig wäre. Wieviel Rechenzeit braucht 
> denn ein Durchlauf?

ca. 12h für das planet file.
Kleine OSM-Gebiete z.B. Africa ca. 30 min.

> > Insgesamt erscheint mir der Aufwand der Auswertung sehr viel kleiner als
> > das manuelle Verknüpfen mittels Relationen.
> 
> Auch der Aufwand für explizite Verknüpfungen ist eher klein (ein Element
> pro Gewässer). Wichtiger ist aber die Frage, ob man ohne explizite
> Zuordnungen die Flusseinzugsgebiete korrekt berechnen kann.

Ich denke schon.

Die einzelnen Way-Segmente haben eine Fließrichtung und so können auch
komplexere Flusssystem noch besser ausgewertet werden. Das Problem ist
die Darstellung als Graph (hier ein DAG).
DAG = http://en.wikipedia.org/wiki/Directed_acyclic_graph

Grüße
Werner





Mehr Informationen über die Mailingliste Talk-de