flusssysteme im überblück

Chenshi · 2015-09-26 15:29:18

wie kann man sich mit weniger klicks ein ganzes flusssystem mit overpass turbo anzeigen lassen? oder müssten dazu alle waterway(-relationen) ein tag für das flusssystem erhalten?

https://de.wikipedia.org/wiki/Kategorie … stem_Hunte

Last edited by Chenshi (2015-09-26 15:30:06)

4rch · 2015-09-26 15:39:49

Chenshi wrote:

wie kann man sich mit weniger klicks ein ganzes flusssystem mit overpass turbo anzeigen lassen?

Ich glaube nicht, dass Overpass derartige Funktionalitäten bietet. Hier hat das jemand mal für die Mitteleuropäischen Flusssysteme gemacht: http://www.kompf.de/gps/rivermap.html

Chenshi wrote:

oder müssten dazu alle waterway(-relationen) ein tag für das flusssystem erhalten?

Nein, das ist überflüssig, da alle Wasserwege miteinander verbunden werden und somit die Zugehörigkeit zum jeweiligen Flusssystem klar ist.

mmd · 2015-09-26 16:00:04

Hallo,

das funktioniert noch nicht mit der offiziellen Overpass API, allerdings gibt es das Feature schon auf der Entwicklungsinstanz.

Hier mal ein Beispiel, das ausgehend vom Fluß selbst alle zufließenden Bäche automatisch per Query ermittelt.

Das GitHub Ticket dazu: https://github.com/drolbr/Overpass-API/issues/95

Gruß,
mmd

Chenshi · 2015-09-26 16:30:14

mit dem wizard kann ich es für direkt zufließende waterways ausführen "destination=Hunte".

da haben wir aber mal wieder grundsätzlich das problem. sachen in osm eintragen, kein große sache, aber die daten auf einfachem wege nutzen, riesen hindernis.

das muss so gehen: klick, klick, auswählen, auswählen, klick, export, fertige darstellung.

Last edited by Chenshi (2015-09-26 16:31:08)

mmd · 2015-09-26 16:41:01

Hallo,

ich hab mal ein Beispiel für den Fluß "Hunte" gebastelt, allerdings nur natural=water und waterway=stream/ditch weiterverfolgt. Das lässt sich sicherlich noch verfeinern: http://overpass-turbo.eu/s/bGo (experimentell, kann auch mal nicht verfügbar sein, dann einfach nochmal etwas später probieren).

Das mit "destiantion=Hunte" verstehe ich nicht so ganz, die Daten geben das heute nicht so wirklich her.

Gruß,
mmd

Chenshi · 2015-09-26 17:11:08

mmd wrote:

Das lässt sich sicherlich noch verfeinern.

mmd · 2015-09-26 17:32:19

Hallo,

gut das ist klar, mit der Bedingung wird einfach ein riesiges Gebiet angefordert. Die Logik verfolgt solange neue River/drain/stream/ditches, bis nichts neues mehr gefunden wird.

Hier ist es auf jeden Fall empfehlenswert, bestimmte Flüsse per Namen explizit ausschliessen oder zumindest die Suche mit [bbox:{{bbox}}] räumlich auf die aktuelle bbox einzuschränken.

Gruß,
mmd

Last edited by mmd (2015-09-26 17:35:49)

emga · 2015-09-26 17:39:40

Weis nicht ob es hilft aber hier in Österreich halber hydrologische Dienst ein nettes GIS bei dem man sich sowas sehr schön auch mit messstellen und Einzugsgebiet anzeigen lassen kann. Evt gibt es das in Deutschland auch

Chenshi · 2015-09-26 18:09:36

seit wann ist die weser mit der ems verbunden?

ich dachte der overpass code ist für alles vom eingefügten fluss und dann flussaufwärts. der ist jetzt runter gegangen und dann die weser wieder rauf.

mmd · 2015-09-26 18:17:20

Hallo,

ich denke, ich sollte vielleicht zunächst erklären, wofür complete ursprünglich gedacht war. @jotpe hatte vor längerer Zeit mal den Vorschlag gemacht, bei der OSM Nominatim Suche die komplette Strasse anzuzeigen, statt nur einen kleinen, zufällig ermittelten Ausschnitt. Dabei geht man immer von einer bestimmten Strasse aus und sucht von dort ausgehend alle weiteren Ways, die denselben Namen haben. Soviel zur Grundidee.

Zufällig macht sich complete auch ganz gut, zusammenhängende Flussabschnitte zu ermitteln, allerdings ohne ein flussaufwärts oder flussabwärts berücksichtigen zu können. Dafür ist complete einfach zu dumm.

Ohne Weser sieht das ganze dann so aus: http://overpass-turbo.eu/s/bGJ

Gruß,
mmd

Last edited by mmd (2015-09-26 18:22:24)

maxbe · 2015-09-26 18:20:09

Könnte man nicht diese Fliessgewässerkennzahl "ref:fgkz=*" abfragen? Die ist doch hierarchisch aufgebaut, soweit ich weiss. Allerdings weiss ich nicht, wie gut die gepflegt ist. Und ich glaube, Kanalbauten, die den Abfluss woanders hin leiten wurden da nicht berücksichtigt.

Für die grösseren Gebiete gäbs eine fertige Karte für ein paar rechte Donaunebenflüsse hätte ich was da. Das grösste Problem beim erstellen waren übrigens die Seen und die unterschiedlichen Arten, Gewässer zu verbinden (Fluss wird als Linie durch den See gezeichnet / Fluss berührt nur das Seeufer / Seeufer berührt Seeufer).

Grüße, Max

Chenshi · 2015-09-26 18:31:13

@mmd, ich bedanke mich. damit kann ich weiter arbeiten....

Basstoelpel · 2015-09-26 19:10:28

Ich meine mich zu erinnern, daß es mal ein QS tool gab, das auf Wasserläufe mit offenem Ende hinwies. Gibt es das noch?

Gruß, Baßtölpel

mmd · 2015-09-27 11:01:56

Basstoelpel wrote:

Ich meine mich zu erinnern, daß es mal ein QS tool gab, das auf Wasserläufe mit offenem Ende hinwies. Gibt es das noch?

Im genannten Ticket gibt's noch folgendes Beispiel für Bachabschnitte, die nicht von einem Fluß aus erreichbar sind:

Funktioniert analog auch für Eisenbahnen und andere Netzwerke.

derFred · 2015-10-10 14:29:31

Hallo mmd, *

mmd wrote:

Hallo,
das funktioniert noch nicht mit der offiziellen Overpass API, allerdings gibt es das Feature schon auf der Entwicklungsinstanz.
Hier mal ein Beispiel, das ausgehend vom Fluß selbst alle zufließenden Bäche automatisch per Query ermittelt.
https://cloud.githubusercontent.com/ass … 277814.png
Das GitHub Ticket dazu: https://github.com/drolbr/Overpass-API/issues/95
Gruß,
mmd

1. könnten das Geografielehrer sehr gut gebrauchen,
2. wie ich an dem Beispiel erkenne fehlt dort ein Zulauf ;-) ... also könnte es auch zur Qualitätssicherung genutzt werden,
3. ...

Wenn ich jetzt in github nachsehe, - https://github.com/drolbr/Overpass-API/issues/95 - dann gibt es dieses feature schon fast ein Jahr lang, ist aber noch nicht implementiert.

* Gibt es Gründe dafür, warum das Feature immer noch nicht zugänglich ist?
* Wie könnte man dieses Feature zugänglich machen?
* Dieses Feature könnte in der aktuellen Situation - Ausbruch des Vulkans Cotopaxi - bevorstehende Lahare*) - gut gebraucht werden.

Siehe WN vom 26. August: http://blog.openstreetmap.de/blog/2015/ … iz-nr-266/

derFred · 2015-10-13 10:19:54

zu dem Bildchen mal eine Frage:
Bei Küsnacht fließt der Dorfbach in den Zürichsee.
Der Dorfbach bei Erlenbach (direkt unterhalb) ebenfalls.

Fragen:
1. Warum ist der (a) Dorfbach bei Küsnacht mit dem dargestellten Durchfluss durch den Zürichsee verbunden, und (b) der Dorfbach von Erlenbach aber nicht?

2. Was ist richtig/sinnvoll (a) oder (b)?

geri-oc · 2015-10-13 10:43:03

Wenn der See ausgetrocknet ist wo fliest dann der Küsnachter Dorfbach?

Ich würde immer waterway an waterway - schon bei größeren wegen Routing.

derFred · 2015-10-13 16:15:49

ok, also muss der Erlenbacher Dorfbach auch verbunden werden. - Merci.

seichter · 2015-10-13 22:44:08

geri-oc wrote:

Ich würde immer waterway an waterway - schon bei größeren wegen Routing.

Wobei der waterway durch den See noch ein Stück künstlicher ist als ein highway quer über einen Platz.
Routing über Bäche ist auch nicht so gebräuchlich wie über Fußwege.
Für Flusssysteme macht es aber schon Sinn.
Ein Zusammenhang ließe sich aber zwanglos herstellen, wenn die Bäche/Flüsse mit der Begrenzung des Sees (natural=water & water=lake oder waterway=riverbank) verbunden würden und das auch ausgewertet würde.
Die Krücke mit der Zentrallinie waterway=river ist höchstens mit den begrenzten Fähigkeiten der Auswerte-Anwendungen zu rechtfertigen, für die wir ja mappen ...

Chrysopras · 2015-10-14 06:40:29

seichter wrote:

Wobei der waterway durch den See noch ein Stück künstlicher ist als ein highway quer über einen Platz.
Routing über Bäche ist auch nicht so gebräuchlich wie über Fußwege.
Für Flusssysteme macht es aber schon Sinn.
Ein Zusammenhang ließe sich aber zwanglos herstellen, wenn die Bäche/Flüsse mit der Begrenzung des Sees (natural=water & water=lake oder waterway=riverbank) verbunden würden und das auch ausgewertet würde.
Die Krücke mit der Zentrallinie waterway=river ist höchstens mit den begrenzten Fähigkeiten der Auswerte-Anwendungen zu rechtfertigen, für die wir ja mappen ...

+ 1. Ich habe allerlei waterway-Relationen angelegt und/oder gepflegt, aber dieser Punkt ist m.W. in der waterway-Beschreibung nicht geklärt. Das trägt zur erstaunlichen Vielfalt bei, wie mit der Situation "Wasserlauf durch See" umgegangen wird; richtet man sich nach der bisherigen Beschreibung von waterway-Relationen, so muss man entweder den waterway durch den See anlegen oder eine Lücke in der Relation lassen ...

Würde also (nach Deinem Vorschlag) einfach explizit erlaubt, Flächen mit natural=water (& water=lake oder =riverbank) als member in eine waterway-Relation aufzunehmen, so würde dieses Problem entfallen und die künstlichen "Durchflüsse" wären überflüssig. Dann wäre eben z.B. der Bodensee ein Teil des Rheins ... was auch sachlich nicht ganz falsch wäre.

Was wäre denn nötig, um zumindest die waterway-Relations-Def. entsprechend zu erweitern? Wenn Du ein Proposal etc. machst, werde ich gleich zustimmen.

--

EDIT: Na, da war ich wohl zu schnell. So ziemlich dieser Vorschlag steht ja bereits im Wiki unter Relation:waterway (englische Fassung, nicht in der deutschen), allerdings mit der Bemerkung: "Not approved, not frequently used and controversial". Offenbar eine neuere, aber eben noch umstrittene Erweiterung. Also müssen wir diesen Diskussionsteil dort fortführen...

... oder doch erst hier bzw. in einem neuen Thread, weil m.E. die Wiki-Diskussion zu Relation:waterway wieder einmal alles mögliche (generelle Editoren/Relations-Probleme etc.) behandelt. OK, Werner2101 ist gegen waterbodys in waterway-Relationen, und er ist m.W. mit der waterway-Experte, sodass seine Stimme meritokratisch gesehen großes Gewicht hat. Allerdings sprechen die meisten Argumente v.a. gegen eine Inklusion (aller) Riverbank-Elemente in die waterway-Relation. So etwas wäre natürlich tatsächlich aufwändig und wohl unnötig. Im Vergleich dazu erscheint mir die Zulassung der Aufnahme eines Sees, der von einem waterway durchflossen wird, in die zugehörige waterway-Relation als klarer und wohldefinierter ...

Last edited by Chrysopras (2015-10-14 07:07:20)

seichter · 2015-10-14 15:00:02

Chrysopras wrote:

Allerdings sprechen die meisten Argumente v.a. gegen eine Inklusion (aller) Riverbank-Elemente in die waterway-Relation. So etwas wäre natürlich tatsächlich aufwändig und wohl unnötig. Im Vergleich dazu erscheint mir die Zulassung der Aufnahme eines Sees, der von einem waterway durchflossen wird, in die zugehörige waterway-Relation als klarer und wohldefinierter ...

Flussflächen halte ich auch nicht für sinnvoll. Im Gegensatz zum See gibt es praktisch immer eine Hauptströmungslinie, wenn auch nicht immer trivial zu bestimmen. Bei einem See ist das eigentlich nie der Fall, ich betrachte das sogar als Hauptmerkmal zur Unterscheidung von Fließgewässern.

seawolff · 2015-10-14 16:53:10

Für viele Anwendungen ist eine Fortsetzung von Fließgewässern im See sinnvoll (amtliche Kilometerangaben, Längenmessungen, Berechnung von Gewässerbäumen).
Was für einen ein breiter Flussabschnitt ist, betrachtet ein anderer als schmalen See.
Eine einheitliche Erfassung mit einer (recht willkürlichen Mittel-) Linie erleichtert die Auswertung.
Manche Flussflächen sind nicht als "riverbank" sondern als "natural=water", "water=river" erstellt.

Vielleicht wäre es sinnvoll, die Anteile eines Flusses, die in einem See verlaufen mit einem Zusatztag zu kennzeichnen, damit man sie ggf. anders als sonstige Flussabschnitte auswerten kann (z.B. um den Flussnamen im See nicht zu rendern).

Chrysopras · 2015-10-14 19:00:15

seawolff wrote:

Vielleicht wäre es sinnvoll, die Anteile eines Flusses, die in einem See verlaufen mit einem Zusatztag zu kennzeichnen, damit man sie ggf. anders als sonstige Flussabschnitte auswerten kann (z.B. um den Flussnamen im See nicht zu rendern).

Das wäre natürlich auch eine gut Lösung, und sie würde sehr wenige Änderungen erfordern (keine Umdefinition/Erweiterung von waterway-Relationen etc.); und sogar wenn die Renderer sie nicht (sofort) umsetzen, würde die Darstellung zumindest nicht schlechter als bisher. Sympatisch.

OpenStreetMap Forum

#1 2015-09-26 15:29:18

flusssysteme im überblück

#2 2015-09-26 15:39:49

Re: flusssysteme im überblück

#3 2015-09-26 16:00:04

Re: flusssysteme im überblück

#4 2015-09-26 16:30:14

Re: flusssysteme im überblück

#5 2015-09-26 16:41:01

Re: flusssysteme im überblück

#6 2015-09-26 17:11:08

Re: flusssysteme im überblück

#7 2015-09-26 17:32:19

Re: flusssysteme im überblück

#8 2015-09-26 17:39:40

Re: flusssysteme im überblück

#9 2015-09-26 18:09:36

Re: flusssysteme im überblück

#10 2015-09-26 18:17:20

Re: flusssysteme im überblück

#11 2015-09-26 18:20:09

Re: flusssysteme im überblück

#12 2015-09-26 18:31:13

Re: flusssysteme im überblück

#13 2015-09-26 19:10:28

Re: flusssysteme im überblück

#14 2015-09-27 11:01:56

Re: flusssysteme im überblück

#15 2015-10-10 14:29:31

Re: flusssysteme im überblück

#16 2015-10-13 10:19:54

Re: flusssysteme im überblück

#17 2015-10-13 10:43:03

Re: flusssysteme im überblück

#18 2015-10-13 16:15:49

Re: flusssysteme im überblück

#19 2015-10-13 22:44:08

Re: flusssysteme im überblück

#20 2015-10-14 06:40:29

Re: flusssysteme im überblück

#21 2015-10-14 15:00:02

Re: flusssysteme im überblück

#22 2015-10-14 16:53:10

Re: flusssysteme im überblück

#23 2015-10-14 19:00:15

Re: flusssysteme im überblück

Board footer