when changing presets, delete keys from the old preset which are not in the new preset

[k-yle]

Previously discussed at openstreetmap/id-tagging-schema#1622 (comment)

• GoMap has already implemented the logic proposed here.
• StreetComplete and CoMaps have their own manually curated logic.

---

Currently, if you change building=yes + building:levels=5 to landuse=grass, then the grass will still have building:levels, which is a bit weird.

There are endless examples like this. This topic has been discussed many times in different PRs. removeTags can solve this, but it's not clear when we should use removeTags.

---

New logic:

• universal keys like name, check_data are always kept
• keys that do not exist in the tagging schema are always kept, like ref:FR:some_random_tag
• keys that are not used by the old preset are always kept
• keys that exists in the old preset, but not in the new preset, are deleted.

---

• fixes #11175
• fixes id-tagging-schema#1622
• fixes id-tagging-schema#1621
• fixes id-tagging-schema#1624
• fixes id-tagging-schema#1686 (comment 2537104048)
• fixes #9115
• discussed at id-tagging-schema#1800
• discussed at #11175 (comment 3019700503)
• does not fix­ id-tagging-schema#1283 - this is a complex example where we still need removeTags

[tordans]

universal keys like name, check_data are always kept

Is this part in the code already?

[k-yle]

Is this part in the code already?

yeah, right now iD doesn't delete any fields when changing presets.

So the only change is to the 4th bullet point.

[tordans]

If we release this, we should look into adding a recommendation in the docs (probably schema builder) to hint at other apps that this is the common handling of this case. (Note to self)

[tyrasd]

This sounds like the most sensible thing do do.

I noticed that none of the tests seems to cover the case for a tag which does not exist in either preset… Shall we maybe add a test for that case while we're at it? //edit: added this in 6f92a29

[matkoniecz]

fixes openstreetmap/id-tagging-schema#2069

how it does it?

https://github.com/openstreetmap/id-tagging-schema/blob/93113eccdddcedb502d951dc206c7add951b1d68/data/presets/golf/lateral_water_hazard.json#L4 does not have water= tags, so they will be still deleted - right?

When migrating from say https://github.com/openstreetmap/id-tagging-schema/blob/93113eccdddcedb502d951dc206c7add951b1d68/data/presets/natural/water/pond.json#L15

[k-yle]

fixes openstreetmap/id-tagging-schema#2069

how it does it?

If we add a field for water=* to the Lateral Water Hazard preset, then the tag will be preserved when you switch between the presets Lake and Lateral Water Hazard.

So it requires a change in this repo and iD-tagging-schema to fully fix that issue

[matkoniecz]

I expected that openstreetmap/id-tagging-schema#951 would be also fixed, but it still requires fiddling with paths.

[matkoniecz]

StreetComplete and CoMaps have their own manually curated logic.StreetComplete and CoMaps have their own manually curated logic.

I wonder whether it also should be partially used to purge things like "fhrs:.*", "old_fhrs:.*", "fvst:.*", "ncat", "nat_ref", "gnis:.*", "winkelnummer", "type:FR:FINESS", "type:FR:APE", "kvl_hro:amenity", "ref:DK:cvr(:.*)?", "certifications?", "transiscope", "opendata:type", "local_ref", "official_ref", "ref:thw", "ref:nav", "ref:GR:kepId", "ref:bufa", "ref:walmart", "ref:rspo", "ref:cue", "ref:regon", "ref:BY:trade_register", "ref:vb", "ref:comfort", "ref:bademilj.", "ref:HU:vatin", "ref:HU:company", "ref:ico", "ref:scoutingnl", "ref:anlegg", "ref:FR:sport_equip", "ref:FR:RNA", "ref:FR:CRTA", "ref:charity",