[Tagging] remove “rendering” from proposal template

Bert -Araali- Van Opstal bert.araali.afritastic at gmail.com
Mon Apr 26 18:29:27 UTC 2021


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.

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

Same applies to data consumers.

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

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.
Suggestions and/or examples can be part of it, but the guidance should 
be primarily optimisation and compatibility with existing practices.

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.

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.

Greetings,


Bert Araali

On 24/04/2021 21:00, stevea wrote:
> On Apr 24, 2021, at 10:28 AM, Brian M. Sperlongano <zelonewolf at gmail.com> wrote:
>> 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.
> 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.
>
>> 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.
> 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.
>
>> 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.
> Totally "fixable:"  say the section is optional, say it shouldn't be critical for voting.
>
>> 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.
> 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
> Tagging at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20210426/07107b58/attachment.htm>


More information about the Tagging mailing list