<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p><font face="Verdana">I am not a favourite of removing it neither
        of changing the title.  As we all know we don't map or tag for
        rendering, or propose new tags or mapping practices for
        rendering. Being the "Rendering" part of a "Proposal", taking
        these principles into account says enough.  Changing or adding
        titles or additional warnings or context doesn't help here I
        believe, just adds duplicate guidelines in different pages. 
        Keep the general principles n one place, the proposal process
        has it's own place and is all about "proposals", being
        suggestions, improvements or whatever you call it supported by
        examples.  People who write proposals should be aware of these
        principles in the first place.</font></p>
    <p><font face="Verdana">I would suggest to add some more
        clarifications of what the expectations are for the community
        and the voters of the contents in this section.<br>
        Does it consider that the proposal is a tagging scheme that
        breaks existing rendering, rendering not only in OSM-Carto but
        other major rendering engines, and how the proposer suggests
        this can be resolved.<br>
        Did the proposer take these impacts into account, or has several
        optional tagging schemes, on how it can be easily processed and
        visualised in renderers.  <br>
      </font></p>
    <p><font face="Verdana">Same applies to data consumers. <br>
      </font></p>
    <p><font face="Verdana">All to often, we see that discussions arise
        because the proposer is not interested or specialised in
        rendering or data processing, and neglected these, leaving out
        alternatives which might better suit all purposes, including the
        primary one that he wants to map and tag something new or
        improve the existing practices.<br>
        The "Rendering" and "Data consumption" sections can be extended
        or filled in during the RFC, supported with more specialised
        suggestions found from the community during RFC.</font></p>
    <p><font face="Verdana">I do believe that all these topics or
        sections should be part of every proposal.  Either as described
        or as "not applicable", so considered by the proposer and the
        community after RFC but saying not impacting or improved tagging
        because of possible rendering or data consumption.<br>
        Suggestions and/or examples can be part of it, but the guidance
        should be primarily optimisation and compatibility with existing
        practices.<br>
        <br>
        Voting has to be valid and accepted as arguments for or against
        rendering and data consumption, being it only to indicate your
        support for a well crafted proposal, were major impacts are
        considered and the tagging proposal is optimised taking these
        impacts into account.</font></p>
    <p><font face="Verdana">After the proposal process the proposals are
        retained.  Crafted in final tagging guidelines with OSM-Carto
        examples, overpass for data consumption.  The proposal with it's
        rendering and data consumption sections remains available and
        can be optimised if it turns out the implementation differs from
        the proposed, and can be used for further or future development
        of the proposal.  Feedback could be given by the programmers on
        the discussion page of the final tagging guidelines.<br>
      </font></p>
    <font face="Verdana">Greetings,</font>
    <p><font face="Verdana"><br>
      </font></p>
    <p><font face="Verdana">Bert Araali</font></p>
    <div class="moz-cite-prefix">On 24/04/2021 21:00, stevea wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:D8F4FC15-CDC2-44FB-9E63-16B7C978528F@softworkers.com">
      <pre class="moz-quote-pre" wrap="">On Apr 24, 2021, at 10:28 AM, Brian M. Sperlongano <a class="moz-txt-link-rfc2396E" href="mailto:zelonewolf@gmail.com"><zelonewolf@gmail.com></a> wrote:
</pre>
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">The information that I think we actually care about is:

* Does this proposal change the meaning of or deprecate existing tagging which is currently supported by data consumers/renderers?
* If yes, what will the impact be on those data consumers/renderers, and what is the proposed plan for transition, such dual-tagging, attrition, future mechanical edits, etc?

What we are really assessing in these cases is whether the cost (impact to data consumers) is worth the gain in approving the tagging change.
</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">
Here, as Brian zooms out from the specific issue of "remove or include 'Rendering' from Proposals?, and/or put the word 'Suggested' in front of it," he ask us (correctly, imo) to weigh whether skewing the Proposal in a particular rendering direction "is worth the gain in approving (it)."  This would be worthy to do, IF the "Suggested Rendering" were REQUIRED to be "strongly associated" with the Proposal.  But it doesn't have to be:  as a "suggestion," it is "weakly associated," this section is optional, it could even be blank.  It does not have further dependencies on whether it cripples or dooms the entire Proposal simply because this particular Rendering Suggestion is (or is not) "worth the gain."  The entire reasoning for this, and why it even works in the first place, is because these ARE "suggestions."  These ARE "optional," and don't cripple or doom the proposal if the Rendering Suggestion is way off base or doesn't get adopted by a renderer author.  These are simply the (optional) ideas / suggestions for rendering by the proposal author, maybe they help someone voting "visually get it" (better), maybe they don't.  But they do this because we change the proposal template to say "Suggested" and "this is all optional, ultimately renderer authors make these decisions."

This really is related to why when we map with tags, we shouldn't tag for the renderer.  As we map with tags (use syntactically-correct sentences, like entering into OSM a well-tagged multipolygon), we allow the semantic interpretation of that syntax (tagging) to happen in the renderer.  Syntax has its realm:  that of mappers who "know and/or can see that something exists in the world to be mapped" and semantics has its realm:  that of renderer authors who interpret tags (well-uttered, syntactic "sentences") and then display them.  Recall that any of us are free to write our own renderers that emphasize and/or ignore certain syntax as we see fit for our particular desire to visually represent underlying data in the map.  A "Hiking / Camping Map" renderer author decides "I want to show what hikers / campers need to see" and so all sorts of data in the map not important to those use cases are (largely) ignored.  And if a suggestion for a syntax feature that deserves to be seen in this rendering doesn't "look right" in its wiki (perhaps derived from a Proposal that is Approved) s/he is free to modify or exclude it.  This is the renderer authors call, and rightly so.

</pre>
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">For truly brand new tags, if a proposal author wants to do an art project to show how they think it should render in Carto because they think it makes the proposal more compelling, I guess that's fine, but having it as an explicit section makes new proposers think it's expected.
</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">
All we need do is specify in the Proposal Template that "Rendering Suggestions" aren't expected to be followed exactly, these are merely suggestions to renderer authors, who really do have say in how this will or won't get rendered (including and especially in our Standard renderer, Carto).  And again, this section is optional, it can even be blank / empty (it should say so, if so).  When included as a Proposal, its specifications aren't required.  When included as a Proposal and is being considered by someone about to vote Approve or Oppose, this section must not be used as a "make or break" decision input.  We can clearly state all of this with good language in the template, and I think with "Proposal Suggestion" and "this is optional, not required" and "don't use this section as a determination in your vote..." we're mostly there.

</pre>
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">It also risks people voting against the proposal because they don't like the rendering suggestion, or don't think it should render in the default map at all, which is an independent question from how to tag things.  It also discourages people that are not artistically inclined from writing proposals if they feel that a sample rendering is expected.
</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">
Totally "fixable:"  say the section is optional, say it shouldn't be critical for voting.

</pre>
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">I would rather see proposals clearly and squarely focus on the modeling and data structures, with strong, compelling examples, versus back-door Carto rendering requests.
</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">
Now that you mention "back-door rendering requests," (I agree that sort of "hijacking" has been attempted before and should be heartily discouraged going forward), we might mention that this section (Suggested Rendering) is absolutely no place to be trying to force any particular rendering, as doing so is not the realm / domain of proposal authors.  It is squarely the realm of renderer authors.  (On rare occasion this might be the same person, but the roles, the "which hat is being worn?" are clearly one or the other).

We can do this.
_______________________________________________
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>