[Tagging] Feature Proposal - RFC - Discouraging the use of deprecated schemes
robin.burek at gmx.de
Mon Mar 22 16:18:51 UTC 2021
> True, a warning shouldn't be flashy enough. Although I would love
> too see the proposal process for guidelines to evolve more
> positively.Â Instead of a warning message you can put an
> acknowledgement or encouragement. Instead of being negative, be
> postive. We could put a very flashy message on top of a proposal
> that went through the discussion process and the talk group review
> process as:
> "This tag is considered as best practice. Use it if you like your work
> to be supported by other applications." Make it very flashy and green !
Nevertheless, you have to clearly indicate a consensus, also - or rather
especially - on the pages that are out of date.And a green message on
consensus pages won't help you if someone encounters a "deprecated"
element in the wiki - because they won't see the green message
elsewhere. As praiseworthy as the idea is, it won't really solve the
I wouldn't go along with a ban either, but reporting the consensus would
be really necessary - and that includes deprecating
> Its OK to disagree. I would refer to the Deprecation wiki page
> (https://wiki.openstreetmap.org/wiki/Deprecated_features). The
> deprecation process is there, and for good reasons as you say, which
> whom I agree. It's a process, a process of reaching consensus by the
> broader community, not by the few people of the tagging-talk page who
> join voting. As Fredrik said, that is a very small group, they have no
Then we should rather ask the question, how do you reach more people?
Information message about started proposals in JOSM and ID, ...?I
believe that if there is a complaint about this, we have to make this
process more public and give more people the opportunity to participate.
But only because so far a limited number has participated ..... Everyone
is free to participate.
> However we see that more and more people who make proposals there seem
> to think different. Proposals are more and more used to promote a
> certain tagging scheme popular in some country or region, as we've
> seen recently with the waterway=riverbank and natural=water
> water=river scheme.
> No consensus and approval could be reached even in the small group of
> tagging-talk. Yet, the process of "organic" deprecation is largely
> disrupted because a small group of people is calling for support to do
> the deprecation on a global scale, semi-automatically.
> That is completely against the process of deprecation described in the
> wiki. The worldwide community doesn't have a chance to express it's
> support, for or against. I think the proposal process should make
> suggestions, and advise if a certain tag could be deprecated, maybe
> even using words that are less stringent, like a "good replacement" or
> "good alternative" instead of proposing short term and mass
> deprecation of tagging schemes.
But that's what it's all about right now. There is no logical reason to
label the same thing with x different alternatives. And here it doesn't
help to water down the word "deprecated". Because in the end, that only
exacerbates the matter. And in the end you have to ask yourself as a
community - does the kind of "consensus finding" (75% right now) in an A
or B question make sense. I don't think so - and I had been thinking for
a long time how one could address something like this without stepping
on someone's feet. But especially here a meaningful new way of how
something can be coordinated may have to be found. And in the end that
might mean that we put 50 + 1 decisions in such "Let's use A or B as the
standard" in the entire community (via all mailing lists, the forum, the
OSM page itself) to vote . But I notice it in various inconsistencies
(contact * scheme, riverbank, etc): You let two identical ecosystems
continue to exist side by side and in the end there is always only
quarrel. It is precisely here that we need to find a democratic way of
> "Uniformity", well the World's Geographic Information is not uniform,
> it's very diverse. But that is OSM's purpose. We should not put
> restrictions or limitations for the sake of "Uniformity".Â Data
> consumers and renderers alike should cope and find a way to handle
> that "chaos". I am not saying we should strive to help them, by
> organically implementing some uniformity where possible, tagging
> scheme promotion, not deprecation, through proposals and well written
> wiki pages is a tool to achieve that.
Unfortunately, stroking everybody the head does not always achieve a goal.
And the aim should be to work towards a uniformity that makes sense for
MAPPER and data users.Sounds silly, but I really thought about it in
between - oh, why not map both of these A or B things in the future?
Then everyone is satisfied and no one feels trodden on the tie. Simply,
when acquaintances ask me: "What should I use there now?", I will
probably really answer in the future: "Take both. Before anyone feels
> But who am I or you or any other contributor to decide to just
> deprecate or ban or replace them ?
No, but the part of the community that wants to develop the tagging
scheme further and also harmonize it.How do we manage to detach this
process from the mailing list / forum and open it to the outside world.
One approach was made with the weekly, for example, but is that enough?
> Data consumers and renderers who want to cover to whole flora and
> fauna of tags that exist, sure go ahead, give it a try, live with it.
> Serve the purpose, don't limit it, because of your applications
>> All in all, a database must always have the right to map the data
>> correctly, but still free of contradictions. And that includes not
>> having five different tags for phone numbers, and someone uses a
>> sixth variant. But that you create uniformity for all sides. And some
>> then just have to jump over their shadow and are then urged, but
>> please to use something else. (You can anyway, but then the community
>> has every right to adapt this to the consensus)
> Databases have no rights, OSM contributors have rights respected in
> OSM, tag as you like, feel free.
Well, a right always goes hand in hand with a duty. And here I would say
that entered elements must also be understandable and evaluable - one
means of doing this is documentation (unfortunately not all of them
manage), another is also to be based on conventions.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Tagging