these weren’t part of the proposal anyway 
in all languages these are less than 20 on the globe…
All right, I will hold my horses. Seriously, I had the impression the discussion had come to an end, with no votes against after a week and nobody having said anything for two days.
I feel some might be unaware of the documentation of the suggested mechanical edit – quite some of the concerns raised here have been addressed there already. I am posting it again.
For the record, apparently it is not possible to upload just the non-conflictuous POIs with JOSM and deal with the conflicts later. Just in case you, too, ever want to pick up the 70,000 pieces after a not-so-fortunate mass edit …
Sorry, votes? What votes? Were we supposed to “vote” somewhere on your proposed implementation?
For my part I was waiting for you to follow what it says here - document how you were going to perform your planned edit. Earlier I had said
I (and possibly other people) were waiting for you to publish the overpass query that you were going to use.
Note also that the code of conduct says “Execute only a small number of edits with a new bot at beginning before proceeding with larger edits” so I absolutely wasn’t expecting you to try and do the whole planet at once …
1 Like
“Votes” as in “vota”, “opions”. There was broad support, that was my point, then two days silence.
The documentation on the planned edit had been on the wiki for days already at that time, including the overpass query, the pilot I ran after some smaller tests, and the global scope of my suggestion, the two latter of which I had also posted right here above: 1st 2nd
@ChillyDL To me it seems that support is in favour of this, to give users some time to adapt before any mechanical edit happens. (As always, correct me if I’m wrong.)
In the Germany Forum, @streckenkundler suggested to simultaneously run a quality control on the values of site_type= while re-tagging. To keep the discussion together, I would like to address this here.
To me, the task here is to effectively re-name the tag site_type=. Due to the circumstances, this will be done with an interim step for data consumers to adapt, but it still is re-naming task. There is built-in quality insurance in my above proposal as only those POIs that bear tags of the historic= group will be re-named in the bulk edit. Presently all do.
I suggest to keep changing the values of site_type out of this bulk edit. Of course, there should be quality control of the values of site_type=/ then archaeological_site=, and I have busied myself to exactly this the last two years in my daily editing routine and intend to keep doing. But I would keep this apart from the present re-naming operation.
@streckenkundler named three values specifically that raised his concern: rock_painting, roman_road and industrial. With rock-painting and roman_road, I believe it is safe to trust their historic= tagging to go on with the tag re-naming. Of industrial, there is only a handful left, tagged historic=archaeological_site, that I looked through individually and that seem alright.
You can find a list of the affected values in the documentation.
I agree that semantical and syntactical edits should be separate steps.
1 Like
Just worth noting that in December 2022, iD editor deprecated site_type in favour of archaeological_site for the historic=archaeological_site preset.
Two week on, it seems to me that the discussion has come to an end and that support is in favour of the transitional simultaneous tagging as suggested.
After a number of successful tests and pilots, I will now proceed to mechanically amend the tagging. I will do this in smaller geographical units, and I will only do this for objects that are tagged as historic=archaeological sites.
I went through all the site_type= in the historic= group that are not tagged =archaeological_site in the last two weeks manually in preparation to guarantee data quality.
For details, see the documentation.
2 Likes
done. The tagging has been amended.
There is one group of archaeological sites that still carry the deprecated site_type= tag exclusively: about 2000 of New Zealand’s prehistoric fortifications, called pās. For historic reasons, these archaeological sites are tagged historic=pa and not historic=archaeological_site:
As I have only included objects under the historic=archaeological_site tagging scheme in the edit above so far, the instances of site_type= under historic=pa have not been part of the edit.
For reasons of data consistency and to not leave those Maori archaeological sites behind, I suggest to extend the above tagging edit to objects tagged historic=pa, meaning to also there
-
now tag a ll POIs tagged
site_type=simultaneously witharchaeological_site=and vice versa. -
in July 2023, remove the
site_type=in all the POIs simultaneously taggedarchaeological_site=.
All data users of site_type= had been informed in January already.
What do you think?
All data users of site_type= had been informed in January already.
how was this possible? I would be interested in the details, could be useful for other cases as well…
2 Likes
I should have been more precise. What I meant is: All known data users of site_type= as documented in Taginfo have been informed in January already.
1 Like
That is simply untrue.
I stumbled across an edit to something with this tagging just 5 minutes ago. The changes to this and this were neither discussed in this thread above nor at https://wiki.openstreetmap.org/wiki/Automated_edits/ChillyDL#values_affected. Neither are archaeological sites.
I think you need to stop now.
I’m still trying to decipher the higgledy-piggledy edits you’ve done so far (see note above), and I suspect that I’m actually more aware of the changes that you’re making than most people. I’d suggest waiting a few months to let people catch up and work out why the things that they expect to see in the data that they get from OSM isn’t there any more.
Just changing tag values from one thing to another isn’t a cost-free process. For example, if you** change “historic=somethingelse” to “historic=industrial” it’ll cause a problem to all those people who were deliberately ignoring “historic=industrial” - they’ll need to look at some other tag in the data to decide whether to render it or not.
Also, at the risk of stating the obvious, just fiddling about with tags (except to correct misspellings etc.) does not result in any more things being mapped in OSM - it does not improve the quality of OSM data in any way.
** Edit: I should point out that I’m just using “historic=industrial” as an example here. I wasn’t expecting your edits to that key, true, but it does seem that most of the growth was in 2020 and 2021. The 2020 growth looks like an organic process that might correspond to people actually checking the values they are changing, but the two jumps in 2021 look like a whole bunch of data having its keys changed in one go. For the avoidance of doubt, each of these pre-dates your edits of 3 months ago.
Now, this is surprising. A certain “SomeoneElse” pointed out above that the data users “are not living under a rock” and that they were most likely informed already. I contacted them all the same.
@SomeoneElse, I sent you an OSM message.
Yes. These 16 objects are neither automated edits nor mass edits nor archaeological sites nor are the edits part of the implementation of the new tagging scheme. That is why they are not discussed in this thread and the proposal.
I am not happy with the allegations and insinuations here. What is described here as “higgledy-piggledy edits” has been the product of weeks of work to systematically sift through all thousands of possibly archaeological sites manually, when editing the occasional non-archaeological object that I came across.
I have shifted the =industrial of the odd former, non-archaeological mill from site_type= to historic=, stuff like this. I have not done any mass or automated edits, let alone years ago in the historic=industrial sphere with a sock puppet or how ever this could have been possible.
Also, I do not see how this is an argument to not protect New Zealand’s archaeological sites equally from the effects of the unfortunate depreciation decision.
To start with this one first:
I’m suggesting that we let the fallout from your previous edits hit the ground before embarking on more of them.
I don’t know what else you have done that you haven’t told us about, and there might be nothing, but please let’s wait a bit before embarking on the next phase!
What is your goal here?
What are you trying to do with OSM data that you can’t at the moment that requires the “to and fro” edits to e.g. https://www.openstreetmap.org/node/5501813929/history to achieve it?