Updating and fixing rivers

Hi everyone,

We are working on a project that is trying to clean up and update river data globally. In short, we look to fix errors like disconnected waterways, overlapping water areas or waterways, correcting broken multipolygons, fixing mistagged features, removing duplicate objects and also moving older river tags (waterway=riverbank) to the newer more numerous version natural=water + water=river.

More details are written up here:
https://wiki.openstreetmap.org/wiki/WikiProject_Waterways/River_modernization

Let me know your thoughts about running the modernization in Poland.

Cheers,
Martin

W skrócie chodzi o przetagowanie

waterway=riverbank 

do

natural=water water=river

i zrobienie jakichś poprawek przy okazji.

So far, the official data on the waterways network in Poland are not available for mapping.

Also I forgot to ask if any good soul could translate my message to polish I would be much obliged!

Dziękuję

Although Mateusz has already shortly abstracted the main goal of the project, regarding Your wish I attach the full translation below:

**@cytryn @Mateusz Konieczny ** Thanks for translating!

I’m wholeheartedly for updating river tagging in Poland.

I agree that it would be great to clean up the river net. Generally I can’t think of any technical problems it could imply, but maybe someone with more experience could add something here.

Beside all the issues mentioned, it would be also nice to fix inconsistencies in flow direction, if there are any. I’d like to point out here, that although for rivers the direction is rather obvious (or can be easily researched), it can be quite tricky for the water canals. The reason is that for all “non-stream” waters (lakes, canals, etc.) the fairway direction is defined by the authorities, so it doesn’t have to be obvious in some cases. I believe that waterway direction of mapped canals should origin from the physical terrain shape, so in all cases it should follow the direction from the highest to the lowest level. It implies that for summit-level canals it should start from the summit-level reservoir, so in this place there would be two adjacent waterways with opposite directions, which can be perceived as an error by validators. I’m not sure, but probably the only case in Poland is the Augustów canal.

Thanks everyone for your comments. I’ll try to answer

@Władysław Komorek: Just to clarify, instead of mapping new objects we are working on existing data. Though we can add new objects in some cases when it is required for fixing an error.

@cytryn: Thanks for bringing it up. Fixing the waterway flow consistency is also one of the modifications we do as well. It is just sometimes difficult to discover those cases. If anybody knows a strategy how to detect those type of errors that would be a huge help.
(On a side note, I always though that direction for canals is not that important, because water typically doesn’t flow that fast. JOSM also doesn’t show direction arrows for waterway=canal. But noted, we’ll be careful around canals.)

Osmose detects the opposite direction of adjacent segments, but probably the most credible way is to trace each waterway manually from source to river mouth :wink:

Generally you’re right, but I can think of at least one situtation, where this matters from the mapping point of view - it’s the way how the water lock icon is rendered. Traditionally, in cartography water locks are depicted with the single or double “chevron” (<<). The story behind it is that it symbolizes the lock gate which in early design had such a V-shape (image). The tip of the gate is always directed against the water flow (picture), so it could force the water pressure acting onto it to close the gate rather than opening it. Bearing this in mind, the icon of the lock should follow the scheme. So the conclusion is, that if one day Carto will start to render water lock icons (BTW I’m quite suprised it doesn’t), the tip direction of the icon should correspond to the given waterway direction.
Likewise, I can also imagine the direction could affect some other structures icons behavior, i.e. weirs, sloping-plane locks, etc.

By contrast, iD does.