[Tagging] Deprecation - waterway=riverbank vs water=river
Martin Machyna
machyna at gmail.com
Wed Feb 17 01:21:11 UTC 2021
1) I guess it is ok to add it to the water=* page in a separate section
mentioning that water=stream was not a part of the original proposal.
2) I would say this could be fixed when the tag on the object will be
updated to water=*. Either changing it to those values that exist like
water=canal or by inventing new subtag like water=streampond. But I am
no expert in those features.
3) Hmm, I am no limnologist but that sounds to me like a definition of a
wetland. I personally would tag it as wetland with whatever the river
name is. But if you insist that a river must be drawn across them then
I'd say the validator change is more straightforward and I think it
could be possible to do a custom hack that would allow you to use it as
your tool. I assume you are talking about JOSM, there might be people
skilled in Java that would know more about this. Another solution that
comes to my mind is to invent a new wetland tag that would be specific
for cases that you are describing, but not with immediate support from
editors and renderers.
4) You have some creative workarounds :) I just chose to ignore those
warnings if I see they don't make sense. Natural=water is described as
areas-only in wiki and that makes sense, if you are using it on linear
features then that is not the intended use. So natural=water+water=drain
is to outline the area covered by drain and waterway=drain is to create
flow connectivity to other flowing water. But I guess no one anticipated
that drains can have no flowing water and no connection to other
waterway features. The solutions that come to my mind: a) as you sad
have noexit=yes tag also for waterways, b) update JOSM validator so it
would account for cases when drain is stand alone, c) create new
waterway tag such as waterway=evaporation_drain that would not have the
validation check for connectivity.
On 14.2.21 8:12 , Bert -Araali- Van Opstal wrote:
>
> 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
>
> _______________________________________________
> 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/20210216/480695fa/attachment-0001.htm>
More information about the Tagging
mailing list