<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">Hi,<br>
      <br>
      Thanks for your time, Peter, and for a message which I feel like
      the first to want to cooperate.<br>
      However, I don't feel well how your variants fit with the scenario
      I am dealing with, namely:<br>
      <ul>
        <li>a mapper has a feature to tag</li>
        <li>he finds the right tag definition</li>
        <li>but that definition has no rendering</li>
        <li>hence <br>
        </li>
        <ul>
          <li>he uses an approaching but wrong definition that has a
            rendering</li>
          <li>or he uses RENDER <b>default</b> rendering (which could
            be refused).<br>
          </li>
        </ul>
      </ul>
      variant1: how could using right tags cause (using RENDER
      everywhere and) prevent discussing new tags?<br>
      variant2: you are extending the scope to other maps whose authors
      said they won't support RENDER<br>
      variant3: you'll never find a solution if it's not used<br>
      variant4: RENDER is of course not a way to be able to tag x=y
      render=yes nor to choose colors; mappers are supposed to use
      defined and appropriate tags.<br>
      <br>
      Thinking in the same direction as you did may raise some ideas
      like this.<br>
      The lack of rendering may have two reasons that lead to the same
      idea: 1) lack of time for rendering to follow the tag production
      rate  2)  the tags are just too varied to find similarly varied
      rendering<br>
      Both lead to think of classes of objects inside which each new
      object would be put.  If an object has no specific rendering, it
      would inherit the rendering of its class.<br>
      For example, getting back to the mini-golf, it could inherit the
      rendering of the class called "ground", or "park", whatever you
      prefer but rendered. It can be refined to a proper mini-golf
      later.  In fact, it's nothing more than render=park, but possibly
      out of user control if that's what hurts.<br>
      <br>
      But the big, big problem with new tagging is the OSM theory that
      each user can invent his own tags and that they look at each other
      later in hope that they did the same things. That can be
      compatible with RENDER but certainly not with classes.<br>
      <br>
      Well, I said I would stop.  I'll let you think.<br>
      Best regards,<br>
      <br>
      <table>
        <tbody>
          <tr>
            <td>André.</td>
          </tr>
        </tbody>
      </table>
      <br>
      On 2014-08-27 19:09, Peter Wendorff wrote :<br>
    </div>
    <blockquote cite="mid:53FE10D2.8040606@uni-paderborn.de" type="cite">
      <pre wrap="">Am 27.08.2014 um 17:49 schrieb André Pirard:

</pre>
      <blockquote type="cite">All the replies in this thread showed
        absolutely no desire to join the
        fight and make suggestions, just to disparage the idea.
      </blockquote>
      <pre wrap="">I don't agree here.
But the way you proposed for this fight is not a solution.
It may be if what you call (and many see as) "the default osm map",
namely the mapnik, now osm-carto stylesheet, would use the render-tag,
but only partly.

Let's imagine "the map" would support RENDER.

variant 1) people stop using wrong tag to "tag for the renderer", and
instead use RENDER=* to get the image they want. This only works partly,
as the selection in cases of restricted place on the map cannot be solved.
As a result there may be now semantic tagging for new stuff as it's more
easy to use RENDER everywhere to get what I want than to propose and
discuss new tags.

variant 2) people use RENDER, but as render is not sufficient to support
garmin maps, osmand, nominatim and others, keep tagging for the renderer
to get their features used there as well

variant 3) nobody uses RENDER, then it's useless of course

variant 4) the best case would be that people use RENDER only on objects
where there is no "right" tagging (yet). In this case it slows down tag
inventions and clutters the map view by many inconsistent rendering
rules, as you add a feature X somewhere in the world and let it be
rendered in red, I add a feature X somewhere else and want it to be
rendered blue, and some other mapper doesn't care about rendering and
adds a feature X without RENDER-tag. Render would even reduce the
motivation to invent and "standardize" new tags, as it's not necessary
any more to get something new on the map.

To summarize: Why do you think RENDER would have any benefit?
I mentioned the drawbacks of it:
- less motivation to get consensus on new tags
- very limited motivation not to tag (wrong) for the renderer any more
- inconsistent map views as a result of inconsistent RENDER-tags for the
same object types

I like the idea to tackle the tagging-for-the-renderer, but all
arguments FOR the RENDER-tag I read yet (if I didn't miss any) are IMHO
countered by the explanations and assumptions above, feel free to
correct me if I'm wrong and add real benefits of RENDER.

regards
Peter

_______________________________________________
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>
    <br>
  </body>
</html>