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