As of today, 75,000 of the occurrences have already been mechanically re-tagged, converting site_type= into archaeological_site=. It is not clear – at least to me –, if the lot of the OSM data users and renderers have been informed about this change, and if they have had enough time to adapt. At the same time, 45,000 POI are still tagged site_type=. Many are not yet re-tagged, and it is not known if and when they will be. 7000+ POI are tagged both, site_type= and archaeological_site= with identical values. site_type= currently has got 332 values, none of which refer to something other than archaeology.
The implementation of the change in tagging could be improved, it has been noted, see e. g. the discussion in the Germany forum. It would be good to have an agreed plan on what will be done when.
I suggest to
now tag all POIs tagged site_type= simultaneously with archaeological_site= and vice versa.
I wrote a script that could do this.
in July 2023, remove the site_type= in all the POIs simultaneously tagged archaeological_site=.
For completeness, here’s a link to the " Automated Edits code of conduct". That explains what you need to do before changing any data. You’ve already started the first part of that (“Document and discuss your plans”), so thanks for that. The rest of that wiki page explains the rest of what you need to do (proceed with caution; small changes first, etc.).
Although it’s not required by that code of conduct, I’d also suggest contacting the data consumers listed on taginfo for that tag**. This shouldn’t be too much of a chore, as there are only 7 data consumers listed there.
** full disclosure - (wearing my “web map developer” hat) that includes me***. I spotted an earlier iteration of large-scale changes to this tags and discussed it here. Given the chat on the German forum and the fact that I suspect that the other maintainers aren’t living under a rock, I suspect that the other maintainers may know already too - but it’d still be nice to let them know.
*** and also (wearing a “Data Working Group” hat), I’ve picked up a ticket that was reported from with the German community about an undiscussed mass edit. That resulted in a message to the user performing the change that was reported to say that they needed to join the general discussion in the German Forum. So far they seem not to have acted upon that request, unfortunately.
The DWG never got a report about “b-unicycling”; that was a non-DWG conversation that I had with them earlier. The DWG did get a report about “geozeisig”, and they hadn’t replied to changeset discussions, hence the “your email may be broken,” message. They now have replied to some changeset comments.
The discussion you had with b-unicycling on the changeset shows that even experienced community members often overrate the tagging proposal process and think that just because something is “approved” (by, usually, a handful of people) that’s an automatic license to mass-change OSM (which usually affects contributions by thousands). Then they do it wrong, get a polite reminder like yours, and become all defensive. I think we need to be even more careful with the words “deprecate” or “replace” in any future tagging proposals.
In the end, I did not use a script. I wrote it in VBA, and while the script itself was functional, Word and Excel were not, quitting service in the face of the 650,000 lines of xml code. So, instead I used regular expressions in a search and replace, wich took my machine 40 seconds. Yay!
Ah, thanks - the scope is worldwide. I thought this was clear because there was no limitation, but I see it is not
I will add this to the documentation.
It probably needs to be said explicitly: no, no data consumers and renderers have been informed except for those that just happen to have followed the discussion and no, there is no way that this can be automated.
If you feel that changing existing objects is worth the trouble, then YOU need to go and chase down consumers of the data, work out a campaign to inform ones that you can’t contact directly and so on.
To be clear, there is a way that data consumers can “register an interest” - they can update “taginfo” as a project, like @SimonPoole did for Vespucci here. If a project hasn’t done this then Simon’s ansolutely right - there isn’t an easy way to do it other than to chase down each project manually.
If you feel that changing existing objects is worth the trouble, then YOU need to go and chase down consumers of the data, work out a campaign to inform ones that you can’t contact directly and so on.
Sure that is a starting point, but I don’t think there is a “staring you in the face” place in which you could find about this, so it is a very insider kind of thing.
Probably worth just making the distinction that (I think) b-unicylcing wasn’t using mechanical/automated re-tagging. They were systematically but, as far as I am aware, manually re-tagging items.
This is, essentially, a terminology change. It doesn’t break the OSM database.
I do agree, however, that this should have been discussed before being undertaken (as is suggested in the Automated Edits code of conduct) as it can (and did) result in broken projects/maps.
I also agree that @ChillyDL 's proposed solution is sensible.
As of today, 75,000 of the occurrences have already been mechanically re-tagged
Probably worth just making the distinction that (I think) b-unicylcing wasn’t using mechanical/automated re-tagging. They were systematically but, as far as I am aware, manually re-tagging items.
It was mechanical because they were searching for objects with the site_type tag and then removed this tag and added a archaeological_site tag. On every item until they got too much flak and stopped.
How is this not “mechanical”?
This is, essentially, a terminology change. It doesn’t break the OSM database.
it breaks every single data consumer who expects “site_type” tags
[changes] made to objects in the database without review individually by the person controlling the edits
I don’t think this is the case here. b-unicylcing was manually (individually) editing objects and, one could argue, therefore reviewing them as they did so. Although, I accept, it will depend on one’s definition of what counts as a review…
To be absolutely clear: I still think they should have discussed this change and come up with a transition plan. An accepted proposal isn’t enough. Their edits were systematic but I don’t think they were “mechanical”. Just a semantic distinction.
Again, not disagreeing, see the other part of my post…
But I mentioned “not breaking OSM” because the code of conduct (as written) is about the database not 3rd parties
The purpose of this policy is to avoid the database being damaged.
Again, to be clear. I don’t think this was the right way to go about things but I think it was probably a misunderstanding that an accepted proposal was enough to make widespread changes.
yes, I am aware of this wording, I agree the guidelines are probably not really helpful in the case of “retagging” from tag A to B with the intention to not change anything, e.g. from phone to contact:phone.
If you take the guideline literally, doing so one by one (implying “individual review”) would not be forbidden by the guideline, but if the spirit is to not have few individuals manipulate what thousands of mappers have „voted with their feet“, then it doesn’t matter if you do it one by one or in a bigger batch, and you must get approval for such mass editing
Regarding the individual review, it is very likely that b-unicycling didn’t know all those thousands of objects, so if they were wrongfully tagged as a site_type they will be wrong as an archaeological_site=* now (i.e. maybe no actual review has taken place)
| 
ChillyDL: