Should river lines be mapped through lakes, estuaries, gulfs, and other large water bodies?

Thanks for raising this issue @ezekielf – I followed the same train of thoughts as you and I was glad someone else started it first. :slight_smile:

I have mapped a lot of waterways and I’m among the ones who consistently “map linear waterway features through lakes” (usually omitting name and even “hiding” it using layer=-1). However, where I live those lakes are almost all dammed reservoirs, so it comes pretty natural.

I agree with andygol and R0bst3r that mapping virtual waterway through large water bodies constitutes a best practice, to facilitate routing through radial water networks and simplify the model for water-routing and QA applications (such as OSM River Basins). I just spotted a large unconnected basin off the south shore of Lake Balaton, but then I realized that someone has already created a virtual waterway there where those streams can connect.

I also agree that such virtual waterways should be simple linear ways roughly following the centerline of the waterbody. They should branch only if there are major gulfs or bays that collect a significant number of tributaries.

4 Likes

Can think of the conceptual tag of river/stream=link similar to mapping cycleway and footway=link sections to express it’s for routing across areas…

We have several reservoirs that fill up in late autumn/winter/melt season where the actual original path of the streams/rivers are ‘revealed’ at end of summer, Lago di Penne between high in spring and low end of summer, draining exclusively for irrigation is some summers 21 meters or more, a gauge on the sloped dam wall showing the state of affairs.

3 Likes

Wouldn’t waterway = lake/reservoir/bay/estuary be a natural choice? Actually, it’s probably a good thing that those won’t render under most of the current OSM stack.

(Btw, I wish there was waterway=oxbow to accompany water=oxbow… most oxbow lakes are actually long linear features. I know, “any tags you like”, but those are the ones I’d want to be rendered).

1 Like

The wiki for waterway=fairway might be worth a look
quote: Use waterway=fairway for a linear representation of a navigable route in a body of water such as a lake or sea, in cases where other values such as waterway=river… are not appropriate. Do not use instead of waterway=river…etc.
Seamark:type=fairway is also a possible addition. although they only have a few thousand uses between them.

yes, Tag:waterway=fairway - OpenStreetMap Wiki is quite common in terms of navigability.
Example: maplibre-gl-leaflet

1 Like

The same issue has been intensely discussed here not very long ago

Prolongue rivers flow inside big lakes

without a consensus, as far as I understand. Again there are a couple of topics dealing with the same problem in the german community. I am looking forward to the outcome here.

2 Likes

What I’m hearing so far is that folks do consider waterway lines through lakes to be a good practice, but perhaps tagging them differently from rivers or streams would be an improvement. The idea of virtual or link waterways makes sense to me. I also noticed waterway=fairway, but it seems to generally be indicated by man made markers of some kind. So a virtual line through a lake where there are no markers may not qualify.

Also it is a good point that reservoirs can be considered not an interruption of a river. A waterway=river line going through a reservoir make perfect sense because the reservoir would not exist if the river wasn’t dammed, and if/when the reservoir is drained the river will still be there. So I think reservoirs can be left out of the discussion about whether any different tagging would be good for other types of large water bodies.

It also seems like virtual waterway lines outside the natural=coastline in estuaries, gulfs, and bays are more questionable than those in large lakes.

2 Likes

At least some mapping of waterways outside natural=coastline makes sense.

Coastline in OSM follows mean high water springs, and for regions with significant tides, there are often substantial areas exposed at lower tides. It makes sense to map established channels for streams in those areas.

4 Likes

I don’t think this should be required, and we should document that it isn’t required.

It would be a massive amount of effort to do this for somewhere like the Great Lakes:

The only reason to map these “virtual” waterways is to make the rivers join up topologically, but it can be done without all this hassle. (In the simplest case, someone pointed out that you can just consider the lake as a “roundabout”.)

Adding waterways through larger lakes is just tagging for the renderer, and we shouldn’t be requiring it. In some situations it also means river names unexpectedly appear in the middle of lakes.

That said, I think there are some cases where mapping waterways within larger bodies of water is still useful:

  • Smaller lakes (and of course riverbanks), where it simply makes more sense to keep the linear waterway mapped.
  • Tidal/intermittent areas of water, where the route of the stream is sometimes visible when the water level is lower.
7 Likes

I support @Russ comment above.
l also support the two bulleted exceptions to the rule at the end of the post.

Mapping rivers over lakes does not seem to conform well with the “what’s on the ground (water)” rule. To draw virtual rivers over lakes can only have one purpose: Mapping for render/router. Routing should use line-of-sight routing across open areas and make use of seamarks data to improve routing.

If the river continues on the other side of a large lake I would expect there either to be identical tags or a relation.

The river-basin map should not rely on connected river-centerlines. The lake body should be included using inflow-outflow to calculate the river basin coverage.

1 Like

If we map a stream/river relation, does leaving out the lake sections not cause validators to act up with ‘you’ve got a gap’. If only consumers would be able to interpret the omnidirectional areas as part of the route we’d be done.

At any rate, as it is now got a reservoir that before it became one had 3 torrents converging in it and now the map show depending on the zoom all these names in the reservoir on top of the reservoir name. Fortunately the streams themselves don’t render in the standard issue else it would look a little perverted. It certainly would break in the present config Amanda’s river basin project showing the total tributary distances of watersheds like the sample below. Most of the 212km feeding the Tavo would be gone. Not ready for that yet.

image

1 Like

note that “should not be done for Great Lakes” does not mean that it should not be done and should not be required in general and “document that it isn’t required” should not imply this

“lakes smaller than Great Lakes” covers A LOT :slight_smile:

1 Like

I don’t think we necessarily need a solid rule here - we just need to make sure that people don’t rely on (or massively over-map) these “virtual waterways”. But a good rule of thumb might be:

If the same named river flows in and out of a lake, then it should continue through the lake (and other inflows should join it). Otherwise the inflows should terminate at the edge of the lake, or at the lowest water line if the level is variable.

1 Like

https://amandasaurus.github.io/osm-river-basins/#map=14.35/52.5754/19.52282 looks like counterexample to me (river joins another river, does not exit reservoir - similar would apply if that would be natural lake)

I think this works - my rule says this should be joined together. Maybe I didn’t explain clearly enough - because a river flows through that reservoir, it should be joined up. If the lake is the source of its outflow, then anything which flows into it should not be joined up.

(I’m sure there are lakes which have multiple outflows but that’s an uncommon edge case.)

1 Like

I previously floated the idea of mapping a channel through certain linear gulfs:

However, I didn’t consider the implication of also extending every inflow to meet this channel. I could see that being problematic, in that the majority of a very short stream could lie within the gulf, causing an unsophisticated renderer to place its label misleadingly inside the gulf.

As others have indicated, there’s a difference between a linear representation of an elongated body of water (which some renderers can generate automatically) and a waterway channel that happens to be submerged beneath the body of water (i.e., a dammed river through a reservoir). In the latter case, the thalweg is valuable additional information that renderers can use. The geometry is nonarbitrary and not quite the same thing as a waterway=fairway.

3 Likes

my european-waterway-router example takes care of waterway=fairway:
https://brouter.grade.de

To avoid the weird render label issue, you can always make a separate waterway= way without the name that is the connector way.

I’ve been continuing major named waterways (and cleaning up their relations) through water bodies but having the named portion of smaller side streams stop at the larger water= boundary. As many have noted, the lake/reservoir is there because of the river way. Alternatively, there’s still a river, it’s just covered by a lake!

1 Like

there’s still a river, it’s just covered by a lake!

:joy:

1 Like

I think there’s agreement that there should be a waterway continuing through the lake at least in some circumstances. In my opinion there’s still a waterway but it’s not a river. So just like a river can switch to a waterway=stream for a bit (or vice versa), I think it should switch to a waterway=lake for these segments.

2 Likes