In the end, I decided not use the script since Word and Excel would freeze because of the sheer amount of 650,000 lines to process.
I use regular expressions in Visual Studio Code instead, to which I copied the output from level0 for processing:
run overpass query for POIs with tag archaeological_site NOT with tag site_type, load into level0, copy plain text from there.
duplicate lines containing archaeological_site and replace archaeological_site with site_type in the original lines, using these regex in Visual Studio Code:
Find: *(.*)archaeological_site =(.*)*
Replace with: *$1site_type =$2\n$1archaeological_site =$2*
run overpass query for POIs with tag site_type NOT with tag archaeological_site, load into level0, copy plain text from there.
duplicate lines containing site_type and replace site_type with archaeological_site in the original lines, using these regex in Visual Studio Code:
Find: *(.*)site_type =(.*)*
Replace with: *$1archaeological_site =$2\n$1site_type =$2*
Just for completeness, you need to search for historic=archaeological_site + site_type=* as some usage of site_type=* is not for historical sites (and so we wouldn’t want to add archaeological_site to them).
(unrelated to archaelogical sites, as was the complaint, but)
Experience suggests that that is unlikely to occur. In the meantime it probably makes sense to manually review anything that you have contributed by email (and maybe wait until you can contribute not by email).
(back on topic)
Yes, and that actually applies to pretty much any proposal that suggests “deprecating” existing usage of a particular tag without giving any thought to how the proposal can be implemented. Another recent example was here - good idea (in this case to harmonise tags for “diplomatic” entities), poorly documented proposal and even poorer implementation that was only spotted due to “objects disappearing”.
I am a bit stuck - I am about to upload the POIs with duplicate tags now, but level0 refuses to even load the data (too many?), while in JOSM I keep running into conflicts while uploading so I have to restart every time.
Is there a way I can just upload the non-conflicting POIs in JOSM?
I absolutely would not use a “shoot yourself in the foot” tool like level0 for something like this. I’d use JOSM, and the workflow I’d use would be - query data according to a published overpass query that people have agreed to, change the data that people have agreed to, upload the data.
However, before doing anything else, I’d make sure that the discussion was complete, and I’m not sure it is, yet (I don’t think you’ve addressed this comment, and the fact that you’re even thinking about using level0 for this suggests a misunderstanding of the best way to work with OSM data).
I suppose the way to go is to not have everything in on global changeset with ca. 100.000 POIs. With this amount of POIs, it is just rather likely that somebody will upload a change while I am working with the data. I suppose this is what happened. Also, this seems to be easier to digest to the other mappers reviewing.
I just had to leave it now and will only come back to it after the weekend. Better not to do this in a hurry.
The requirement for previous discussions of large-scale edits is, among other things, to ensure that those intending to perform the edit can retrieve the necessary advice in advance, rather than starting something half-baked, attracting complaints, and then stopping midway
I am reverting your edits now in the hope that they can either be done by someone more knowledgeable or that you acquire the necessary skills before you try again. I also found it a bit problematic that you used this thread as a justification for your mass edit even though the discussion had not concluded.
I expect there to be a comparison of old to new first with something like this. Documented in a suitable place, e.g. Wiki. That’s how I would do it if I were considering the hot potato of mass edits.
It must also be ensured that all common editors such as iD, JOSM also evaluate the new key. Applications such as Historische Objekte are also part of this, hence the documentation.
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 …
“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: 1st2nd
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.