add option to limit values of a field on a "per preset" basis

Many fields (OSM tag keys) are used for more than one kind of map features. Sometimes, the sensible values of a field are restricted depending on which preset (primary OSM tag) is used. For example, usage=penstock only makes sense for pipelines, but not canals (see https://github.com/openstreetmap/id-tagging-schema/issues/348#issuecomment-1017432699). Another example of a tags where this is the case is the service tag.

A related use case is regional fields which might want to add or skip values on a per-country basis (see https://github.com/openstreetmap/id-tagging-schema/issues/287#issuecomment-1009822860 for example).

Sometimes tag values depend on the value of another (non-primary) tag, e.g. the values for denomination depend on what value the religion tag has. Another place where such a feature could come in handy would be to optimize the values suggested for the surface tag of sport pitches (see https://github.com/openstreetmap/id-tagging-schema/issues/336).

Currently, such situations are "solved" by duplicating the respective fields in the presets, which unfortunately can creates unnecessary additional work for translators. It would be more elegant to be able to create generic fields which are configurable in a more flexible way.

I see three different approaches to implement this, with differing pros and cons:

a) allow to specify allowed options also in `presets`

Presets could get the ability to specify options for the fields they use:

{
    "name": "Canal",
    "tags": { "waterway": "canal" },
    …
    "fields": [ …, "usage_waterway", …],
    "fieldsOptions": {
        "usage_waterway": ["transportation", …, "spillway"]
    }
}

{
    "name": "Pipeline",
    "tags": { "man_made": "pipeline },
    …
    "fields": [ …, "usage_waterway", …],
    "fieldsOptions": {
        "usage_waterway": ["transportation", …, "penstock"]
    }
}

Pros:

relatively easy to use and maintain
all relevant information is stored in the presets file Cons:
only directly applicable on a per preset basis (e.g. not for the religion → denomination use case mentioned above)
not extendable for regional variations without requiring to duplicate the preset

b) `optionsPrerequisites` configured on the field

This could be configurable in the field by adding a setting which limits the options by the presence/absence of a tag. The syntax could be borrowed from prerequisitetag. For example:

{
    "key": "usage",
    "type": "combo",
    "label": "Usage Type",
    "strings": {
        "options": {
            "transportation": "Transportation",
            …
            "spillway": "Spillway",
            "penstock": "Penstock"
        }
    },
    "optionsPrerequisites": {
        "spillway": { "key": "waterway", "value": "canal" },
        "penstock": { "key": "man_made", "value": "pipeline" }
    },
    "autoSuggestions" : false,
    "customValues" : false
}

Pros:

relatively straight forward to use, since existing features of the schema are reused
flexible: can be also used for the use case where options depend on the presence/absence of a non-primary tag (e.g. religion → denomination)
would allow to be extended to also filter options by locationSet Cons:
for some use cases this solution could still be a bit too limited, e.g. when a value should be limited to a set of two or more different presets
makes fields quite complex (i.e. harder to maintain)

c) inheritable `strings` for fields

Fields could be allowed to inherit strings from other (base) fields. e.g. there could be a generic usage_water field, and usage_waterway as well as usage_pipeline which inherit the strings property from it and then only need to specify the respective list of options.

Pros:

simple solution Cons:
not extendable for regional variations without requiring to duplicate the field and preset(s)

Perhaps this is all overkill and isn't worth the added complexity "only" to fix https://github.com/openstreetmap/id-tagging-schema/issues/351. I'm also not super happy with any of the proposed approaches above, since all of them have at least one significant downside and still not offer the full flexibility I'd love to see (i.e. to be able to mix and match and preset, tag and location based approach on all field and string). Maybe I'm overlooking a simple and flexible solution? :thinking:

ideditor / schema-builder