Proposal talk:Flowlines

Update waterways documentation as well

Hello, I second this proposal and flowline would be a good improvement.
By the way, Waterway, Water_management and waterway=* should also be updated if this new value is approved. Fanfouer (talk) 14:06, 13 August 2024 (UTC)

Thanks! Good idea about the other pages to update, I've updated the proposal to mention that. JesseFW (talk)

From what I understand, there is no clear flow in a lake, rivers and streams can enter a lake, and leave it, but inside the lake there is no such flow because otherwise they would be rivers and not lakes. Where should the flowline be drawn? —Dieterdreist (talk) 22:10, 15 August 2024 (UTC)

The current guidance (from waterway=flowline) is: "Draw the flowline along the centerline of the lake towards the outlet(s), i.e. in the general downstream direction. (Do not attempt to model the exact fluid dynamics in the lake.)". I'm glad to discuss changing it to something different if you have any suggestions or concerns about that wording. JesseFW (talk) 01:55, 16 August 2024 (UTC)

I believe it doesn’t add information to draw these non-existing flowlines instead of simply connecting inflows and outflows to the lake outline, and in the case of several outflows it would lead to spiderwebs of non-existing flowlines. No flow no flowline I would say, and even more if the intent is avoiding to map actual fluid dynamics on purpose. Lakes can have flow, but it is not as if a river is flowing through them, they have their own system of flow. —Dieterdreist (talk) 14:25, 16 August 2024 (UTC)

Thank you for sharing your view. There is actual flow, it is just much slower than thru narrower waterways. The information it adds is the fact that water (and pollutants, etc) can and do flow thru these paths. But all this was already mentioned in the proposal. I'll let you know when/if this comes up to a vote, and you are welcome to re-express your opposition at that time. JesseFW (talk) 16:07, 16 August 2024 (UTC)

Yes there is flow, but the proposal states it doesn’t want to map it, it wants to map a connection in the “middle” of the lake and even discourages to map actual flow, this is why the term flowline is misleading. —-Dieterdreist (talk) 08:38, 17 August 2024 (UTC)

I think you are misreading the page, but that's exactly the sort of thing this proposal process can help with. My understanding is that flow is exactly what is intended to be mapped, just at a high level of generality. I'm certainly open to altering the guidance on where to put the line, and even changing to a different tag name, although that would have a higher bar as we'd want to do a automatic update of the existing ~2,000 uses. JesseFW (talk) 21:59, 17 August 2024 (UTC)

Clarify distinction from waterway=link

I have been using the interpretation of waterway=link that is analogous to (highway)=link, i.e. for mapping virtual connections between routing graphs — in this case, most commonly as a way to connect land routes with water routes, and enable watercraft (and multi-modal) routing. For example, between a water body's centerline (i.e. flow line) and an access point on land.

I think this proposal would benefit from making such a distinction of intent between the two tags more clearly, rather than relying on the non-flowering nature of waterway=link tags, which is incidental to it, and IMO slightly less intuitive to reason about. --Waldyrious (talk) 08:40, 27 August 2024 (UTC)

Yes, that seems like a good improvement to me, too. Do you have any ideas of how best to word that? JesseFW (talk) 23:01, 27 August 2024 (UTC)

No specific ideas other that what I already wrote above. In fact, those are already adapted from the text I had added earlier to waterway=flowline (in this edit) and waterway=link (in this edit). I can't think of additional ways to phrase this... --Waldyrious (talk) 23:58, 27 August 2024 (UTC)

Thank you for reminding waterway=link to us here. It differs from highway=link as waterway=link is not an actual waterway (a flow of water). It should be replaced with a better solution, just like waterway=dock, waterway=fuel and other amenities (out of this proposal) Fanfouer (talk) 07:22, 3 September 2024 (UTC)

I'm not sure I follow; after all, a highway=link is not an actual highway either.

As far as I understand, waterway=link is not meant for physical infrastructure like docks, piers, fuel stations, etc. Instead, it is meant precisely to connect elements that can be routed into over land, with the centerline of the adjacent water course (like here), to allow for multimodal routing — hence the use of a "virtual" linear connection, which is what the *=link syntax has come to be used for in OSM. --Waldyrious (talk) 16:14, 21 September 2024 (UTC)

Why not flowline=*?

I am against this tag:

1. What size should the reservoir be to choose waterway=flowline instead of waterway=river/stream? I believe that this should be unified, and not decided by local communities

2. A long river can have many small and huge bodies of water along its path. As for me, data users will be surprised by the appearance of waterway=flowline on some section of the river

3. The only reasonable use of this tag I see is when several rivers flow into a large body of water, and a new river flows out of it, which has not flowed into the body of water before.

4. It seems to me that by introducing this tag we are trying to solve the problem of a specific renderer that cannot work with water polygons.

5. Why not flowline=*? Such tagging will not break backward compatibility, but solves all the problems for which this tag is introduced. We don’t draw highway=link in cities at intersections, instead of highway=tertiary/residential/unclassified

In general, I have the same complaints about the waterway=link tag.

6. And somehow it seems to me that cartographers will not understand the difference between waterway=link and waterway=flowline, so using waterway=river/stream seems more common to me.

TrickyFoxy (talk) 05:08, 1 September 2024 (UTC)

What an interesting alternative! I'm glad I kept this open for more discussion for longer. :-) As for the specifics of the idea -- you are proposing drawing ways thru all water bodies, but tagging them as waterway=river (or waterway=stream) and flowline=yes (or something similar)? That seems fine to me, but I may have misunderstood what you are proposing. JesseFW (talk) 15:27, 1 September 2024 (UTC)

Yes! TrickyFoxy (talk) 19:44, 2 September 2024 (UTC)

Added it as an alternative proposal -- thank you! Hopefully people will discuss it, including expressing their general preference between the two, and we can narrow it down to one of the two proposals before formal voting starts. Personally, I'm neutral; both alternatives seem better than the current status, and I'd be happy with either. JesseFW (talk) 02:02, 3 September 2024 (UTC)

We have to decide what solution we keep here as to not mistake the vote and clearly state what we choose to map. Fanfouer (talk) 07:13, 3 September 2024 (UTC)

I prefer the tag flowline=yes Commonly rivers meet in lakes, and this tag allows us to retain original form of mapping data while allowing and end user to know about or filter out sections of waterway within some water bodies JassKurn (talk) 14:27, 3 September 2024 (UTC)

Maybe I'm missing something, but how does this alternative handle the case described in 3. above? For example here or here. It seems to me that extending the actual rivers or streams towards intersection points in the middle of the body of water is not just misleading (since those lines within the body of water are not really streams in the way most people understand them to be), but even potentially incorrect (since we would be arbitrarily deciding which water course flows into which one, as well as the tracing of those flows). How would you handle situations such as the ones I linked with this alternative tagging? --Waldyrious (talk) 16:35, 21 September 2024 (UTC)

6. Really? I assume they can understand this discussion as OSM users can.
usage=flowline is already used for a different meaning. A top-level flowline=* doesn't seem clean. At least waterway:flowline=*
I still don't understand what's the inspiration of using "flowline". NHDFlowline includes all flows. Rather there is "artificial path". so I would prefer that terminology.
—— Kovposch (talk) 15:02, 3 September 2024 (UTC)

Seems like a nice compromise

I support this proposal, and see it as a nice compromise between mapping rivers and streams through waterbodies vs not mapping anything through waterbodies at all.

There was some discussion on the forums on whether waterways should be mapped through waterbodies at all. The critics arguing that routers and anylysers should be able to handle waterbodies. Putting aside that handling polygon or even multipolygon waterbodies is much more complicated than handling a graph of ways, I think that is a moot point given that mappers already map waterways through waterbodies anyway (as rivers and streams). While many rivers and streams can be considered to carry on through the waterbody and can be mapped as such (as they are today), there are many that aren’t considered to continue as a river/stream and flowline is an excellent option for mapping those.

The only concern I have is for waterbodies with multiple outlets. In that case all inlets are mixed together and contribute to all outlets, since it is very hard to say anything definite about which exact inlets were the origin for the water going out an outlet. Since flowlines are directional, all inlets would need a flowline to a central point from which flowlines would go out to each outlet so that all inlets go to all outlets. This would lead to very messy mapping for large waterbodies. In this case looking at the waterways connected to the waterbody edge makes the most sense.

But just because flowlines aren’t perfect doesn’t mean they aren’t an improvement on the status quo. If anything the transition from handling only the waterway graph to handling the full waterbody could be made easier by all ways in the waterbody being flowlines. It would then be easy for a tool that handles waterbodies to exclude the waterways within the waterbody by ignoring all flowlines from an analysis, rather than having to account for rivers and streams existing both within and without the waterbody.

Synfarer (talk) 10:43, 26 October 2024 (UTC)