I’ve now created the proposal page for waterway=flowline : Proposal:Flowlines - OpenStreetMap Wiki (although I haven’t filled it in yet). I’d be delighted with help, or criticism, or other input.
6 Likes
Where a watercourse enters a lake and ceases to be recognizable as a stream or river, start a way tagged waterway=flowline.
https://wiki.openstreetmap.org/wiki/Proposal:Flowlines
Please, cross post this announcement on the tagging mailing list on my behalf by sending an email to: tagging@openstreetmap.org
1 Like
I’ve now populated the proposal, and opened it for comment.
Thanks for actually creating the proposal 
Have posted it to Tagging on your behalf.
1 Like
The proposal has now been open for discussion for nearly 2 weeks, and the only comments were one small (accepted) suggestion from Fanfouer and clear opposition to the whole idea from Dieterdreist. While I plan to leave it open for discussion for another two weeks or so, in case there are additional concerns or suggestions that people might want to make, I thought I’d bring it up here again. Also, if there are any additional venues where the proposal would be appropriate to mention (such as Slack, Discord or the Fediverse), please do!
I see where @dieterdreist is coming from. These lines do not provide any additional information that isn’t already present in the map. Existing inlets and outlets perfectly describe the fact(s) that a flowline purports to describe.
It’s not clear that there’s a real problem that is being solved here, except perhaps to make the waterways map look a little nicer, in which case we’re basically tagging for the render by suggesting a nice place to put labels and not mapping actual geodata.
Thanks for the further discussion! While in theory users of the data could interpret (appropriately tagged) ways that touch areas as implying that they all connect, in practice that is both difficult and (as I understand) very infrequently if ever actually done. I’d be glad to hear from @quincylvania (who originated the tag), and @amapanda_ᚐᚋᚐᚅᚇᚐ (who decided not to implement the logic for associating waterways across waterbodies) their thoughts.
Pro: It could stop people from having all sorts of rivers flowing into a basin continue through which messes up label rendering. Last I looked, mappers in Japan were very prolific at that.
Con: It is a completely made-up line that only serves the purpose of “OMG I cannot deal with relations that have holes in them”
I am against mapping these lines at all, be it as rivers or as “flowlines”. To me, this is like drawing random “highway=something” lines across a flat area just so that routing works better, or to get rid of that ugly disconnected relation warning in JOSM. We should solve these things properly rather than mapping a band-aid across it. I therefore reject the proposal because it is a band-aid.
1 Like
Other cases I’m aware of where a “redundant” way is used within an area that could theoretically imply it are:
- water=river (where the way is actually required, and the area is optional)
- highway=footway (which there is controversy over whether to map it across pedestrian plazas)
There may be others.
1 Like
What would solving them “properly” look like?
water=river (where the way is actually required, and the area is optional)
it is not comparable because for rivers we try to map the actual way which the water flows while the proposed flowlines in lakes (which are lakes because of the absence of river like flow) are explicitly not trying to do it.
I’m not a big fan of “virtual” ways in general.
I can half understand the use of them for area routing instead of solving the problem properly because we’ve got in to a vicious circle of developers not being motivated to add support, because people work around the issue with “virtual” ways, because developers haven’t added support.
But in this case there doesn’t seem to be any technical justification at all, just a desire to connect the (inflow(s)-outflow) dots, which however is something that can easily be done by the data consumer if they want to do so.
2 Likes
Yes, however there’s already (waterway=river)s through a lot of lakes, so this is not entirely different from the pedestrian example.
I’ll be supporting this. Commonly river & streams are mapped through still water bodies, and this improves that situation.
Clearly some have strong views, but I see no harm in this data.
4 Likes
I mapped some flowlines, i.e. retagged waterway=river into those: To get rid of the names from OSM-Carto. Tagging for the renderer, sure.
If only there was highway=route to get rid of invisible paths without drawing the ire of “expert mountaineers” that need them badly: So they can recreate tour-portal rambles in OSM.
1 Like
As I said in my SotM Europe 2024 talk, I would like to add this feature to WaterwayMap.org. I just haven’t gotten around to it! 
I did once try to waterbody ways. It helped connect up some, but so many were relations that the map looked wrong.
The tool that powers WWM, osm-lump-ways only supports ways, and not relations. You can see from the changelog that it’s under active development, with a lot to do!
Personally I think rivers should be mapped through waterbodies, so the status quo suits me. However I want WWM to support both, to precent undue influence on mapping. I think waterway=river (with name!) is correct to map through a waterbody, but I’ve no objection to =flowline.
1 Like
@TrickyFoxy came up with an alternative option, that I’ve now added to the proposal page. Please express your thoughts/preferences as soon as practicable, so we can hopefully narrow it down to one or the other before starting formal voting.
I like flowlines. Breaking down real world complex 3d geometry into simpler data makes it much more useable. Shops aren’t nodes, roads aren’t lines. But it sure makes them easier to work with.
Sometimes though, you need some of the higher dimensionality back, and then a bit of duplication is unavoidable. River meeting lake isn’t the only example.
I want waterway data to be useable for graph techniques (powerful things, see for instance routing), so I want flowlines.
3 Likes
I prefer the suggestion made by @TrickyFoxy for
flowline=yes
It will allow end user knowledge of the existence of a “flowline”, but also allow original info to be retained.
This does effectively create two proposals?
1 Like
I do not support the alternative proposal flowline=yes. The idea seems to be to continue mapping waterway=river and waterway=stream lines through large waterbodies just with the extra tag. Providing an alternative to that practice is the whole point of waterway=flowline. A line tagged waterway=river through a massive lake is can often be false information, unless the lake is actually a reservoir (artificially created by damming a river).