[Tagging] RENDER

[Peter Wendorff]

Hi André,
Am 28.08.2014 um 01:41 schrieb André Pirard:
> Hi,
> 
> Thanks for your time, Peter, and for a message which I feel like the first to 
> want to cooperate.
> However, I don't feel well how your variants fit with the scenario I am dealing 
> with, namely:
> 
>   * a mapper has a feature to tag
>   * he finds the right tag definition
>   * but that definition has no rendering
>   * hence
>       o he uses an approaching but wrong definition that has a rendering
>       o or he uses RENDER *default* rendering (which could be refused).
As the second (using RENDER) requires that tag to be considered on
rendering, which I doubt will happen, I guess this collapses to the
first option only.
If there's really a map that uses RENDER, it's still "better" to use the
wrong tags as that occurs on more maps and applications in return.

> variant1: how could using right tags cause (using RENDER everywhere and) prevent 
> discussing new tags?
Not using right tags, but using RENDER.
OSM allows to use any tag you like. It's easy to invent a new tag, but
it's hard to get that tag understood to people, applications, styles and
their creators.
To invent a tag I open josm or iD and add the tag to some object in OSM,
that's all. To get it in use, I (up to know) have to discuss it with the
community, explain why it's worth to exist, why it's the best (or one of
the best ways) to be exactly how I defined it.

If RENDER is used by the rendering applications, I can step over these
discussions. I don't have to explain myself any more to others, I don't
have to agree on anything as suddenly I can decide how my objects are
going to be displayed.
Why should I still take the additional time and work to get the best tag
through? The worst that could happen would be that nevertheless my tag
get's adopted and my RENDER-tags aren't necessary any more, but that's
work for others, not for me.

That's why I think discussion of new tags would be prevented: there's
less motivation for it with a "default" tag like RENDER.

> variant2: you are extending the scope to other maps whose authors said they 
> won't support RENDER
? Sure I do, that's what we have no: nobody supports RENDER and people
keep tagging for their pet application. Why should that change due to
one or some maps or applications follow an additional
do-it-yourself-styling? Why should I stop tagging for the renderer just
because osm-carto would follow my RENDER-advice, when at the same time
Osmand doesn't show my features? Then I still tag them as shops as
that's used there.

> variant3: you'll never find a solution if it's not used
Sure ;) But nevertheless a possible outcome, as I didn't read any
response with a positive feedback from someone who said or I know to be
involved in the common map styles or applications.

> 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.
I don't understand what you want to say with that sentence, sorry...

> Thinking in the same direction as you did may raise some ideas like this.
> 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  
yes.
> 2)  the tags are just too varied to find similarly varied rendering
I don't think this is a reason. I would like to add three other ones:
3) Geometric space on the map is restricted, a map filled with any
possible object (in any zoom level?) has to omit something. It's better
to choose a subset of items to be shown, e.g. for thematic reasons (like
the public transport maps) or with an estimation what are the most
interesting features for the target user group.
4) A key part of maps is - well - the map KEY. This is mostly hidden on
OSM, but the background is, that a map should communicate meaning, not
nice drawings in the first place. Icons may communicate this meaning due
to well-known real-world images (like the shopping cart for a
supermarket, the burger for a fast-food "restaurant", knife and fork for
a restaurant); others may have to be explained, like the colors of
different roads, which is usually done by the map key.
While the map key is already a difficult part on osm and web maps, it
would get completely impossible to achieve with RENDER, as there's no
control and even less documentation, what is rendered in what way, and
conflicts of different things rendered the same way will occur.
5) A map showing any possible feature get's unreadable. With more than X
colors (where I guess X is below 100) most users cannot identify the
right meaning of color #5f32d8 as there are lot's of similar colors as
well. That's why different map styles are useful and benefitial.
RENDER - to achieve what you want - would have to be used by any map
style (as else people fall back to tag-for-the-renderer again); but if
it is used on any map style the decision of the style makers isn't their
own any more.

> 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.
> 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.
A mini-golf may be inside a park, but here mini-golf venues often are
fenced private areas dedicated to play mini-golf, whereas parks most
often are public areas where you go for a walk or to relax on the grass.
A fallback of mini-golf to park IMHO would be semantically wrong. Most
often the grassy surface and footways across are the same for parks and
mini-golfs, but not more.


> 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.
It fits with some kind of classes. What you described above is kind of a
"rendering class", which IMHO is not suitable as it's possible to define
different class hierarchies depending on the goal of your rendering.
Let's take a new type of barrier, where cars can pass, but bicycles
cannot (whatever that should be). Let's further assume there's a generic
barrier-rendering for unknown barrier types.
A cyclist would want that new barrier type to be rendered (and thus have
the fallback to generic barriers) while a car driver would not want to
(thus no fallback and no rendering at all).
Both options are wrong for the other one.

The Cyclemap-layer would of course decide for the cyclists point of
view, a car driver map would decide for the car drivers view, and a
general purpose map would either decide for any one of them or decide to
add a distinct symbol which communicates that difference to the user.

With a per-object defined class system instead the first barrier of this
new type would be classified by the cyclist and thus rendered, the
second one by the car driver, and wouldn't. A third one may have been
classified by someone aware of the conflict and thus rendered different
than other barriers, and a fourth one different again as the fourth
mapper was aware of the conflict, but didn't know about the fist
classifying stuff.

regards
Peter