Sometimes, upgrade paths need to handle semicolon-separated tags differently depending if only a single value is present or a combination of multiple values. For example consider the following situation:
old_tag=a :arrow_right: new_tag=x + new_sub_tag=a
old_tag=b :arrow_right: new_tag=x + new_sub_tag=b
old_tag=a;b :arrow_right: new_tag=x
Such a tagging upgrade is currently (in general) not possible to implement using the deprecated.json and/or preset replacement mechanisms. The first because multiple upgrade paths will match the a;b value, causing the new_sub_tag to be incorrectly added in the result. The preset replacement mechanism does not work if there is only a single preset for new_tag=x (and a field for new_sub_tag).
One solution would be to allow the matching of old tags to be more strict, e.g. by being able to indicate that semicolon-separated values should not be considered. Possible syntax:
Sometimes, upgrade paths need to handle semicolon-separated tags differently depending if only a single value is present or a combination of multiple values. For example consider the following situation:
old_tag=a
:arrow_right:new_tag=x + new_sub_tag=a
old_tag=b
:arrow_right:new_tag=x + new_sub_tag=b
old_tag=a;b
:arrow_right:new_tag=x
Such a tagging upgrade is currently (in general) not possible to implement using the
deprecated.json
and/or presetreplacement
mechanisms. The first because multiple upgrade paths will match thea;b
value, causing thenew_sub_tag
to be incorrectly added in the result. The presetreplacement
mechanism does not work if there is only a single preset fornew_tag=x
(and a field fornew_sub_tag
).See https://github.com/openstreetmap/id-tagging-schema/pull/365#issuecomment-1020327367 for a case where such a bug occurred.
One solution would be to allow the matching of
old
tags to be more strict, e.g. by being able to indicate that semicolon-separated values should not be considered. Possible syntax:The property could also be called
"match": "exact"
to be a bit more concise.The downside of this approach would be that it would not be backwards compatible with older versions of iD (once it is implemented). :thinking: