[Tagging] Deprecation - waterway=riverbank vs water=river

Mon Feb 15 01:12:22 UTC 2021

1) Correct, water=stream is used and similar to water=river. I wanted to
point out that the wiki needs updating, water=stream is not described in
the wiki.

2) Not exactly wrong tagged, they are correctly tagged, the
waterway=river_bank is used also to map wide canals, streams, pools or
ponds (streamponds) formed by intermittent rivers etc... but because of
the single existing waterway=river_bank, since we didn't have any
alternative like waterway=bank in general, or waterway=canal_bank
waterway=stream_bank etc... deprecating it to water=river is wrong and
change all these areas to rivers.  You will get areas tagged as
water=river with a waterway=stream, waterway=canal running through it.
That would definitively be unfortunate. You are right in the sense that
for these you could easily tag those correct with a corresponding
water=stream or water=canal. However that is a huge task, there are
thousands of these waterway=river_bank which will have to be reviewed
and retagged.

3) Nope, our wetlands appear as wetlands most of the year since the
river running through it spreads over a plain creating a very shallow
wetland or even just mudplains and continues to run underground. Many of
them however historically carry the name of the river and are considered
rivers since a few days, sometimes longer the whole wetland turns into a
raging river. We looked at how historically this used to be mapped, the
common practice is to map the dominant appearance, so the wetland, with
the river running through it (either intermittent / seasonal or not).
Same we have (I think mentioned before) large sand plains with the
riverbank sometimes very far from the actual common river flow.  Tagging
those plains as sand or mudplains with intermittent or seasonal river
running through it is fine.  In some cases these rivers remain wide
enough for the waterway=riverbank to be used.  That's the riverbank
during the dry state or season (seasons vary largely from year to year).
Leaving us to map the riverbanks as cliffs or the more suitable but less
used natural=earth_bank. As stated this gives no validation warnings,
because river_bank is happily to overlap with wetland and mudplains. 
Not so the natural=water areas.  I agree this could be easily solved by
changing the validation rules or just ignore the warnings, but it's not
that simple. We use these warnings to detail large wetlands. We draw
areas of wetland with type tagging on large multipolygons or relation
boundaries and use these warnings to tag them correctly as inner parts
of the multi-polygons or relations. Since this was never an issue with
the waterway=river_bank these are not defined as inner parts. Neither do
we define residential areas or farmland (most of these wetlands are
encroached) since they are not considered as water features. I hope my
point gets clearer, a solution would be to change the validation rules,
however that would break a powerful tool ans consistency check for
correct tagging of wetland at the same time. We can put our heads in the
sand and say this is a validation or editor problem, not a tagging
problem, but I think, due to it's huge impact, we should consider it here.

4) Allow me to clarify: you have only 1 way to define a drain (sorry I
used ditch it must be drain), on a way with waterway=drain. When the
drain has just the function to collect water and let it evaporate or
soak into the ground (it drains into the ground so its a drain not a
ditch), the node at the end of the way is not connected to any other
waterbody or waterway. Same concept appears in irrigation systems.  In
JOSM you get a warning that the drain (as it assumes it has to flow into
something) is ""Waterway ends without a connection to another waterway
or the direction of the waterway is wrong".  Same as we get messages on
none connected roads for which explicitly a noexit key is created. So
the described proposed way to solve this is to draw a small pool at the
end of the ditch or define the end node as a sinkhole (yep, mappers are
creative)! If you use natural=water, water=ditch (which is not in the
standard JOSM presets) you get a validation warning that the way is not
closed. The common validation is that it doesn't take into account that
the natural tag can be applied to a linear feature. By the way, the same
applies for the other natural water tags.  Now this might be a JOSM and
validation issue but to my opinion relates to this issue as our wiki and
all the editors refer to ways only for waterways, and natural=water can
be used on ways according to the wiki, true, but isn't correctly
supported in our editors. The situation gets even worse because
waterway=river_bank is sometimes used to map these drains ! So if we now
deprecate this waterway=river_bank ditches, they all become rivers ! The
best solution would be to create a new tag similar to the noexit tag on
highways, f.i. noflow. But again, there are thousands of thiese
workarounds implemented.

Greetings, Bert Araali

On 15/02/2021 01:33, Martin Machyna wrote:
>
> 1) If I understand that correctly river_bank is used for both rivers
> and stream as would be water=river, so I don't see much change. But is
> seems that some use water=stream anyways:
> https://wiki.openstreetmap.org/wiki/Tag:water%3Dstream
>
> 2) Correct me if I am wrong, but that sounds like those channels and
> ponds are wrongly tagged now and replacing river_bank with river would
> not change much. Except now we have water=pond and water=canal to fix it. 
>
> 3) This seem to me like a simple change in the validator tool would
> fix that. But I personally think that those are badly mapped, you
> either have a wetland or you have a river, so having that split into
> separate polygons is correct.
>
> 4) I don't see that deep into the sinkhole issue maybe you can
> elaborate or someone else can chime in. I just try naively with an
> idea, that to me waterway=ditch has a merit for routing within the
> ditch system (if it is a single ditch than not so much). Plus might be
> useful when you want to retrieve water elements as line-mesh rather
> then polygons. I certainly don't see anything detrimental on having it
> there. But you might have more to say to this.
>
>
> On 14.2.21 2:16 , Bert -Araali- Van Opstal wrote:
>>
>> I am strong against to deprecate waterway=river_bank in favour of
>> natural=water and water=river:
>>
>> - there is no (described) water=stream in the wiki. However,
>> waterway=river_bank is used often for more detailed mapping of
>> streams, so we need (at least described) water = stream;
>>
>> - if we deprecate and eventually ditch or replace waterway=river_bank
>> we are going to get a lot of eceptions, since waterway=river_bank is
>> also used to map wide channels, sometimes ponds etc.., actually most
>> of the linear waterway feuatures whenever they get wide. 
>> Unfortunately historically we had only the vaue river_bank instead of
>> "bank" as a more general term.
>>
>> - waterway=riverbank is accepted and doesn't give warnings in
>> combination with wetland = natural. So many wetlands have rivers with
>> defined river_banks and other waterways running through them without
>> any issues.  Natural = water is considered as bad mapping and creates
>> warnings.  Meaning all wetlands need to be converted to multi
>> polygons or relations with natural=water inner parts. A huge task.
>>
>> - I would like to see a solution for non-flowing water in ditches.
>> Now it says explicitly that it has to be combined with
>> waterway=ditch. It creates lots of validation problems, yet many
>> ditches have the sole purpose to let the water evaporate or soak
>> away. People find creative solutions like adding sinkholes at the end
>> of a ditch, bad practice but only available solution at this time. So
>> do we change the wiki as acceptable to map ditches as areas (in se
>> map their banks) without a waterway=ditch running through them ?
>>
>> So I am in favour of deprecating waterway=river_bank in favour of
>> natural=water if we find reasonable solutions for the above issues.
>>
>> On 14/02/2021 21:41, Martin Machyna wrote:
>>> 1) merging of the schemes
>>>
>>>  argument in favor:
>>>
>>> - more simple and unified database
>>>
>>> - no need to maintain two schemes
>>>
>>> - less confusing to new users
>>>
>>> - OSM would look more professional and reliable to current and
>>> potential new adopters
>>>
>>> - resolved violation of "one feature one tag" rule
>>>
>>>
>>> argument against:
>>>
>>> - Lithuanian tool would not work
>>>
>>>
>>> 2) which to keep
>>>
>>> water=river:
>>>
>>> - is approved
>>>
>>> - Would unify water=* subtree for water covered areas and waterway=*
>>> for river network
>>>
>>> - Is currently more popular
>>>
>>>
>>> waterway=riverbank:
>>>
>>> - is currently more numerous
>>>
>>>
>>> On 12.2.21 10:38 , Marc_marc wrote:
>>>> Le 12.02.21 à 16:18, Martin Machyna a écrit :
>>>>> I don't see any advantage to keep both other than someone's personal
>>>>> convenience.
>>>> I think the debate should be splited in two, especially since at least
>>>> one person is playing on both sides to say that at the same time there
>>>> is no problem to have a fragmentation since all the tools manage both
>>>> schemes and at the same time that it is very expensive to eliminate
>>>> one
>>>> of the 2 schemes because some of these own tools only manage one
>>>> schéma.
>>>>
>>>> Unfortunately, apart from discussion, there is no way to make a 2-step
>>>> proposal:
>>>>
>>>> 1) in favor or against the merging of the 2 schemes into a single one
>>>>
>>>> argument in favor: reducing the loss of human time, increasing
>>>> coherence
>>>> and therefore quality
>>>>
>>>> argument against:
>>>> - communication (this is a point that needs to be improved) is
>>>> obviously
>>>> more time-consuming in the short term than the status quo.
>>>> - tools managing only one of the 2 will see their defect even more
>>>> visible depending on whether the remaining schema is the supported one
>>>> or the other (and in my opinion, it is not a argument against so
>>>> much to
>>>> see the "design errors" rather than "if not too many complaints, do
>>>> nothing").
>>>> - the existing old books are frightening to some. (against argument:
>>>> if you type a tag in any correct editor, it tells you that it is
>>>> deprecated, so everyone knows how to update easily)
>>>>
>>>> argument neither for nor against: it will be necessary to carry out a
>>>> mass operation so that the gain above can be made, I'm willing to take
>>>> care of it.
>>>>
>>>> 2) to choose the new scheme on the basis of the
>>>> advantages/disadvantages
>>>> of each of them and no longer on the basis of "should fragmentation be
>>>> maintained or not".
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Tagging mailing list
>>>> Tagging at openstreetmap.org
>>>> https://lists.openstreetmap.org/listinfo/tagging
>>>
>>> _______________________________________________
>>> Tagging mailing list
>>> Tagging at openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/tagging
>>
>> _______________________________________________
>> Tagging mailing list
>> Tagging at openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20210215/9bfbd1c6/attachment-0001.htm>