The end of waterway map

I’ve added a new feature to A map showing where waterways end, i.e. a map of the ends-of-waterways :slightly_smiling_face:.

It shows nodes which are “the end” of a waterway, i.e. where the water can’t go anywhere else. Uniquely, it calculates the total upstream length of waterway ways which end at a point. It uses the direction of OSM ways, and how they are connected. This should make larger mistakes more visible. Like the rest of, data is updated daily, at the same time.

It’s normal for there to be ends, like when a river ends at a coastline. This will rightly show up on WWM:Ends. When a river empties into a lake, this will also show up, unless we’ve mapped a waterway through the lake. There’s active discussion on when & how to do that.

Merging & Splitting

When 2+ waterways come together, the upstream value is added together. When 2+ waterways split, the upstream value is split equally. This mostly works well, e.g. when a river splits through a side channel, and then rejoins.

If you have a small stream going into a large river, and it’s in the wrong direction, then half the upstream value from the big river will go off to the side stream. This is a mapping mistake, and this tool makes it easier to find them. e.g. way 962171457 is mapped as flowing out of the Nile, so it’s taking 17,000 km of upstream away! on wwm/ends. This direction should probably be reversed.

Conversely, this way is taking half (930 km) of the Shannon wwm/ends. I don’t think this should count as an “end”, but the mapping looks ok. WWM/ends excludes canals. I’m unsure if it’s possible to calculate the right value. Perhaps more advanced tag calculations. What do yous think?

I hope you enjoy this new map & we all improve OSM together. :slightly_smiling_face:

See also

• a short description of how it works.
News about can be found on Mastodon/Fediverse (incl. Atom/RSS feed):
• This code is on Github: amandasaurus/ New issue reports are welcome.
• The programme which generates it is osm-lump-ways


Any idea what it’s detecting at Is it confused by the lock or does it not think a river should flow into a canal?

I see a lot of small black dots on low z-levels, which disappear when I zoom in. Since the data for smaller waterways apparently then exists, I would like to be able to view them to fix issues in my local area.

That’s been fixed now. Initially I wasn’t including waterway=canal. But I kept seeing issues like that. So now I include a waterway=canal iff there is lock=yes. Water will now flow through locks.

I made this code change yesterday, and posted this message before that code change. This also fixed one of the erorrs I mention in my original post. Ooops.


Coincidentally had a flag recently, then saw the end node was marked with something which translates to a sinkhole (a ponor). Remembered that as we have many little streams that end in nothing.

I found an interesting case, where a water course is mapped as diverging into an underground/overground pipeline which then routes onto another water course: - End points.

The pipes are mapped as Way: 151069423 | OpenStreetMap, Way: ‪Conduta de água‬ (‪225455540‬) | OpenStreetMap and Way: 225455539 | OpenStreetMap, and their direction is correct. Shouldn’t the start of the pipeline not be considered an end for the water course?

Edit: here’s another one that I’m a bit puzzled by (also involving pipelines, this time one that diverges and returns to the same water course).

1 Like

The title of this post made me very sad, the content made me very happy. Thanks for a great map + tool!