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.
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.
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.
I think this notion of “definitively linear” is affected by scale. If I’m mapping at zoom level 18 or viewing the map at z15 and the waterway has a nontrivial length, the same degree of imprecision may not bother me so much. It reminds me of how, when I return to ponds I mapped reasonably carefully a decade ago, I’m horrified at the sharp angles I drew where there should be smooth curves. But this only happens when I’m mapping at my usual z19–20, something I couldn’t fathom a decade ago. In a few years, I’ll feel lost trying to navigate the sea that is a backyard swimming pool.
I find it interesting that these artificial paths through waterbodies has caused so much discussion, whereas other kinds of artificial paths artificial paths have barely attracted any attention:
footway=link has seen phenominal growth as mappers draw beeline dashes from the curb to the street centerline or parking aisle. Mappers usually don’t delete the highway=footways going through a pedestrian area, because almost every router would otherwise tiptoe around the perimeter, which causes us embarrassment. When mapping a motorway ramp, the consensus is apparently to have it run roughshod over a patch of pavement or grass where vehicles cannot go in reality. We call this a transition. (Yet the Kreuz Köln-Sud solution looks so artificial that, inevitably, the Kreuz Köln-Sud itself no longer conforms to it.)
In an unsophisticated renderer, disembodied and misleading labels can occur with all these tagging approaches too, though some renderers’ translucent waterbodies do exacerbate the waterway problem. At least the technology for efficiently mitigating that problem (layering and masks) is well-known, if not ubiquitous (#6).
I think it’s because water bodies and waterways have a far greater range of shapes and widths than roads. Perhaps if highways the width of Lake Michigan existed we’d be discussing them as well! Hmm, how many thousands of lanes would that be?
Imagine if people thought of how the ground is shaped underwater, and the lakes at some point reducing water level revealing a more near-to-river flow of the water current
A river channel exists in most reservoirs and may be available via topographic maps, but the glacial lakes that some have focused on in this thread don’t have such channels.
But roads and walkways don’t have nice big lakes to connect them together. Waterways can also easily be padded with a companion area (riverbank), while a road can not (or rather… should not). So a road has to compensate for for having only centerlines by actually linking them with virtual ways.
While this is indeed mapping for the router, one must also consider that without such links, OSM would be completely useless for routing and lose a majority of its usefulness. I don’t see, however, that OSM needs to use centerlines in lakes to do water-routing (it would be wrong anyway unless the virtual rivers follow seamarks).
Oh, footpaths can have nice large pedestrian areas or nice large squares connecting them.
Well, it certainly doesn’t always make sense to paddle a small canoe in the middle of a very large lake.
Nor does it always make sense to always paddle along the shore on a heavily indented lake.
Indeed, but I think we can all agree that the upper limit on pedestrian area size doesn’t even begin to approach the upper limit of lake size. Unless there are some pedestrian areas the size of Austria that I’m unaware of .
I brought up footway=link only to raise awareness that OSM does map some ways solely for connectivity; it’s a broader phenomenon than these waterways. But it’s already been demonstrated that artificial path waterways are useful for more than network analysis and connectivity: they can also serve as labeling hints to renderers. If we have a problem with rendering hints that have some basis in reality, however tenuous, then natural=valley is just as questionable, and place=* nodes as label members of boundary relations are not far behind.
Yes, but the roads dont, so how do you connect a “square” to a “road” if not with a link.
I said padded, not paddle As in, enclose the centerline with a waterbody.
Routing should be done not on premade centerlines, or the edges, but on open space calculations for shortest way across the space between the access and egress points.
But size doesnt matter. The problem is moving between centerline mapping and area mapping.
That may sometimes be the case, but I don’t think anyone will be served by having river name lables at random places in huge lakes like Ladoga. Unlike rivers in lake Ladoga, I think a valley or ridge is more easily defended as it actually being there and the name label being relevant.
Yes this is the fundamental issue, but I think size does matter. Whether you think a stream should end at a river’s edge or center line, the difference is just 10m when the river is 20m wide. This is not such a great distance and I think most of us see no issue with it. I’d also hope nobody concerns themselves over the junction of two 1m wide streams where one center line must extend an extra 50cm to meet the other. However, when a river is 10km wide, a stream flowing into it must be extended 5km from the edge to join the center line. With a 100km wide lake, now we’re talking about 50km. Maybe the stream flowing into the lake is only 5km long (or 55km if you measure to the center of the lake!). Technically, the 50cm extra is the same issue as the 50km extra, but they feel pretty different to me. Probably because I can travel 50cm in a single step while it might take me several days to travel 50km!
If size doesn’t matter, waterway lines through 100km wide lakes would be no more or less correct than those through 1m wide stream areas. If size does factor in (as I contend) then we might find consensus on a guideline suggesting that waterway lines are reasonable through water areas up to a certain size, but beyond that are best avoided.
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?
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).
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.
.
As in, enclose the centerline with a waterbody.