You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 ➡️ new_tag=x + new_sub_tag=a
old_tag=b ➡️ new_tag=x + new_sub_tag=b
old_tag=a;b ➡️ 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
➡️new_tag=x + new_sub_tag=a
old_tag=b
➡️new_tag=x + new_sub_tag=b
old_tag=a;b
➡️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 openstreetmap/id-tagging-schema#365 (comment) 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). 🤔
The text was updated successfully, but these errors were encountered: