<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">On 19/03/2015 2:44 PM, Clifford Snow
      wrote:<br>
    </div>
    <blockquote
cite="mid:CADAoPLo1ChcaiJGdw317feAqimtKNMSUQ8fzhy6yrgX-SPtgBQ@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra"><br>
          <div class="gmail_quote">On Wed, Mar 18, 2015 at 5:45 PM,
            Matthijs Melissen <span dir="ltr"><<a
                moz-do-not-send="true"
                href="mailto:info@matthijsmelissen.nl" target="_blank">info@matthijsmelissen.nl</a>></span>
            wrote:<br>
            <blockquote class="gmail_quote" style="margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <div id=":4qr" class="a3s" style="overflow:hidden">As far
                as I know, we don't have a policy on which tags to
                include in<br>
                the rendering, and there is currently no consensus
                within the<br>
                development team on what the best policy would be.
                Personally I'm<br>
                trying to steer towards requiring an accepted proposal
                plus<br>
                documentation on the wiki before rendering a new tag,
                but I know not<br>
                all of the developers share this point of view.
                Currently, proposals<br>
                for newly rendered tags are currently discussed on a
                case by case<br>
                base.</div>
            </blockquote>
          </div>
          <br>
          Requiring an accepted proposal plus good documentation sound
          like a reasonable policy. I would probably add, that the tag
          is sufficiently used, and/or be very desirable. It is
          interesting that developers are discussing which tags to
          render as well as being discussed on the tagging mail list. It
          seems like we should have the benefit of both discussions.
          While not all tags need to be, or even should be displayed, I
          wonder if it might knowing if a tag is likely to be rendered
          would have an impact the acceptance of tags. It shouldn't, but
          it might sway voting. </div>
        <div class="gmail_extra"><br>
        </div>
        <div class="gmail_extra">Even more so, the decision by
          developers to add the tag to editors. I would think that
          having a tag supported by JOSM and iD would more quickly lead
          to its acceptance. Conversely, not including the tag could
          result in it being one of the many tags with limited use. </div>
        <div class="gmail_extra"><br>
        </div>
        <div class="gmail_extra">Voting is all well and good, but it
          seems like we need to encourage dialog with developers to
          support new tags or understand why they don't think the tag is
          worthwhile of their time and effort. I feel that voting should
          be just part of the approval process. If we, the mappers, feel
          like a new tag should be adopted, then we should make sure
          that developers share our belief. I am not saying that
          developers need to be part of the initial dialog. We would
          probaby scare them off from ever taling to us again!</div>
        <div class="gmail_extra"><br>
        </div>
        <br>
      </div>
    </blockquote>
    <br>
    I don't think renders will be interested so much in tags with low
    usage. And at the start new tags have low use thus they don't get
    rendered. Catch 22. So renders may not actually be too interested in
    the making of new tags? <br>
    <br>
    To me (and I'm not a render) I'd render things that had a good wiki
    page with some idea of how to render it, lots of use and some
    'significance' to the map .. the 'significance' will depend on the
    render and their desired application. For example cycle maps might
    include 'bicycle repair station' despite the low usage. <br>
  </body>
</html>