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

Martin Machyna machyna at gmail.com
Sun Feb 14 22:33:54 UTC 2021


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


More information about the Tagging mailing list