<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>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:
<a class="moz-txt-link-freetext" href="https://wiki.openstreetmap.org/wiki/Tag:water%3Dstream">https://wiki.openstreetmap.org/wiki/Tag:water%3Dstream</a><br>
</p>
<p>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. </p>
<p>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. <br>
</p>
<p>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 <font face="Verdana">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. <br>
</font></p>
<p><br>
</p>
<div class="moz-cite-prefix">On 14.2.21 2:16 , Bert -Araali- Van
Opstal wrote:<br>
</div>
<blockquote type="cite"
cite="mid:306fda28-c337-d553-f10b-ed74737249c8@gmail.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<p><font face="Verdana">I am strong against to deprecate
waterway=river_bank in favour of natural=water and
water=river:</font></p>
<p><font face="Verdana">- 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;</font></p>
<p><font face="Verdana">- 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.</font></p>
<p><font face="Verdana">- 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.</font></p>
<p><font face="Verdana">- 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
?</font></p>
<p>So I am in favour of deprecating waterway=river_bank in favour
of natural=water if we find reasonable solutions for the above
issues.<br>
</p>
<div class="moz-cite-prefix">On 14/02/2021 21:41, Martin Machyna
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:3c8ebe1f-d46c-7828-c4b5-e9218314a854@gmail.com">1)
merging of the schemes <br>
<br>
argument in favor: <br>
<br>
- more simple and unified database <br>
<br>
- no need to maintain two schemes <br>
<br>
- less confusing to new users <br>
<br>
- OSM would look more professional and reliable to current and
potential new adopters <br>
<br>
- resolved violation of "one feature one tag" rule <br>
<br>
<br>
argument against: <br>
<br>
- Lithuanian tool would not work <br>
<br>
<br>
2) which to keep <br>
<br>
water=river: <br>
<br>
- is approved <br>
<br>
- Would unify water=* subtree for water covered areas and
waterway=* for river network <br>
<br>
- Is currently more popular <br>
<br>
<br>
waterway=riverbank: <br>
<br>
- is currently more numerous <br>
<br>
<br>
On 12.2.21 10:38 , Marc_marc wrote: <br>
<blockquote type="cite">Le 12.02.21 à 16:18, Martin Machyna a
écrit : <br>
<blockquote type="cite">I don't see any advantage to keep both
other than someone's personal <br>
convenience. <br>
</blockquote>
I think the debate should be splited in two, especially since
at least <br>
one person is playing on both sides to say that at the same
time there <br>
is no problem to have a fragmentation since all the tools
manage both <br>
schemes and at the same time that it is very expensive to
eliminate one <br>
of the 2 schemes because some of these own tools only manage
one schéma. <br>
<br>
Unfortunately, apart from discussion, there is no way to make
a 2-step <br>
proposal: <br>
<br>
1) in favor or against the merging of the 2 schemes into a
single one <br>
<br>
argument in favor: reducing the loss of human time, increasing
coherence <br>
and therefore quality <br>
<br>
argument against: <br>
- communication (this is a point that needs to be improved) is
obviously <br>
more time-consuming in the short term than the status quo. <br>
- tools managing only one of the 2 will see their defect even
more <br>
visible depending on whether the remaining schema is the
supported one <br>
or the other (and in my opinion, it is not a argument against
so much to <br>
see the "design errors" rather than "if not too many
complaints, do <br>
nothing"). <br>
- the existing old books are frightening to some. (against
argument: <br>
if you type a tag in any correct editor, it tells you that it
is <br>
deprecated, so everyone knows how to update easily) <br>
<br>
argument neither for nor against: it will be necessary to
carry out a <br>
mass operation so that the gain above can be made, I'm willing
to take <br>
care of it. <br>
<br>
2) to choose the new scheme on the basis of the
advantages/disadvantages <br>
of each of them and no longer on the basis of "should
fragmentation be <br>
maintained or not". <br>
<br>
<br>
<br>
_______________________________________________ <br>
Tagging mailing list <br>
<a class="moz-txt-link-abbreviated"
href="mailto:Tagging@openstreetmap.org"
moz-do-not-send="true">Tagging@openstreetmap.org</a> <br>
<a class="moz-txt-link-freetext"
href="https://lists.openstreetmap.org/listinfo/tagging"
moz-do-not-send="true">https://lists.openstreetmap.org/listinfo/tagging</a>
<br>
</blockquote>
<br>
_______________________________________________ <br>
Tagging mailing list <br>
<a class="moz-txt-link-abbreviated"
href="mailto:Tagging@openstreetmap.org" moz-do-not-send="true">Tagging@openstreetmap.org</a>
<br>
<a class="moz-txt-link-freetext"
href="https://lists.openstreetmap.org/listinfo/tagging"
moz-do-not-send="true">https://lists.openstreetmap.org/listinfo/tagging</a>
<br>
</blockquote>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Tagging mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Tagging@openstreetmap.org">Tagging@openstreetmap.org</a>
<a class="moz-txt-link-freetext" href="https://lists.openstreetmap.org/listinfo/tagging">https://lists.openstreetmap.org/listinfo/tagging</a>
</pre>
</blockquote>
</body>
</html>