Proposal:Deprecated and unsupported status

From OpenStreetMap Wiki
Jump to navigation Jump to search
Deprecated and unsupported status
Proposal status: Abandoned (inactive)
Proposed by: Overflorian, Gendy54, Fanfouer
Applies to:
Definition: Advice mechanical edit to get rid of deprecated tags after 2 years of close follow-up
Draft started: 2021-12-08


This proposal has been abandoned on 2021-01-03. We've learn a lot while writing itː

  1. the deprecation process is messy, unclear and sometimes, ineffective. There isn't any follow-up of the deprecation process by the community. Sometimes, it takes up to 10 years for an effective deprecationǃ This is an absolute necessity that we, as a community, address it. As a first step, we created a new page to better manage the Deprecation process and to follow-it-up.
  2. we miss a better understanding of the already deprecated tags and the process that leaded to that. A more precise analysis should be produced.
  3. the definition of some status are unclear, leading to misunderstanding. We understood that deprecated and unsupported status would lead to more confusion. Instead, what is the exact difference between in use and de facto status? How to differentiate a properly voted deprecation with a de facto deprecation? This should be clarified in our new proposal.
  4. the inconsistency of the deprecation information in the wiki is a nightmare. The info is inconsistent between different languages but also different pages, between the wiki and the data items. This should be addressed.
  5. the data items are key to smother the communication between the community and all the downstream projectsː renders, editors and other tools. We should make sure to update properly the data items and promote its use in all projects using the data.
  6. the Any tags you like policy is a good one. For now, we don't see any good enough reason why we should setup automatic deprecation managed by bots

As a conclusion, the system should not be transformed to become a cathedral but rather organize better the current bazaar.


This is a collective proposal from three French contributors:

Proposal overview

We propose to create a new "deprecated and unsupported" status. This new status would be active 2 years after the deprecation's date of the tags.

This 2 years period is a smooth transition buffer during which the already existing deprecated status would apply, and a transition plan would be setup to get rid of the deprecated tag:

  1. On the deprecation day
    • only the approved tag would be recommended as standard in the editors and tools
    • QA tools such as Osmose are recommended to display a suggestion of getting rid of the deprecated tag
    • renders are recommended to keep supporting both approved and deprecated tags
    • the documentation would still mention the 2 tags as currently in use, recommending to use the approved one, with a clear mention of the up-coming "deprecated and unsupported" date
    • the documentation would detail a transition plan to help the community keep track of the transition
  2. After 1 year
    • an automated edit would be recommended to add the approved tag on all objects using the deprecated tag, in accordance with Automated code of conduct
    • the render are recommended to drop support of the deprecated tag, displaying only objects with the approved tag
  3. After 2 years
    • the new "deprecated and unsupported status" would apply
    • an automated edit removing deprecated tag would be recommended in accordance with Automated code of conduct
    • the documentation would mention the "deprecated and unsupported" tag as an historic feature
    • a new "deprecated and unsupported" warning box would be displayed on the wiki page of the "deprecated and unsupported" tag

At every step of the process, safeguards would be setup to prevent any wrong move.

Detailed proposal

The proposal creates a new "deprecated and unsupported" status and a new transition plan to ensure a better transition of unsupported tags.

Current situation

Today, a Proposal process leads to an approval/rejection decision to replace a deprecated tag. Once a tag is declared deprecated, little follow-up is given to make sure the community get rid of it.

Documentation

When existing, the documentation regarding deprecation process is poor and inconsistent. See for example the pages Tag:amenity=swimming pool, Tag:access=public, Tag:amenity=advertising

Examples of previous deprecation cycles

Let's review some examples of what happened after previous votes:

  1. Most of the time, the transition is smooth (but it could take many years):
  2. In many cases, even if the use of the deprecated tag increases, the use of the new tag takes over:


Current situation - deprecation cycle.png


As you can see, all these examples are very heterogeneous (which, in and for itself isn't a bad thing) but also very unpredictable.

This proposal is about improving the life-and-death of tags cycle, improving the predictability of tag use without hurting the community.

Create a buffer period

The buffer period would allow the community to adapt its tools and methodology to the new approved tag. 2 years is a long enough time range for any possible scenario. It allows even the biggest IT projects to plan a transition without any continuity break.

It also allows the community to act according to the following transition plan.

Transition plan

We propose to setup a new transition plan for every deprecated tag, starting from the deprecation's date.

Proposed process.png


In detail:

  1. From deprecation day:
    • Update the deprecated tag wiki page (for every available language)
    • Update the approved tag wiki page (for every available language)
    • List the deprecated tag on the deprecated features page (for every available language)
    • Update every single page mentioning the deprecated tag
    • Update the deprecated data item (at least for English)
    • Update the approved data item (at least for English)
    • Send a request for changing the presets of the Editors: main ones (JOSM, ID, Vespucci, etc...) and the specific ones regarding the specific topic of the tag
    • Send a request to create validators for the main editors and QA tools (JOSM, ID and Osmose) suggesting to replace or delete the deprecated tag
    • Send a request to render (standard tile layer ...) to support the approved tag
  2. One year after deprecation day:
    • Recommend mechanical edit to add the approved tag to any object tagged with the deprecated tag in accordance with Automated code of conduct
    • Send a request to render (standard tile layer ...) to drop support of the deprecated tag
  3. Two years after deprecation day:
    • Recommend mechanical edit to remove the deprecated tag to any object tagged with the approved tag in accordance with Automated code of conduct
    • Update the deprecated tag wiki page (for every available language)
    • Update the approved tag wiki page (for every available language)
    • List the deprecated tag on the deprecated features page (for every available language)
    • Update every single page mentioning the deprecated tag

As it's too much work for a single person, we feel like the person that made the approved proposal should not be in charge of it alone. It should be a community effort. Therefore, the follow-up of the transition plan would be directly displayed on the deprecated tag wiki page.

Perimeter

This proposal strictly applies to deprecated tags approved by a proper community vote. Having a page with such a vote should be the only but necessary requirement. Therefore it does not apply to "not-clearly" deprecated tags such as waterway=riverbank, marked as deprecated in the doc (data items, wiki pages...) but not deprecated with passed proposal, informally deprecated (on a mailing-list for example) or other cases.

Exceptionː same key

Sometimes, the key of the approved tag remains unchanged. Only the value is modified. For example landuse=school was replaced by landuse=education.

For this exception, the planned mechanical edit one year after deprecation should not be done. Indeed "add the approved tag to any object tagged with the deprecated tag" would lead to replace all tags. And we want that after 2 years, not 1.

Transition follow-up

A proper follow-up table should be directly added on the deprecated tag, as described hereː Deprecated features follow-up#Original table

For the purpose of this proposal, it has been successfully tested for some transitionsː

A new wiki page "mechanical edits for deprecation" would list all the mechanical edits planned and pasts regarding deprecation.

Note: we are aware that translating into every language could be an issue. It might be fully addressed in another proposal. As a first step, we propose to copy/past the English version in every language page. The local community should address the translation on its own later. The important fact is that every single wiki page mentioning the deprecated tag should be up-to-date.

Mechanical edits: preliminary precautions

The transition plan includes mechanical edits. Mechanical edits without control could lead to dangerous changes for the integrity of the database. Therefore, strictly defined mechanical edits should only be recommended.

In particular, for such edits, the following requirements should all be fulfilled:

  • every task of the transition plan is fully completed on time
  • strictly switch the "deprecated and unsupported" tag to its new approved tag. More precisely:
    • mechanical edit after 1 year:
      • if only the deprecated tag is used, the approved one should be added
      • if both tags are used, nothing should be edited
      • if only the approved tag is used, nothing should be edited
    • mechanical edit after 2 years:
      • if only the deprecated tag is used, it should be replaced with the approved one
      • if both tags are used, the deprecated tag should be removed, the approved one should remain
      • if only the approved tag is used, nothing should be edited
  • be listed and documented like any other standard mechanical edit as a separate wiki page
  • follow other requirements of the Automated Edits code of conduct
  • the approved tag should exactly replace and describe the same object. Example of proposals that do not fit this definition:

If it strictly matches all these requirements, a mechanical edit should be recommended without any prior discussion. Indeed, the details of these changes are agreed in advance in this proposal.

Of course, such mechanical edits should be anticipated. The 2 years buffer time should be used by the community to plan any expected complication (see "managing transition for currently deprecated tags" below for some examples).

Fixed date ("Old tags saint's day") as the end of the buffer period

We propose to set a fixed date as the end of the 2years buffer period. It would bring much more predictability for all. Also a single annual review of the deprecated tags would be necessary for all the users. Also, the tools/render developers and data users being aware of the process are more likely to take community's votes into account in the future.

Let's set the 1st of November as an new "Old tags saint's day". Indeed 1st of Nov. is "All Saints' Day", it's a perfect date for a farewell to old, brave but yet deprecated tags.


Every year on "Old tags saint's day", the community will bring together to review the on-going deprecation process. More precisely, the community will execute the actions planned 1 and 2 years after deprecation.

Managing transition for currently deprecated tags

The currently deprecated tags should be considered, one at the time, to be included in the process to become unsupported and deprecated. We should apply the transition plan if the tag fits all conditions, and the 2-year period would be counted from the date of approval of this proposal. As a consequence, the following 2 years should be dedicated to progressively cleaning up the already deprecated tags.

List of already deprecated tags that respect all criteria:

Deprecated tag Approved tag URL of approved deprecation vote Trend
amenity=register_office office=government + government=register_office Proposed features/Government offices comparison 400 vs 4800 objects
amenity=shop shop=* Proposed features/Shop (rather than amenity=shoptype above) amenity=shop

shop deprecation must be manual -> shop=butcher, shop=bakery, ...

bridge=suspension bridge=yes + bridgeːstructure=suspension Proposed features/Bridge types bridge=suspension -> 374 objects

bridge:structure=suspension -> 3614 objects

escalator=* highway=steps + conveying=* Proposed features/Escalators and Moving Walkways escalator -> 300 objects

overpass : node+way[highway=steps][conveying] gives 16300 objects

hazard=air_traffic hazard=low_flying_aircraft Proposed features/hazard#Features.2FPages affected comparison deprecation not really done 100 vs 30 objects
hazard=dangerous_turn hazard=turn Proposed features/hazard#Features.2FPages affected comparison deprecation not really done 450 vs 130 objects
hazard=deer hazard=animal_crossing + hazard:animal=moose Proposed features/hazard#Features.2FPages affected comparison deprecation process started
hazard=reindeer hazard=animal_crossing + hazard:animal=reindeer Proposed features/hazard#Features.2FPages affected comparison deprecation process not really started
hazard=rockfall hazard=falling_rocks Proposed features/hazard#Features.2FPages affected comparison 150 vs 180 objects. Acceptation under way
hazard=rock_slide hazard=landslide Proposed features/hazard#Features.2FPages affected comparison 400 vs 5000
hazard=slippery_road hazard=slippery Proposed features/hazard#Features.2FPages affected comparison 220 vs 570 objects
hazard=wild_animal hazard=animal_crossing + hazard:animal=wild_animal Proposed features/hazard#Features.2FPages affected comparison acceptation not yet obvious
hazard=wild_animals hazard=animal_crossing + hazard:animal=wild_animal Proposed features/hazard#Features.2FPages affected comparison deprecation process under way
landuse=pond natural=water + water=pond Proposed features/Water details#Deprecation comparison 400 vs 1 400 000 objects
landuse=reservoir natural=water + water=reservoir Proposed features/Water details#Deprecation comparison in a good way but still many 320k vs 440k
landuse=school landuse=education Proposed features/Multiple schools on one ground comparison in a good way 4000 vs 7000 objects
office=administrative office=government Proposed features/Government offices comparison 10k vs 190k objects
office=tax office=government + government=tax Proposed features/Government offices comparison 200 vs 4700 objects
post_office:type=* post_office=* Proposed features/shop as post-partner post_office:type decreases but still 13000
waterway=riverbank natural=water + water=river Proposed features/Water details#Deprecation waterway=riverbank from 330k to 30k within 3 years but is it automatisable ?

Tags already deprecated with occurrence under 100 worldwide are not listed below. They are part as the long tail, therefore they remain part of the proposal and should be managed later with the same rules. For exampleː bridge=arch, bridge=beam, bridge=humpback, hazard=crosswinds

Tools and render impacted

Currently, the Proposal process includes a template of proposal page that includes:

== Rendering==
<!-- Optional rendering suggestion, if relevant -->

== Features/Pages affected ==
<!-- List of wiki pages that would be edited if the proposal is approved -->

We suggest to add a section for the proposal to include the list of projects that are or may be impactedː

== External projects affected ==
<!-- List of projects (editors / renders / routers / search engines / others) that would be impacted if the proposal is approved -->

This list would be used later as a base for the transition plan's table.

Box for wiki users

The current "deprecated" message would not change.

Example for the changing_tables=*:

exclamation mark

This feature has been labeled as deprecated. The recommended replacement is: changing_table=*.
The reason is documented in Deprecated features. You are still free to continue to use or interpret this tag as you see fit 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.

A new "deprecated and unsupported" box would be created:

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

The reason is documented in Deprecated features. You are still free to continue to use or interpret this tag as you see fit since OpenStreetMap does not have “banned features”.

You are welcome to manually or (semi-)automatically change “deprecated and unsupported” tags to its replacement tag without any warning. See the conditions on this page.

What this proposal is NOT

This proposal does NOT aim to

  • change in any way the current Any tags you like policy.
  • ban the use of any tag (as previously suggested). In particular, the use of the deprecated to tag will always be tolerated, even after automated edits.
  • Change the one feature, one element policy. In particular, during the transition period only the new approved tag would be recommended for mapping new elements.

Rationale

This proposal aims to massively improve both visibility and efficiency of the tags deprecation process.

Currently, users of the data and tools / editors developers could face difficulties to identify the tags cycles. One has to understand and properly analyze TagInfo + Tag use history + multiple wiki pages + multiples mailing-lists.

Instead, a very clear recap table will be available in the already existing deprecated features page as a new "deprecated and unsupported" paragraph. It will help users to make a single set of changes every year in their tools, at a fixed date.

This proposal is inspired by the Ubuntu LTS release cycle which successfully improved massively the release understanding for users

Statement

Current deprecation process could last many years, leading data users and developers to keep using deprecated tags for a long time. The current spirit of deprecation is very clear: the use of the community prevails over the voters of the deprecation vote. Only the use could decide if a tag should live or die. It is a liberal way a dealing with deprecation that could be improved.

We think that the community should stand for its own internal votes in a more aggressive way (we pick carefully our words here). Taken the whole set of necessary precautions detailed in this proposal, there is no reason why the community should tolerate outdated, useless data nor editors / tools / render that keep using deprecated tags passing 2 years the date of vote.

This proposal is as much a new, improved process for the community to follow to ensure transition's success than a better predictability tool for the users and developers. Indeed, we need to take into account different interests.

Ideally:

  • For a data user: tags should never co-exist and a change of tag should only happen at a single, precise date, announced years earlier. Example: tag 1 is deprecated / 100% of objects keep being tagged with tag 1 during one year / 100% of objects switch to tag 2 after one year & tag 1 disappear forever
  • For a developer / user of presets: tags should never change, and if change there is, retro-compatibility should always prevail
  • For the community: no constraint of any kind should ever exist regarding the use of tags and the documentation should be crystal clear about which tag to use for a given object

As these interests are not compatible, we have to find a middle-way. Better organizing the community's process and having a deadline is a great balance.

Moreover, we clearly understand the risks of mechanical edits (as explained in this video) and tried our best to lower them. Indeed we strongly agree with the philosophy that "The strenght of OSM is edits by humans with intimate knowledge of location and subject". Nevertheless, we also strongly feel that, little-by-little, OSM is taking the same path than the GNU-Linux project. As it's been said "the main strength of Linux is that anybody could do anything with it. Its main weakness is that everybody did."

As the quantity of data continue to grow quicker than the number of contributors, we are convinced that we need new smart, controlled mechanical edits to support community's efforts.

Let's keep OSM safe from tagging balkanization and push in a direction of creating a both understandable and usable data for the community and the users. That is what tag standardization is all about and why we should reinforce it using this proposal.

External discussions

Several discussions already happened in order to improve the proposal.

As far as we know:

  • Preliminary discussion on the OSM France talk-fr mailing-list "[OSM-Talk fr] [Proposition] Améliorer le processus de dépréciation des tags" We've made a quick translation of the discussion and all the answers and improvements of the proposal:
    • Lejun: "I agree with this proposal, even if I have some reservations. Regarding the creation of another exception of the Any tags you like policy, I think it's no big deal (I spent too many hours over the transit network!). Regarding the automated edits of deprecated tags, I would prefer a manual correction such as the "possible synonym" wiki model "Template:PossibleSynonym2"
      • Overflorianː dealing with the synonyms is a different topic
    • Dominique Rousseau: "As far as the community voted, I suggest that the tools warn the deprecated tag sooner than the 2 years time period. I also suggest that the QA tools display warnings and allow semi-automated edition tools."
      • Overflorianː the warnings are planned. Regarding the 2 years period, we feel like it's the good balance to manage any exceptions.
    • David Marshal : "I agree to the principle. Nevertheless, replacing the old tags could require a human intervention: what if a tag is replaced by 2 different tags? Only a human intervention could make the job. Also, I feel that a deprecated tag should be removed from the editors the day it's been deprecated. Creating a new transition period of 2 years could lead to the editors to wait to make any change."
      • Overflorianː I added an exception in the proposal to deal with your concern. And I agreeː the tag should be deprecated in the editors on day 1 after deprecation.
    • Christian Quest: "your proposal is not such a big deal. 2 tags over the same object is really common. Also my schedule proposal : after the deprecation, 1 year period during which the tag is considered an anomaly by QA tools & editors. Nevertheless, renders (such as mapnik) still support the tag. After one year, the render remove the tag. After 2 years: mechanical edit. I'm strongly convinced that we will need more mechanical edits to be able to maintain the data over long term in the future as the data is growing quicker than the number of contributors."
      • Overflorianː Good idea. I added it to the proposal.
    • Noémie Lehuby: "I love the idea to kill obsolete tags after we all agreed. I think it's more important to focus on having the tools to support the new tags instead of focusing of removing the older. The transition period should be a migration period for the editors, renders and use to adapt. Mechanical edit is useless if we don't properly change our editors and tools, create MapRoulette challenges...
      • Overflorian (talk) 10:37, 11 December 2021 (UTC) A "transition plan" has been added to this proposal to follow your very good advice.
    • Jean-Yvon: If the new tag is too generic, it could be that replacing the deprecated tag with an automated edit makes no sense at all.
      • Overflorian (talk) 14:02, 12 December 2021 (UTC) You are right, I added the following mention: "Exception: the new tag should exactly describe the same object. For example, the old, still in use highway=bus_stop tag is described in the PT_v2 model as 2 different elements: public_transport=stop_position and public_transport=* and should not be mechanically edited."
    • Jean-Yvon: "In order to limit potential errors, it could be possible to use data items.
    • Jean-Yvon: maybe the life cycle could be decided during the deprecation process, independantly for every tag
      • Overflorian (talk) 14:02, 12 December 2021 (UTC) That a "community friendly" solution but it misses the main point of this proposal: improve life-cycle visibility/predictability. For this reason, I feel like keeping a fixed deadline is important. We choose a 2 years transition period, which is very long, to make sure that it's enough to manage every possible cases. We also excluded exceptions.
    • Leni: I feel like adding a link to the request in the table Proposed features/Deprecated and unsupported status#Example would bring more visibility, as long as the task is not yet marked as "yes"
      • Overflorian (talk) 14:02, 12 December 2021 (UTC) I agree. I added a dedicated column
    • Gendy54ː What if the tag has the same key? For example landuse=school is replaced by landuse=education. Therefore both tags cannot properly used at the same tag.
      • Overflorian (talk) 18:02, 18 December 2021 (UTC) very good input. I created a new exception to deal with that.
    • Gendy54 Example of a problem of reuses of a new scheme being developed: Talk:Proposed_features/Parking_lane_conditionals#Outreach
  • Proposed features/ban deprecated tags linked to the osm-tagging mailing-list thread "[Tagging] Feature Proposal - RFC - Discouraging the use of deprecated schemes"
  • Talk:Deprecated features

Comments

Please comment on the discussion page.

Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Proposal:Deprecated_and_unsupported_status&oldid=2513342"