OpenStreetMap
Deprecated or duplicate tagging schemes in use are not critical issues
Posted by Mateusz Konieczny on 30 January 2022 in English. Last updated on 6 November 2022.I have seen on tagging mailing list and some other places claims that deprecated tagging schemes continuing to be used are a critical issue.
I also have seen claims that having two tags with the same meaning is a critical issue that cause very big problems.
In my experience as mapper, someone working on OSM editors, someone working with OSM data:
Deprecated tagging schemes continuing to be used are not a big problem or a serious issue.
There are some tags that should be never used ( osm.wiki/Key:class:bicycle is a good example of something that is pure waste of time, see for example https://github.com/streetcomplete/StreetComplete/issues/2210#issuecomment-726974964 ).
But pointless tags can be completely ignored if they are truly bad ideas.
Note that popular tag which is not fundamentally bad idea and someone wishes to get rid of them is just regular duplicated tag for basically all purposes.
Duplicated tags with the same meaning.
For data consumer it is not a big issue. It is a bit annoying, but as long as new tags do not keep appearing then simple alias solves approximately all the problems.
It can be described as a problem but is definitely not in top 10 issues for data consumer. Maybe not even in top 50.
And is basically eliminated by decent documentation, if one exists at OSM Wiki.
For implementing it in editor - it depends on an exact case and definitely can be annoying.
But the worst part is case when group A demands to deprecate one tag, and group B demands to deprecate tag B. Or when one group accuses someone of being destructive because they followed documentation/consensus that documented some tag as deprecated/not deprecated and situation suddenly changed and another group appeared.
Overall this is quite ironic: people wishing to deprecate, rename, change tags often argue to be doing it to help data consumers.
While existing data consumers overall prefer stability of tagging schemes and this changes rarely make job easier for data consumers. And nothing is as irritating as discovering that you are blamed for using bad tags that month ago were perfectly fine and you need to again research situation and whether there is actual change in consensus or is it a single person (or small group) with strongly hold opinions presented as a consensus.
For mappers: removal of duplicate tagging schemes makes the biggest improvement to mappers starting to use given topic. For example I remember my confusion about which way merged but segregated footway + cycleway should be tagged.
But deprecated or duplicate tagging schemes existing are not critical issues, if OSM will disappear it will not be caused by fact we have both contact:phone and phone tags in use.
This post was triggered by “This attitude reminds me of those who oppose measures against climate change.” on mailing list (threads: 1 2). I would say that this attitude is closer to people that seen topic described as “This will decide future of the world” and discovered that debate concerns color of a bikeshed.
I participated in many tagging discussion and will continue to do this, but lets not overstate importance of tagging schemes. Existence of substandard tagging schemes is NOT a critical issue, it is NOT ever going to be the most important thing, phone vs contact:phone it is NOT worth reraising again given clear lack of consensus and no indicator that anything changed. And distinct lack of an actual importance.
Though I would be happy to deprecate contact:phone and several other tags.
To repeat: “something that you are using just got deprecated” is a guaranteed way to annoy any programmer. Works well also for manager in a large company.
If anyone claims that we need to deprecate heavily used fundamental tags to make large companies treat OSM more favourable, then I am going to doubt about their familiarity how they actually operate. To leave aide question why we should care about such opinions, even if actually existing.
Discussion
Comment from SimonPoole on 30 January 2022 at 09:41
It should be noted that the proposal process does not include terms for handling “deprecation”, far more it implicitly assumes that the purpose of a proposal is to add/document tagging for objects, or attributes of objects, that previously did not have widely used tagging. See proposal process. A good example of this working is how the tagging for bicycle parking was refined in a recent proposal.
As I’ve said before, some times there are actually good reasons to replace existing tagging, for example when the same tagging has been used for two different things, or technically defect tagging (the indoor tagging scheme that referenced OSM ids in tags comes to mind), but these are relatively rare situations. Outside of these special cases “deprecation” happens over time simply by popularity.
What has become more and more common though is churning tagging by replacing completely functional tagging for superficial reasons. Be it a typo or slightly incorrect spelling in a key or value, be it top level categorization that doesn’t quite fit.
Typical of these proposals is not only to they bring -zero- additional value (after all the objects were already being mapped), but they supposedly “deprecate” the existing tagging, which is not more than an attempt to justify a later mechanical edit, because that is actually were the itch is.
This is not only actively data consumer hostile, it doesn’t make the slightest difference to the vast majority of contributors that never see the actual key value combinations that we internally use in the data.
To use a recent tag-churning example, parcel drop off/pick up machines will continue to be presented to the majority of contributors as a “Parcel Locker” (for whatever reason iD decided to change the name from “Parcel Pickup/Dropoff Locker” to “Parcel Locker” which however just proves my point).
Comment from SimonPoole on 30 January 2022 at 10:38
That should have naturally been a reference to the recent amenity=bicycle_rental improvement.
Comment from Mateusz Konieczny on 31 January 2022 at 10:37
I would not go as far to say that things like fixing typo in tag brings zero value, but often overall benefit is dubious at best or clearly negative.
(I count discussions related to deprecation, effort to create proposal/vote, decide on applying or not the deprecation in editors as a cost, annoyance to data consumers is also cost etc etc)
Yeah, this one was better to be kept as is.
It actually mentions deprecation a bit. Though mostly to make clear that deprecation vote is weaker than some proposal process participants expect:
Comment from InfosReseaux on 6 February 2022 at 14:32
Here are some thoughts about this. Thank you for summarizing this all here, while it’s hard to get involved in every discussions in mailing-lists,
An important that didn’t shown up so far is discoverability and ability to map with several tagging schema used.
Tagging convergence can also encourage mapping and actually increase mappers engagement, in ways that would have been impossible with unclear, duplicated or still-used deprecated tagging.
Examples: * The first world-scale replacement I’ve been involved in: power=sub_station to power=substation. power=sub_station: 110 000 objects in 6 years power=substation: 520 000 objects in 8 years Growth rate has been increased by 3.5 times. Data quality improved a lot too.
One of more recent replacement that come to my mind: tower:type=anchor to line_attachment=anchor tower:type=anchor: 13 000 objects in 6 years (5 000 remains) line_attachment=anchor: 52 000 objects in 2 years Growth rate has been increased by 12 times, by encouraging mapping new locations as approx. 25% existing remains to be moved.
Not to mention replacement of waterway=riverbank with natural=water + water=river during last 2 years with already more water=river than legacy riverbanks.
And so on, …
Tagging replacement is a tool among many others, that could be used by the community to improve things. Despite I admit, like any tool, it could be misused, how can one state tagging replacement is globally bad or letting duplicate tagging scheme without convergence perspective isn’t critical? Not to mention the tool we discuss about is used in regard of a seek of consensus and not enforced, discussed every time.
That could be good as well to provide figures like I do to discuss such points. Please provide facts. Many discussions held so far only deal with qualitative facts “tagging should or shouldn’t” but not so often about what has been actually achieved by many other people in the past.
Endlessly confronting groups of people, mappers, consumers, experts, beginners, developers, users (we all experiment each of them at different times) instead of producing common material, data, tagging, is a constant cause of failing in the most deceptive way we could imagine.
Comment from tomczk on 7 February 2022 at 01:02
These annoyances stack up and at some point you as a data consumer start asking yourself “is it even worth trying to use OSM data?”.
Many ways of mapping presence of bike path or sidewalk is a good example of something gets complicated fast.
I could agree that it may not be CRITICAL issue but I wouldn’t push it outside top 10.
The more complicated it is to use any given dataset the less likely it is that it will be used.
Comment from Mateusz Konieczny on 8 February 2022 at 12:48
I am not convinced that the growth rate increased as result of retagging.
I rather expect that both retagging and higher growth rate was caused by some other effect.
And to compare actual growth rate it is necessary to take into account both tagging methods - both before and after.
I just did, based on my experience and comments that I have heard from other users of OSM data.
I have not stated this, and in fact I participated and initiated some of them.
fact: at least some data users and people writing software using OSM data do not consider duplicated/deprecated tagging schemes in use as a critical problem. In this specific post presented sample size is small (n=1: me), but I heard similar comments from other people. Maybe I should track down comments that I remember or try to survey such people.
If anyone else wishes: feel free to steal that idea, I have more plans and ideas than I can do in my lifetime and proper overview from other people using or trying to use OSM data may be interesting.
I am curious what would be listed as top issues, though I am betting that “duplicate tagging schemes” would be:
Comment from Mateusz Konieczny on 8 February 2022 at 12:50
In general I expect that if someone organized mapping campaign, let other people that something specific was worth mapping - then it is the reason for more objects being mapped.
Not retagging itself. And that the same growth would be achieved without retagging.
Comment from Mateusz Konieczny on 8 February 2022 at 12:55
I agree, and I am not claiming that it is always a bad idea. Just that distorting situation and claiming that it is the largest problem ever is simply incorrect.
And it is necessary to be aware that existing data consumers processing OSM data are not happy about retaggings which force them to start supporting new tags, just to hadle things which were covered by deprecated tagging.
Even if such changes would be overall justified - current data users are going to be the grumpiest as they have all negatives without positives.
Comment from Matija Nalis on 11 March 2023 at 17:48
While majority deprecation proposals are problematic, the ones I find most offending are “rename” ideas, e.g. “let’s make a tag with identical meaning like previous tag, but this new one being tidier/clearer/in better hierarchy”.
Especially since they very often quite happily ignore (or hugely downplay) all the problems that “tidiness” brings when applied to tags that are already in use:
people engaging in discussion have to waste their time explaining why that is bad idea (lest bad idea comes into practice!) thus leaving them less time to do more productive OSM-related things
wiki editors will have more work to do which could’ve avoided (especially as almost always there will be people to disagree, change and revert pages etc so endless cycle of watching wiki pages and fixing them will ensue).
regular map editors will now have more work, as they will have to consult multiple wikis to decide which one is correct, lookup the wiki recheck their memory which of the tags they remember is the favored one. And even if editor have extra support for deprecated features, it is still more work as they would have to confirm that changes.
Unless exactly 100% of all mappers agreed (which never happens in reality), there will be edits with old tags as well as new ones, re-editing with new values, reverting to old values, potential for edit wars etc. Wasted time and effort by all parties involved in the best case, community schism and lost good editors in the worst.
editor programmers will have more work, as they would have to add support for new tag and remove support for old tag. And sometimes also they will have to add code to deprecate/warn on old tag and suggest new one, with explanations.
editor support channels (as well as regular forum / mailing lists) will have more work, as people will become confused and unsure, and it will have to be explained to them
data consumers will have more work, as instead of supporting one tag, they will have to support two of them (and have special cases how to handle inconsistencies if both are present but claim different things).
QA tools writers will have more work to add new checks and document them
even people wanting to see only a new tag will have a lot more work – and vast majority of them will give up before promise of “better future” (i.e. only new tags remaining) is accomplished: making issues PR for all editors, contacting users adding old tags (e.g. manually of from custom presets make in the past as they have a solution that works and never heard of the change, or older version of software, or because they are not convinced new tags are better, or …), updating all online (and offline) documentations / slides / video presentations / … (or at least remove / mark them as obsolete, thus destroying useful information)
and the list goes on…
And all of that just for the promise that “well maybe sometime in the future, decades along the road, one raw tag might be slightly more readable, at least according to some users”.
In short
There is lot of pain associated with deprecating things. That does not mean that the deprecations should never be done, but instead that all those pains must be taken into account, resources allocated to address them, and that deprecation request should proceed only if advantages that depreciation bring overweight (hopefully by a big margin!) those disadvantages.
ObXKCD: