Talk:Proposed features/ban deprecated tags

From OpenStreetMap Wiki
Jump to navigation Jump to search

No

Just no. --Brian de Ford (talk) 13:02, 21 March 2021 (UTC)

Misleading info

"Key:diaper has been flagged deprecated. It would be complete nonsense to use it because no data customer will process that key, nor will convert it to something usable."

See for example https://github.com/openstreetmap/id-tagging-schema/blob/fe5f19d0b6832c7aa4f2f2be5c22f6b007dd029b/data/deprecated.json#L482 where iD (this is both editor and data consumer, for rendering purposes) converts diaper tag to changing_table tag Mateusz Konieczny (talk) 13:19, 21 March 2021 (UTC)

I don't understand your message. different QA tools including the iD validator do indeed display information about many deprecated tags. but that doesn't make it a use of the data, adding an object with diaper=* is still irrelevant, right? Marc marc (talk) 19:43, 30 March 2021 (UTC)
Note "nor will convert it to something usable" claim. QA tools and rendering in editors are one of data consumers. And it is not hard to find deprecated tags still processed by various data consumers anyway Mateusz Konieczny (talk) 20:12, 30 March 2021 (UTC)

Rationale missing

Which problem is solved here? Because I am missing what is being solved by that proposal. Mateusz Konieczny (talk) 13:20, 21 March 2021 (UTC)

reduce the confusion of the message ? the message says both don't use it but use it. but i agree with you that the description of the proposal is very confusing Marc marc (talk) 19:44, 30 March 2021 (UTC)
"the message says both don't use it but use it." rather "don't use it but you can if you really want" Mateusz Konieczny (talk) 20:13, 30 March 2021 (UTC)

Insufficient authority

In the discussion on the tagging list (https://lists.openstreetmap.org/pipermail/tagging/2021-March/060549.html) I made the point that while the mechanisms we have in place for tag discussion and voting are good enough to arrive at "recommendations", they are not good enough to "ban" or "strongly discourage" anything. A process that would arrive at such strong statements would have to be much more inclusive and have more checks and balances than the current simple wiki voting. --Woodpeck (talk) 10:03, 25 March 2021 (UTC)

Feature or attribute?

Feature in OSM usually means an object. You don't deprecate objects. In the warning box and the proposed rewording it appears to denote an attribute: tag or key. That is the main thing I would like to see changed.

Unsuitable proposals

Unfortunately, sometimes we've got formally approved proposals, which are not suitable for all affected objects all over the world (for example, author and all voters could just don’t know about all specific of topic). I think that it will be incorrect to force applying such proposals globally. Also I think, that good and well-developed proposals don’t need to be forced — you can see by yourself that most of deprecated tags are very rare in OSM database after a time. Most of mappers want to make OSM better, so they won’t use deprecated tags just to spite others — most likely they just don’t know about the new one, or have significant reasong for using old scheme.

If you additionaly want to motivate people to use the new tags, then maybe this variant will be better:

This feature has been labeled as deprecated. The recommended replacement is: changing_table=*.

The reason is documented in Deprecated features. Please, consider using the replacenent, if it suits your case, but if you have reason — you are free to use the old one, because since OpenStreetMap does not have «banned features». Under no circumstances should you (semi-)automatically change «deprecated» tags to something else in the database on a large scale without conforming to the Automated Edits code of conduct. Any such change will be reverted.

The main idea is that we should mean something like: «Hey, guy, we have a new good tagging scheme, so if it meets your needs — why don’t you start to use it?»

AnakinNN (talk) 18:50, 29 March 2021 (UTC)

but when this is the case, shouldn't the depreciation be cancelled? we saw the case with fenced=yes, discussed on tagging. or there should be a new status for uncontested depreciations or even for tags that have been fully converted in their replacement Marc marc (talk) 19:46, 30 March 2021 (UTC)

How does the ban/discouraging work

First things first: As far as I understand you want to extend the API to verify that the uploaded data does not contain any deprecated tag? If not, please ignore the following and explain what I misunderstood.

The proposal says "It mustn't be done by a strict ban but it can be done by discouraging new entries from being made [...]". So I have two questions:

1.) How would a "ban" look like? Does the API call return an HTTP-error saying "Bad request: Usage of deprecated tag A=B"? Does that only apply for changed/added tags or also for existing ones that haven't been touched? How will the current editors iD, JOSM, Potlatch, MAPS.ME, etc. react to such HTTP-error? How should they react?

2.) How would "discouraging" look like? Also via an HTTP-error since there's no HTTP-warning? Via validation checks within the editors? How exactly should that look like, am I still able to upload my data by clicking a "yes I really want to upload"-button? And as above, does this verification only consider changed/added tags or also existing ones? --Hauke-stieler (talk) 17:35, 31 March 2021 (UTC)

Note: mentioning of filtering/blocking at API level was mentioned in mailing list discussion (if anyone is curious how this appeared here) Mateusz Konieczny (talk) 07:57, 1 April 2021 (UTC)