At State of the Map 2019 the interesting talk “Is the OSM data model creaking?” described how the standard OSM appraoch can require some really weird mapping. Routing via large intersections was an example of where the OSM data doesn’t match how people would describe it.
Maybe this (“waterways through waterbodies”) is another example of how our data model is creek-ing?
Pretty sure that creek nor creak are ‘endorsed’ as waterway=* values ;P)
A new proposed tag, waterway=link, has been suggested for creating topological connections in the waterway network over the surface of a body of water.
The author discourages its use for connecting rivers and streams within a body of water, but I see no reason why it can’t be used in that way.
I must add that there are rivers which actually flow through water bodies for example the Colorado River flows through Lake Powell and in this case the tagging scheme remains the same (we use waterway=river throughout the lake).
https://wiki.openstreetmap.org/wiki/Proposal:Tag:waterway%3Dlink
From the beginning of this thread, exceptions have been recognized.
Regarding the tag suggestion, I think it sounds unnecessary, and will probably be a mostly unused tag. Its a tag that says “this way is a a river/stream in a waterbody” while being a river/stream in a waterbody. But it’s still a sub-tag, so regardless it will mean the waterway-way is mapped on the waterbody.
I think it is usedul to show that a river is effectively passing through a lake. It also gives the ability to communicate the actual path of flowing water. This is important as it often corresponds to a path that follows the deepest parts. Which is usually the safest path to follow. It would also be useful to many others as it indicates the lake’s natural water flow patterns.
I see this issue comparable to how sidewalks and other footpaths may have ‘synthetic’ connections to make it a true network - for routing -. Yet the physical reality is that they are unconnected. A creek flows into a lake. This lake may have a waterfall into another creek, with possibly another name. There is no physical creek or current within the lake. So I see it more like a helper for network-based algorithms than the geographical appearance. My take here is that network-based algorithms can best be enhanced by augmenting OSM data with such synthetic connections. If it is for boat routing, a boat can float over the entire lake.
IMHO we should not draw waterways where there aren’t. The lakes alone should be sufficient to indicate that waterways flowing into a lake and out of it, are related.
The lakes alone, without any waterways within them, don’t indicate which way the water flows. Not to mention the position of the main current, but that’s extremely difficult to verify so this specific is out of the formula, although I said it for completeness.
Sure it does. There are inputs and outputs… the water within the body enters one place and exits another. OSM does not (afaik) map water currents, nor would it be appropriate to use OSM to model fluid dynamics 
We’ve been through this about a hundred posts ago: If it’s a small body of water which is a slowed-and-widened part of a river, then a river centerline makes sense. But where is there a discernable river inside a huge lake?
Maybe it can be a river in a lake if water residency is such and such per this and that
Its a long post and I feel like I’ve said this before.
Lakes interrupt rivers. Sometimes the name of the river is the same before and after the lake, sometimes not. Either way, there is a physical river on both sides of a lake. If they have the same name on both sides - so be it, but they are physically not the same one (again, I’m only considering large lakes here).
I’ve challenged here before to show why it is important to map rivers across lakes. Afaik the only reason is “it looks neat”. Basically: map for a renderer, or at best for a router.
This type of thing has been suggested, but I suggest that the lake is the waterway_link.
So, in case the lake is part of the river, in terms of name, then in the corresponding relation contain the whole lake instead? I’m fine with that.
I would say so yes. I’m not sure what the consensus is but if a large river system is a relation, but it could make sense. I think in most cases it’s possible to judge the situations case by case.
I’ll just put some examples here by how I would judge them:
An OK case for river-through-lake: OpenStreetMap
Upper limit for possible river-centerline, but the two rivers have different names anyway: OpenStreetMap
Certainly no rivers through this lake: OpenStreetMap
I know this has been a long thread and suddenly rediscussing what is already told isn’t easy, but the suggestions you made here with the csses all make sense.
In small/medium lakes with one river passing through, but with different name of the lake, keep the waterway. Remove it if lake has the same name. (I would assume in a really small lake to keep it regardless, in the sense that it may not be actual lake as water level may look like that?)
In large lakes which are linear in the sense that waterways interesect at a central point (your second case), keep them.
In large lakes which aren’t linear and riverways join from several places (your third case), remove them (unless some of them intersect with each other nearly close when they join the lake maybe?)
I’m afraid that currently, no router is capable of utilizing natural=water as part of a waterway route, nor is it expected to do so in the near future. This is why we continue to map virtual, non-existent paths through walkable squares. I believe that the “waterway=link” should serve the same purpose as the forementioned paths.
I’ve been having a bit of a similar issue to this. I’ve been mapping wetlands with these large Supratidal saltflats. There are a lot of intermittent streams that basically just end at the landwards side of the saltflat. There are no signs of the waterway ever reaching the coastline. And due to the high rates of evaporation there, I don’t expect the waterway to ever reach the coastline except maybe in the case of exceptional rainfall. At most some of the water mixes with the seawater present on the saltflat, before they both evaporate together.
Currently there is no connection between the 2 systems and I’m unsure if there even should be one.
Houston Texas is working on that with I-10 West (Katy Freeway). I also encounter a similar problem mapping offroad tracks where MANY tracks diverge and run parallel. This is often a result of severe washboard (corrugation) on the track and it’s easy enough to just run parallel to the existing track on fresh ground since there are no constraints. It creates a wide routable area but trying to connect every one is tedious.
This has also been a topic regarding desert features such as dry washes and fluvial braidplains where they are narrowly constrained during low flow and broad features during high flow / floodstage.events.
So it’s literally mapping for the router . Why should routers bother evolving new technology if everything is pre-drawn for them by mappers? 
Which raises the question: why should we bother drawing highways and paths if a sufficiently advanced routing technology could deduce them from aerial imagery, Mapillary photos and Strava heatmap?
Because it is stratospherically hard.
Router authors are not sitting back eating caviar and quaffing Chateauneuf du Pape while the poor enslaved mappers toil away in the cartographical mines. Every major router has an open issue for routing across areas, dating back several years (OSRM #64, Graphhopper #82, Valhalla #3570). These issues link to research papers that consider various approaches to solving the problem.
I’m pretty sure every router maintainer would love to support it if someone wrote the code. Writing that code is not easy. I have looked into it for cycle.travel, which runs on a fork of OSRM. I would be very surprised if I could get even the most naive of implementations, coping with squares/plazas (which are much simpler than complex lake polygons), running within a full week of coding. Others are far better at C++ and algorithms than me, of course, but it really isn’t an easy thing to do.
You are, of course, very welcome to make things better by writing the code and sending a pull request to the router of your choice!
