<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>