[Tagging] Feature Proposal - RFC - Discouraging the use of deprecated schemes

Mon Mar 22 14:39:11 UTC 2021

On 22/03/2021 03:33, Robin Burek wrote:
>
> Am 21.03.2021 um 17:57 schrieb Bert -Araali- Van Opstal:
>
>> The warning message which we show at the top of "deprecated" tags is 
>> to dominant.  It should be removed.  In essence, deprecation, banning 
>> is all contra-productive when it comes to improving tagging and 
>> achieving consensus, let us work together instead of against each 
>> other.  Not emphasize that practices and tactics exist that go 
>> against core OSM values as free and open and community engagement, 
>> incite activities and give people ideas how to undermine them.
>>
>> A description can be given with a link to the deprecation wiki page 
>> in the "When to use" or "Usage" section.
>>
> I think the warning message can't be flashy enough - otherwise it 
> wouldn't be a warning message. A mention anywhere in the text is 
> forcibly overlooked. You should make it clear that one day after the 
> consensus of the community is no longer up to date. Especially for the 
> "casual mapper" who doesn't follow a thousand mailing lists or forums.
>
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 !
>>
>> We should also remove it from the proposal process.  Deprecation, and 
>> the process of how to determine if the community supports the 
>> deprecation of a certain tag, should not be promoted by advocating it 
>> through Organised Mass or (semi)Automated edits.  But it comes to 
>> those extremes in many proposals we see today. So we should ban it 
>> from the proposal process.
>>
> But now I disagree with you. Yes, you can freely map everything here. 
> But at the same time it is part of consensus-building processes that 
> not only new, uniform keys or values are found, but that these also 
> replace others. To exclude this would clearly lead the proposal in 
> some places extremely ad absurdum.
>
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 
authorithy.  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.
>
> You would disperse the database more and more and in the end destroy 
> the data for data users to such an extent that one is more fixed than 
> further development can take place. Data users and renderers simply 
> need good documentation and, above all, a uniform database. And 
> unfortunately both things are often produced very sparsely here. And 
> OSM is a database, and it is also a task of a database to save and 
> output data consistently.
> You would do away with the database itself if you take away its 
> structure and "uniformity".
>
I am not contesting the structure of our database.  But it is very 
simple, key:value, nodes ways and relations.  OSM is a web tool to store 
World Geograhic Information by contributors all over the world, a 
relational database is used as it's backbone, but as far as I am 
concerned that could be anything else. The database or infrastructure 
should serve the purpose, not the other way around. That's in my opinion 
why we don't map for the data consumer or the renderer.
"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.
>
>
>> This might mean that you will see during prolonged periods duplicate 
>> and competing tagging schemes, but I personally see no problem in 
>> that.  Neither for data consumers or renderers, they decide 
>> independently what they render, what and how they process our data.
>>
> Referring to my previous paragraph: How should the data user decide if 
> there is no uniform basis for decision-making?If it were up to you, in 
> the future I could mark all my streets with the key "road" instead of 
> "highway". That would be okay, because the mapping is free and the 
> data users and renderers have to be able to handle it if they want to 
> use it sensibly. (Yeah that's an exaggeration, but effectively it 
> would come down to something like that)
>
Yes, perfectly OK. Actually I am glad you mention this example, as I 
recently started a "QA" initiative on road.  I don't go around OSM and 
force replacement of the key, I ask every user or the community 
individually if they consider highway not as more suitable, because of 
better support and easier to process for QA. And guess what, 90% of them 
agree and spontaneously do the replacement themselves.  That is what I 
call consensus, awarenes, collaboration.  And the few remaining where I 
don't get any answer I leave them as such.
Data consumers and renderers should refer to approved and promoted 
tagging schemes as the standard. Where most of the data is added, data 
intended to be used worldwide.  But local variants may exist, may 
purposely be invented just with the intend not to be processed by the 
"standard" renderer or data consumer.  But who am I or you or any other 
contributor to decide to just deprecate or ban or replace them ?

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 limitations.
>
>
> 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.
>
> _______________________________________________
> 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/20210322/15717135/attachment-0001.htm>