<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#333399" bgcolor="#FFFFFF">
<p><font face="Verdana">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.</font></p>
<p><font face="Verdana">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.</font></p>
<p><font face="Verdana">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.<br>
</font></p>
<p><font face="Verdana">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 "</font><font face="Verdana">"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.</font></p>
<p><font face="Verdana"></font>Greetings, Bert Araali<br>
</p>
<div class="moz-cite-prefix">On 15/02/2021 01:33, Martin Machyna
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:08aea979-0e7b-ce30-9691-ae02c779002f@gmail.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<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"
moz-do-not-send="true">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" moz-do-not-send="true">Tagging@openstreetmap.org</a>
<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>
</pre>
</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>