`osm-river-basins`: Website to show how are rivers in OSM connected

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:

  1. pipeline under the dam, through a turbine (man_made=pipeline + waterway=pressurised)
  2. spillway over the dam, or besides the dam ((waterway=canal + usage=spillway)
  3. a lock system besides the dam that lets ships through (waterway=canal + lock=yes)
  4. A fish pass (waterway=fish_pass)
  5. 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:

image

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:
directedGraphRealLife

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?

Yes, 9 would then be a dual watershed stream, and ideally would get drawn with a line made of two colours, one for each watershed. Or more realistically, it would get some “neutral” colour.

A new tag like waterway=sink or waterway_sink=yes would give us more nodes, just like those that end on a coastline. Although just looking for waterways that end nowhere would be enough to find all the sinks.

Traversing the graph like this would already find those I think.

No here, I mean can I find the Inn in the Danube basin and then the Sanna entering the Inn and then the Rosanna and Trisanna merging to form the Sanna (slight special case), and then even one of the side streams such as the Malfonbach. Changes of name (as here) ought to help, but these aren’t always available, so things like length above a bifurcation node may be needed.

good idea!

Seems like a pretty straightforward situation:

-------------1-----coastline-------
             ↑
             1
           ↗  ↖
         1       2
                ↗ ↖
              3     2
            ↗  ↖
          4     5
        ↗  ↖
      4     6

1 - Danube
2 - Inn
3 - Sana
4 - Rosanna
5 - Trisanna
6 - Malfonbach 

All are going towards Danube, and the point on the Black Sea, no problems there. Here’s the Overpass query.

Won’t the question of which way “8” flows, left or right, effect things?

You’re right, 7-8 is a stream in two watersheds in this example.