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

[Bert -Araali- Van Opstal]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20210214/4bd3f1e5/attachment.htm>