Also mit der Breitendefinition und dem Quatsch finde ich mich (ausgenommen streckenkundler) missverstanden. Meiner Meinung nach muss viel viel deutlicher herausgestellt werden, dass die Breite nur einer und auch nur ein sehr vager Anhaltspunkt. Das muss mindestens ebenso deutlich formuliert sein, wie man es bei den highway-Klassen gemacht hat. Es gibt zu viele Mapperkollegen, die nicht so genau lesen und die “Überspringen”-Regel viel zu eng auslegen. Es wurde hier mehrfach dargelegt, dass das so nicht funktionieren kann. Oftmals braucht es lokales Wissen, was noch Bach ist und was schon Fluss.
Wie an anderer Stelle schon geschrieben ist es bei ditch/drain ähnlich. Auch hier wird auf die Breite abgestellt. Auf dem Zingst sind aber viele Entwässerungsgräben deutlich breiter, als dass man sie noch überspringen könnte. Das liegt aber an dem feinsandigen Boden und dem hohen Grundwasserstand.
Am Rande, weil es mir gerade heute aufgefallen ist. Bei waterway=canal gibt es zwischen der englischen und der deutschen Wiki-Version gravierende inhaltliche Unterschiede:
wiki_en: Use waterway=canal for man-made open flow (free flow vs pipe flow) waterways used to carry useful water for transportation, hydro-power generation or irrigation purposes. (dieser erste Satz ist von Beginn an nahezu unverändert)
wiki_de: Als Kanal bezeichnet man einen schiffbaren Wasserlauf mit künstlich hergestelltem Gewässerbett oder die größte Klasse von künstlichen Fließgewässern.
Ob etwas ein Kanal ist, hat doch mit der Schiffbarkeit nichts zu tun!
und weiter: Für kleinere künstliche Wasserwege benutze waterway=drain (zur End- und Versorgung von bspw. Industrieanlagen mit Wasser)
was wohl dazu führt, dass sogar Mühlkanäle als drain gemappt werden (https://www.openstreetmap.org/way/579362784). Das widerspricht bereits dem deutschen Hauptartikel zu drain.
zugegeben, im feuchten Flachland sind unsere Unterscheidungen hinsichtlich überspringbarkeit weniger hilfreich, weil die Wasserwege da dicht an dicht sind, alles irgendwie feucht ist auch an Land, und kaum Fließgeschwindigkeit und z.T. geringe Wassertiefen da sind. Dadurch wird aber nicht das komplette Fließgewässer tagging weltweit obsolet, es gibt auch sehr viele Orte wo es problemlos funktioniert
@streckenkundler: Vielen Dank für die Erläuterungen zum ‘No Sport’ Problem.
Gut, ich habe gelernt, Gewässerklassifizierungen haben es in sich. Belassen wir es dabei.
Als Änderungswünsche für BRouter nehme ich mit
canoe=yes/no
whitewater=portage_way
Das reicht mir erstmal für meine Arbeit mit BRouter.
Ich habe schon Tests dazu gemacht. Und hier kam man den Weg über die Rolle sehen und die Alternative durch die Schleuse.
Auch das Routing durch einen waterway=stream ist zu sehen. (Die Notiz habe ich gesehen, aber es ist kein oneway definiert.)
Das bringt mich zu einem letzten Einwurf
Routing über ein Wehr
Routing bedeutet für mich nicht nur das Malen einer Strecke, es ist auch eine Zeitfrage.
Wenn ein Wehr entsprechend getaggt ist (node: waterway=weir auf dem waterway=*) und das Profil es vorsieht, erhält die Route eine ‘Zeitstrafe’ für das Rausnehmen/Umtragen/Einsetzen.
Das arbeitet gut bei Wehren, bei denen keine Umgehung definiert ist oder diese nicht angebunden ist.
Wenn dann eine Umgehung angebunden wird, reicht ein boat=no am Knoten, um die ‘Umwege’ zu routen - oder auch ein besseres Zeitverhalten für den Landweg.
Beispiel am Bürgerfliess
Es gibt einen Tag für das Wehr auf der Karte (way), aber keinen Node am Wasserweg. BRouter und routino tun garnichts und gehen drüberweg.
Wenn man den einfügt, geht es. Alles andere ist ja schon vorhanden.
Nun, was Wehre und Schleusen hier im Spreewald anbelangt ist eine Überarbeitung/ Ergänzung dringend nötig. Zum Zeitpunkt meiner und der Erfassung anderer, hatten wir nur Bing und Mapbox und Qualität war nicht berauschend… Erst mit den Luftbildern des LGB ist eine bedeutend bessere Qualität verfügbar. Ich habe am Wochenende erst wieder eine nicht erfasste Schleuse gesehen… Teilweise liegen die access-Tags auch am falschen Way.
Was deine Beispiele Bräsemannschleuse und Bürgerfließ anbelagt: Bürgerfließ: Access-Tags am falschen way. Bei Bräsemannschleuse kann es sogar so sein, daß durch die Schleuse canoe=no sei müsste, so daß canoe nur über die Bootsrolle gehen darf. Da muß man sich aber die Ausschilderung vor Ort anschauen. In stark fequentierten Bereichen wo es Bootsrollen und zugleich Schleusenkammern gibt, sollen die Kanu-Fahrer die Bootsrollen nehmen, da jeder Schleusenvorgang Wasserverlust bedeutet. Vor allen in den letzten Jahren war das deshalb wassermäßig ganz schön kritisch.
Bei waterway=stream hab’ ich bisschen Bedenken wegen dem Volumen. Sind zwar “nur” 15 Mio gemessen an 200 Mio highway=*, aber bei der Zahl der Nodes ist das Verhälntnis vielleicht ungünstiger. Ich müsste waterway=stream also evt. zuzätzlich filtern bzgl. der Existenz weiterer Tags, die auf eine Befahrbarkeit hindeuten.
Was ist mit Routing über den Rand von Wasserflächen (natural=water) ? Auch hier evtl. ein Volumenproblem und ausserdem sind viele davon wohl auch Multipoligone, und das kann BRouter nicht. Kann man also davon ausgehen, dass bei einem “richtigen” Tagging befahrbare Wasserflächen auch immer waterways drin haben?
Was BRouter auch nicht kann, ist die Blockade durch ein Wehr anhand einen kreuzenden Ways waterway=weir zu erkennen. Aber das hast Du ja auch selbst beschrieben, dass man hier einen node des Fahrweges mit waterway=weir braucht.
Ich mache da gerne eine Erweiterung der lookup.dat (und der “all.brf” )
Sollte aber kein Schnellschuss sein. Gibt mittlerweile 3 Anwender der lookup.dat zur Datenerzeugung (brouter.de, bikerouter.de, LocusMaps) und es wäre schade wenn das divergiert.
Pah… da sind wir wieder beim konkurierendem Tagging… Och nö…
Ich hab mal geschaut… wenn whitewater=portage_way ausgewertet werden soll, muß zugleich auch leisure=slipway + slipway:type=* ausgewertet werden. Hier speziell im Sinne der Fragestellung sehe ich slipway:type=manually (evt. auch cable winch) als gleichbedeutend zu whitewater an. Es kann aber nicht sichergestellt werden, daß stets beides gesetzt ist…
sehe ich auch so… ein node ist hier unerläßlich. Ich denke mir hier im Spreewald mal eine Overpass-Abfrage aus, die Stellen darstellt, die keine entsprechende weir-node haben…und ergänze die dann…Ich sehe keinen Widerspruch un der Erfassung, da es unterschiedliche Datennutzungsebenen sind…
Achtung für die Mitlesenden: Ich habe in dieser Diskussion gelernt, dass ‘waterway=drain’ keine Drainage-Gräben zum Trockenlegen von feuchten Wiesen und Wäldern sind sondern betonierte/gemauerte offene Abwasserkanäle. Ich vermute dazu ein Übersetzungsfehler im Wiki, “drain water” kann man laut leo.org sowohl mit “Trockenlegungs-Gewasser/Drainage” (hier falsch) auch mit “Abwasser” übersetzen (hier richtig).
Also ist die Breite gar nicht relevant zur Unterscheidung von ‘waterway=drain/ditch’ sondern die Befestigung und der Zweck des künstlichen Gewässers.
(dazu ggf. bitte im anderen Thread weiterdiskutieren: drain vs. ditch)
Ja, genau das meinte ich.
Additiv wäre für mich natürlich am besten.
Ich bereite gerade einen lookup.dat Erweiterungsvorschlag vor und stelle ihn zur Diskussion.
Allerdings dachte ich an ein neues Issue. Im alten geht es auch um das Nutzen von variablen Werten (width=*), das würde für den Anfang vielleicht etwas weit führen. Aber im Prinzip gern.
Für den allerersten Anfang würde ein Eintrag in ‘all.brf’ reichen
switch boat=yes 1
Das würde nur die Bäche anziehen, die benötigt werden.
switch not water= 1
wäre schön, aber das sind mir zu viele Daten (10Mio ways). Vielleicht geht ja Reduzierung durch canoe|boat|motorboat|sailboat = yes
Aber da habe ich noch nicht weiter geforscht.
Ein Ansatz für das Gewässerrouting auf einem See könnte hier enthalten sein. Abschnitt: Sonderfall See
Ich finde die Definition super … bei tiefen Bächen muss man zwangsläufig mit einem Sprung drüber (also so 2-4+ Meter, je nach Fitness), an den flachen/breiten Stellen gilt auch der Dreisprung … damit kommt man dann schon ziemlich weit, im besten Fall so an die 15-18 Meter .
die Definition setzt durchaus an einem relevanten Punkt an, aber mit nur 2 Klassen ist man zwar nach unten versorgt für alles was übersprungen werden kann, aber dann hat man alles von 2m aufwärts in einer Klasse, obwohl es da sicherlich Unterschiede gibt die ebenfalls noch nützlich wären um zu entscheiden was man wann z.B. darstellt, ohne dass man kompliziertere Analysen anstellen muss. Im Ergebnis werden Flüsse meistens eher spät visualisiert und man verlässt sich auf die separat gemappten Wasserflächen bei größeren Flüssen.
Mal ein paar Worte zum Spreewaldrouting.
Ich bin in der glücklichen Lage, in der Nähe zu wohnen und bereits viele Rad- und Paddeltouren im Spreewald gemacht zu haben.
Erst einmal ein Lob: Die Spreewaldfließe sind super ausgeschildert - erst im vorigen Jahr gesehen. Sicher auch Dank der Arbeit von Sven.
Beim Routing hatte ich doch eine Menge Arbeit. Erstens nutze ich Komoot (mit Brouter bin ich nicht warm geworden), Komoot und so ziemlich alle Router bieten nicht das Routen auf Gewässern an. Wenn doch: WELCHE? Also lud ich mir eine Spreewaldwasserwanderkarte herunter - im Nachhinein erkannt war die auch ziemlich genau. Letztendlich taten die Karten und Hinweise des Kajakvermieters (keine Namen) ein übriges. Wie plante ich also: In Komoot erstellte ich eine Route mit Deaktivierung der Zusätze “Wegen folgen”. Das ist zwar eine riesen Arbeit aber verpaddeln wollte ich mich auch nicht. Übrigens hinter Lehde ist man sehr einsam - zum Glück - aber man hätte auch niemanden fragen können. Dass die Fließe so gut ausgeschildert waren, bin ich ja von den Wanderwegen nicht gewohnt.
Ansonsten kann ich den Argumentationen von Sven aus Erfahrung folgen.
.