<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>1) I guess it is ok to add it to the water=* page in a separate
section mentioning that <font face="Verdana">water=stream was not
a part of the original proposal.</font></p>
<p><font face="Verdana">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.</font></p>
<p><font face="Verdana">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.</font></p>
<p><font face="Verdana">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.<br>
</font></p>
<p><font face="Verdana"><br>
</font></p>
<p><font face="Verdana"><br>
</font></p>
<div class="moz-cite-prefix">On 14.2.21 8:12 , Bert -Araali- Van
Opstal wrote:<br>
</div>
<blockquote type="cite"
cite="mid:3c4ddc3a-727d-3b0c-4b4d-c7aa54a3a8ce@gmail.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<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>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" 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>