[Osmf-talk] Tagging standards and different problems

[grin]

On Thu, 20 Oct 2022 10:27:09 +0200 Martin Koppenhoefer <dieterdreist at gmail.com> wrote:
> > On 20 Oct 2022, at 01:57, Craig Allan <allan at iafrica.com> wrote:
> > 
> > To avoid the same tag identifying different features we need to collectively set just one rule. "No two different mapped features may be identified by the same tag"  
> 
> this is assuming we all know what a feature is and how it is defined/which are its core properties that must not miss. This is not so often the case on a global level.
[...]
> it may be ok to have different tags for what is all called a “bar” locally, but as long as we don’t define well what’s the meaning of the tags, we won’t know. 
[...]
> The question in this kind of discussion is usually: what constitutes a feature, what are the defining properties and what is optional or indicating a different kind of feature. 
[...]
> Generally, and because we all know that multiple tags for apparently the same or very similar features aren’t a big deal, 
[...]
> Ah, and presets of course. The preset concept as a whole leads to many square pegs pushed in round holes, as in “it is clearly the most pertinent feature class of all available”. 

I believe there is some need to define what we're actually talking about, since there are 
various problems and approaches to that specific problem.

1. using different keys for the same (or similar) purposes
2. using a key for the similar purposes but variance in values (tags)
3. using a key for dissimilar features
4. using values of a key (tags) for significantly different interpretation of an attribute
than general or global usage, especially in case of widely used keys.
4b. ...especially when there is a widely used key and someone (or a group of someones) start
to use it for a different purpose or redefine widely used values.
5. documenting widely accepted usage in the wiki, and whether this shall stop people from
using the key for different features, or use the documented values with different
interpretation.

I believe #1 is the normal way of OSM and relatively simple (though tedious) to resolve in software. 
It is definitely not a "problem".

#2 is often a problem, especially since OSM is used globally, and we expect renderers and data users
to gather localised but often underdocumented interpretation and conversion of a lot of values (tags).
This cannot be prevented but data consumers would be much happier if this use would be documented
more often than not. Example may be tracktype=*, highway=service or smoothness=*.

#3 is a huge problem for automatized data consumers, including renderers, unless there is a mechanically
unquestionable way to differentiate between uses (like opening_hours for a restaurant vs. a gate, which
has very different meaning but it's obvious from the tagging which one we're tagging). The mentioned
highway=secondary for something which would be tagged 
"highway=path + smoothness=horrible + trail_visibility=horrible" is one case where the international 
consumers general and worldwide expectations miserably fail interpreting the tagging, which is pretty
harmful.

#4 is a huge problem. I call it "IMDB stars problem", since my best example is IMDB, where it isn't
defined whether "5 star" means "unwatchable" "meh" or "average", and it causes a very uneven and
pretty uninterpretable distribution of the values, apart from "towards good" or "towards bad". 
Most subjective tags where the value interpretation isn't wiki'd or inserted into JOSM presets
are suffering from this: some people think "smoothness=bad" means a road which is okay for a 
city bike and others imagine it as something only Superman could fly over it. It is a huge
help when someone says "it means the road is okay for light utility vehicles but not for normal
cars or city bike", since people can quantize their subjective observation more or less similarly
to everyone else's.

#4b is evil. It is not forbidden, it's just causing harm without need.

#5 is what I prefer. It shall not be compulsory, it shall not be exclusive, it shall not be The Law.
It is a guide, a help for those who would like their data to be interpretable by everyone else,
not just themselves and their neighbours. Doesn't have to define _all_ the keys, or _all_ the values, 
just enough to cover widely used ones, which would be used by lot of people.
People can still choose not to follow it, but they shall bear in mind what it causes to others, and
whether it's really necessary or not.

my 2 'cents.

g