I’m sorry, I reread the wiki article, it seems it is in fact artificial. I’ll try to find out which part is artificial to fix this.
1 Like
I’ve added a new view, which includes waterway and natural=water.
Any OSM ways, which have a waterway key, or natural=water, and share a node, will now be joined. The total length of the water systems is much less accurate now, but it means that rivers which are connected to the edge of a lake, or river area, will be connected together.
OSMers have various views on whether we should map rivers (or streams) through waterbodies (e.g. this thread). One reason for mapping through a water body is to make hydrological analysis easier, such as on WaterwayMap.org, but people (incl. me) are unsure when to map through a waterbody. My hope with this analysis is to support both mapping approach, and not force one.
Alas, many non-trivial lakes are mapped as multipolygon relations , and this code only looks at ways. 
e.g. the big red Cogburn Creek in CA-BC area is correctly joined when when combining natural=water or waterway=*
wheras with just waterway=* all the tributaries connected to the riverbank are not connected to each other.
However they aren’t connected to the mulitpolygon relation for Harrison Lake).
You can see still find mapping mistakes. Here the Thompson River isn’t connected to the natural=water river bank. (which should be mapped).
I’ll keep this view for now, although it is a little hefty to generate. Supporting relations is low on my priorities for now.
Happy Mapping. 
7 Likes
You could try to use the outer ways as areas and ignore the islets for this purpose. That does of course require some preprocessing, but it may be a simpler solution than trying to support the MPs in full.
1 Like
This is what I have done using ST_ExteriorRing in PostGIS IIRC (not quite sure where the output is located on my PC)
One problem with “Rivers and streams” view, is that hydro power plants almost always break up rivers. When a river comes to the dam, water goes through several paths:
- pipeline under the dam, through a turbine (
man_made=pipeline+waterway=pressurised) - spillway over the dam, or besides the dam ((
waterway=canal+usage=spillway) - a lock system besides the dam that lets ships through (
waterway=canal+lock=yes) - A fish pass (
waterway=fish_pass) - A canoe pass (
waterway=canoe_pass)
As we see none of these are waterway=river or stream. And if power plants were mapped correctly, the “River and stream” view would stop showing river watersheds, it would just show us watersheds of parts of rivers between two dams.
1 Like
The real problem is not these side_stream but more with river divides with no specific tag (like derivation=partial) to document features for derivation of water. Below are examples of features
for partial derivation of rivers into the James Bay hydro-electric project where the tags way[waterway=canal] and node[waterway=flood_gate] describes the infrastructures but no specific tag to indicate a derivation :
- Node 4404857334 - “waterway”=“floodgate” Structure to control partial derivation of the Caniapiscau river
- Node 8057437866 - “waterway”=“floodgate” Structure to control partial derivation of the Eastmain river
- Node 11346676599- “waterway”=“floodgate” Structure to control partial derivation of the Nemiscau river
- Node 4428145174 - “waterway”=“floodgate” Structure to control partial derivation of the Rupert river
What do you mean by “water derivation”? I’m not sure I understand your post.
The 4 rivers merge into large reservoirs connected with a serie of dams and hydro-electric power plants. For each ot the 4 rivers, a portion of the upstream river volume of water is not returned to the downstream section of the river - thus being partially derived to an other watershed. At the point of connection of the reservoirs with the downstream sections, a dam assures the deviation of the water in an other watershed and a flooding door on the dam manages the volume of water to be returned to the river and maintain the population needs, the river vitality, a good habitat for fish and activities on the river (fishing, etc).
Did you mean “diverted”? I assume you’re not talking about mathematical derivatives.
English is not my first language, but below is how deepl.com translates from french
« canal de dérivation de rivière » :
- river diversion canal
other solutions - river derivation channel
- river derivation canal
- river dividation channel
So you would put the tag derivation=partial on what, the power plant, or the artificial lake, or which part of the system? And that would mean “Some of the water is diverted to other watersheds”?
There is a view for “waterway w/o some “dam”-like values”. It should include these pipelines, spillways, canals, fish & canoe passes.
The tag filter is waterway∉dam,weir,lock_gate,sluice_gate,security_lock,fairway,dock,boatyard,fuel,riverbank,pond,check_dam,turning_point,water_point,spillway.
e.g. compare this dam in France with just rivers/streams:
to the version which includes the pressurized pipes through the dam:
Does that solve your problems?
The view “without dams” is almost identical to the “all waterways” view, because usually a river is connected in some way with the downstream. And since it uses all waterway tags, everything is connected, and there is no distinct watersheds. And I must admit, I would really like to have a watershed-correct view derived from Openstreetmap data that resembles this map.
Placing this tag on the node[waterway=floodgate] would explain its role.
The problem with determining water catchment areas is that many rivers are partially canalised (waterway=canal): Locks, hydroelectric power stations, etc. As a result, there is often no continuous connection between waterway=river (or =stream).
If waterway=canal is omitted from the analysis, the water catchment areas are often incomplete.
If waterway=canal is taken into account, different water catchment areas are often connected with each other.
This is a dilemma that I don’t know how to solve either.
Possible approaches:
- canalised river sections often have the same name as the river upstream and downstream of the canal sections → belongs to the water catchment area
- If the name contains the word “canal” in the respective national language and/or the name is different from the adjacent river sections at the ends of the canal, then it indicates that it is not a canalised river but a connection between different rivers (possibly different water catchment systems). - Such channels are usually not taken into account in the analysis.
- many, especially larger rivers including canalised river sections have relations of type=waterway, waterway=river in OSM. Perhaps these can be used in one way or another to determine a river system (and “normal” channels otherwise not taken into account)
I suspect that each of these variants will have various exceptions where an automatic determination of the catchment area will not work.
- perhaps an additional tag waterway=??? is needed to be inserted in places where different river systems are to be explicitly separated.
I wonder if where the main flow has been canalised we shouldn’t tag them as waterway=river with something like canalised=yes or canal=yes. For navigation purposes boat=* should still provide necessary information. Note that there are other issues which I find unsatisfactory with waterway=canal (mainly use both for irrigation and navigation canals): particularly for small irrigation channels which may be no more than 50cm wide.
Note neither canal or canal_type seem to be in use to indicate this type of canalisation either.
1 Like
This is easily solved by looking at the direction of waterways. You start at the point where the river touches the coastline, and you go up the graph. Each connected way should have a direction towards the coastline. The moment a way is directed the other way, the watershed stops.
So in the illustration below, we start with the node 1 because it’s a waterway=river and a natural=coastline meeting in a node. We go up (down) the graph:
1←2←3←4
and all the nodes are connected so that the direction is towards the previous one. They are all in the same watershed.
But then we get to 6←7 →9, and 9 is directing away from the previous one, so the watershed stops there, the waterway 7-9 isn’t a part of this watershed. We can include canals, pipelines, anything, direction shows where the water is going.
-------------1-----coastline-------
↑
2
↗ ↖
3 6
↗ ↖ ↖
4 5 7
↗ ↘
8 9
This is what I’m trying to represent. Mark the direction of the stream from 7-9:
The problem is, I don’t know how feasible it is to do this in the existing code base, and for the algorithm to be reasonably fast for the whole world.
1 Like
The basic pattern of traversal of a directed graph should work in these cases, however if we start from sources the fundamental problem is :
-------------1-----coastline--------C-----
↑ ↑
2 C
↗ ↖ ↗ ↖
3 6 B ...
↗ ↖ ↖ ↗ ↖
4 5 7 A ...
↗ ↖ ↗ ↖
8 9 ...
[/quote]
Node ‘9’ may have other afferents too, which would still mean incorporating it’s headwaters in two watersheds. And there are plenty of waterways with sinks in lakes, endorheic basins etc., so I don’t think you can always start from the coast.
A related question is can one identify sub-basins within one major watershed?