Problem is also not the word I would choose. It just feels to me like it would be useful to introduce a new tag like waterway=link or waterway=virtual that is specifically meant for connecting waterways within very large water bodies. Some data consumers may wish to treat these just like any other waterway, others may wish to do something a bit different with them depending on their use case.
1 Like
Canals might be the easier case, as it’s already common to collect the canalways, however they’re tagged, in a route=waterway relation. But I wonder if this question hinges on the relative notability of the waterway versus the waterbody. The Panama Canal route runs continuously through Gatun Lake. A side channel, Banana Cut, is also tagged as a canal due to its connection to the canal system. I’ve only heard of the Panama Canal, so I wasn’t shocked to see the waterway=canal ways going through the lake.
A culvert can go under a lot of things, even just a spit of elevated land with no infrastructure on top.
2 Likes
That would be true for bridges, but culverts impact waterways more strongly than they impact the infrastructure or whatever else that is on top of them.
Pictures on Culvert - Wikipedia clearly show the variety of culverts. We often think of the more rudimentary one with a simple pipe for smaller rivers/streams. But even there, this is an infrastructure to let the highway pass over the waterway. Extreme weather with the climate change force to adapt these highway infrastructures. Otherwise, this is the highway that disappear, not the waterway.
I encountered a related issue, and @amapanda_ᚐᚋᚐᚅᚇᚐ shared this topic with me. Like a good number of people have suggested, I think updating the tagging is the solution. However, I don’t think waterway is the correct tag, since there’s literally not a river in a lake: these rivers-in-lakes exist only to facilitate hydrologic modeling/analysis. Perhaps modeling:waterway=river would work best.
The tag change would let renderers know the tagged geometry shouldn’t be displayed at all, preserving the “on the ground” rule, allowing the use of the name tag (avoiding the river name appearing in the middle of the lake), while preserving the network connectivity, without having to treat the lake perimeter as the connecting geometry.
1 Like
Does it need to be a key other than waterway=*? Judging from your post in the other thread, you seem to be concerned that renderers will blithely render any arbitrary waterway=* tag, but that doesn’t seem to be the case with any renderer I can find (other than the ones built into editors).
Also, I assume you’re only referring to the portions of the lake’s tributaries that extend into the lake artificially. By contrast, a river can logically flow through a reservoir, and the reservoir can be secondary to the river. But there might need to be a tagging distinction between a river that is digitized as artificial paths for rendering, those that go in a straight line for connectivity only, and those that are tagged more rigorously based on the thalweg or some other criterion.
1 Like
Oh we’ve crossed that bridge a long time ago. Dams, the big concrete things that literally block the flow of water) are are tagged as waterway=dam, and it’s not the only example of that.
2 Likes
On what observations do you base this ? Or do you simply say, litterally, a lake is not a river ?
And the big concrete things are still tagged as ways of water even if they’re areas or relations, and even if what they impound is usually air rather than water. (For example, one of the first dry dams in the world is mapped as an area.)
OSM English really is the best English!
3 Likes
So, again, why is it so important to connect all the waterways? Why is it important to draw rivers in lakes? You’ll have to excuse me but I think that certain RENDERING and certain ROUTING is why it comes across as important. But just to be OSM’y - I’ve never seen a river in a lake (we’ve been through the exceptions).
Statement: It isn’t important to connect the waterways… change my mind. 
1 Like
Your post in that thread pointing out that waterway=connector doesn’t render in many services leads me to retract my proposal of a key change: I think waterway=connector also works well with rivers-in-lakes.
I’m not sure there would be: all of these examples exist for modeling purposes, regardless of detail. As people have pointed out in this thread, NHD calls rivers-in-lakes “artificial paths” and non-specific water body connections “connectors”, but they’re all really the same thing.
I’ve since retracted the quoted proposal, but I don’t think the dam example should be an indication that waterway is acceptable, I think it’s evidence the dam key should be changed to man_made.
The river diffuses into the lake such that the water that was the river is indistinguishable from the lake, i.e. if you removed the lake there wouldn’t be a river beneath it. I based this off my formal education (geology, not fluid mechanics). If you’d like a source, the introduction to Chapter 2 of this PhD dissertation discusses the matter.
Are you sure that the counterexamples presented so far are so rare as to be mere exceptions? I don’t think it’s so outlandish that a major river would be impounded by a minor dam, forming a comparatively small reservoir. There are probably lots of cases like it.
If we allow the Colorado River to run continuously without any tagging changes, as common sense would seem to dictate, then we have to decide whether to also extend the lake’s other tributaries to meet the major waterway. From what I’ve read, Barton Creek and Waller Creek can be described as tributaries of either the Colorado River or Lady Bird Lake. Extending them to meet the Colorado River would seem more internally consistent, but maybe people don’t appreciate how openstreetmap-carto labels the segment that lies entirely inside the lake:
Eliminating these segments within the lake would avoid this situation. Then again, some other renderer has probably already figured out how to avoid labeling these segments so confusingly, probably using the same logic that it uses to omit a country’s maritime boundaries from the rendered map. From that perspective, I agree with this statement:
Just came across a couple of issues related to this topic:
- A lake with a river mapped through it, but the river segments a) did not have a node on the perimeter of the lake, nor were they split into riverine and lacustrine segments. If we are to map rivers through lakes I would suggest a minimum is to ensure that both of these are done. Yes, they can be derived, but it broke my current workflow quite a way downstream, as the straight skeleton does not include the outflow.
- Reservoirs with multiple inflows and outflows other than the obvious streams/rivers entering and spillways etc. The one I looked at was Rutland Water: its primary outflow is a pipe to a water treatment works, but this outflow is in the same place as two overflow outflows, and pumped inflows from other catchments. (Much more complex systems exist in the Swiss Alps, e.g.Zervreilasee system)). The original river, the Gwash, which flowed through the valley is mapped on OSM, but this scarcely reflects actual flows and anyway it’s marked as historic.
These suggest that there are additional mapping nuances which need to be handled if mapping lines though lakes and reservoirs. See my current attempts to create such lines by pruning straight skeletons.
2 Likes
I think dams are part of the exceptions. 
Rivers can sometimes bulge a bit and be better mapped as areas, and even become lake-ish, including dams, but there are clearly bodies of water that are not just a blobby river.
I think what @SK53 does is much more sensible than having users adding them to OSM. And of course, obviously, the waterway should connect to a node on the perimeter of the waterbody it enters (including the “riverbanks”).
And to build on examples from that area where he made the skeleton lakes. River Brathay goes into Lake Windemere, and River Level flows out of it at the bottom. There is no doubt that they are part of the same watershed, but you can’t convince me that there is a river in that lake. 
Also, the enormous work of adding millions of little streams and rivers through every waterbody, and connecting all the tributaries when SK53 has just shown us how it should be done programmatically. I don’t buy it. Data-driven waterskeletons ftw! 
Straight skeletons are such a handy tool (and Voronoi diagrams and visibility graphs by extension). Some other problems that they solve include routing pedestrians through an area (instead of relying on us to map the likely paths explicitly), associating an unaddressed house with its most likely street, and generalizing a dual carriageway as a single line for rendering at low zoom levels. Who knows, maybe someday we’ll even be able to deprecate highway centerline ways in favor of highway areas and road marking ways, letting renderers and routers figure out the rest.
So far, I’ve been under the impression that this kind of generalization is still aspirational due to performance limitations, or maybe it’s too exotic. In your experiments, have you gotten a sense of how feasible it would be to integrate this process into, say, incrementally updating vector tiles or a regularly updated routing graph?
1 Like
These are iterative, but the Lake District water bodies complete in around 9 iterations. The process is ultimately fairly simple: mark entrance & exit nodes on the decomposed straight skeleton, prune any lines with a dangling end not so marked, turn back to multilinestring, linemerge, node and then dump the lines; repeat until number of lines is not reduced. I think, as is, it could be a simple PostGIS function, with polygon and inlet/outlet node list as params. Not sure how performant at present, but the Lake District converges quite rapidly after first couple of steps. Using more steps (no linemerge. noding, assembly & disassembly) can be done iterating through a single set of data which may avoid some complications.
The issue I currently have is missing afferent and efferent nodes: some can be found by increasing complexity of initial queries, but others, such as Rutland Water require some standardisation in how these are mapped.
Thanks for the encouragement!
1 Like
For “group by name” view on WaterwayMap.org, I make longs linestring for each connected named river, which could be used for name labels at low zooms. Would you be interested in using something like that? (And what sort of datasource? A big GeoJSON (or GeoJSONSeq file?)
I think this would be generally useful, in the same manner that osm-lakelines has found its way into a variety of projects including OpenMapTiles. I suspect GeoJSONL or something along those lines would be the most convenient format; downstream projects can tile it up as necessary.
FYI WaterwayMap.org has gotten an new view which looks at natural=water areas. It can now detect (most) cases. My goal was to no longer need to map through water bodies now. Alas it only looks at ways, so multipolygon relations are ignored, so it doesn’t work very well. But it can detect tributaries not connected to riverbanks.
1 Like
Here is a waterway line I mapped last night. It is a connection through a wetland. Here is the latest aerial imagery:
There is no obvious main waterway visible going through it, and yet a stream flows in one end and out the other. I’ve tagged the waterway line as intermittent=yes to sort of suggest that it doesn’t represent the exact geometry of how the water flows. I’ve seen other mappers do this for streams through wetlands like this, but it doesn’t exactly feel right.
This is an interesting example I think because the “virtual/link/artificial” waterway line is visible in many map renderings due to the contrast with how the wetland is rendered. A “virtual/link/artificial” waterway line through a water body is generally not visible in most renderings due to using the same color or being rendered below the water area fill. At first I was thinking of lines through wetland areas and lines through water areas as separate situations perhaps warranting different tagging or mapping practices. After thinking about it a bit, though, I think they are essentially the same: water flows through an area, but the exact path it takes cannot be definitively represented by a line.
1 Like