<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#333399" bgcolor="#FFFFFF">
<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">Tagging@openstreetmap.org</a>
<br>
<a class="moz-txt-link-freetext" href="https://lists.openstreetmap.org/listinfo/tagging">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">Tagging@openstreetmap.org</a>
<br>
<a class="moz-txt-link-freetext" href="https://lists.openstreetmap.org/listinfo/tagging">https://lists.openstreetmap.org/listinfo/tagging</a>
<br>
</blockquote>
</body>
</html>