Hide irrelevant crossing:markings values

[Dimitar5555]

Describe the bug
Not all values of the crossing:markings are used in each country. It would be good to show only ones which are used in the currently edited country. For example, in Bulgaria you will find only dashed, dotted and zebra

To Reproduce
Steps to reproduce the behavior:

1. Go to https://www.openstreetmap.org/node/5337183644
2. Click "Edit"
3. Select the crossing markings field

Expected behavior
Only relevant values should be present for each country (if that's even possible).

Screenshots

[1ec5]

It is possible to implement this for Bulgaria, by creating a redundant field that applies just to Bulgaria and excluding Bulgaria from the global one. You might need to create a redundant set of crossing presets as well.

There are also countries where some values are extremely rare but do exist occasionally. If these values are omitted, then they’ll be undiscoverable, but the field should still show the value if you select a feature that already has the value.

Addressing this issue more broadly would require a change to iD rather than just the schema files here. I’ve been wondering if Geofabrik’s country-specific taginfo instances would be able to handle load from integration into iD. If so, we could hook up iD to those instances instead of the global one, so that the values can be sorted by regional prevalence. I think this would only be prudent for certain keys like crossing:markings that inherently vary by region; we wouldn’t want to fragment the tagging scheme in general.

[Dimitar5555]

I was thinking of something like include and exclude for each option. I'm also not a big fan of the regional presets/fields.

Addressing this issue more broadly would require a change to iD rather than just the schema files here. I’ve been wondering if Geofabrik’s country-specific taginfo instances would be able to handle load from integration into iD. If so, we could hook up iD to those instances instead of the global one, so that the values can be sorted by regional prevalence. I think this would only be prudent for certain keys like crossing:markings that inherently vary by region; we wouldn’t want to fragment the tagging scheme in general.

That may be a better idea, assuming we have enough data for each country.

[tyrasd]

I'm also not a big fan of the regional presets/fields.

May I ask you why?

You might need to create a redundant set of crossing presets as well.

Actually, for cases like this one (where only the field values depend on a specific region) this is not necessary. It's sufficient to just change the default field to exclude the region for which a new regional version is to be created, and to include the new field in addition to the default field wherever that one is already used.

There are also countries where some values are extremely rare but do exist occasionally. If these values are omitted, then they’ll be undiscoverable

This is actually a valid downside of the regional fields approach. 🤔 It's however not something that could not be fixed, though: for example, there could be a new property added to the schema which allows one to customize the order of the options, or alternatively to hide extra options in an ellipsis … entry.

[tyrasd]

I’ve been wondering if Geofabrik’s country-specific taginfo instances would be able to handle load from integration into iD. If so, we could hook up iD to those instances instead of the global one, so that the values can be sorted by regional prevalence.

Interesting idea. I'd be hesitant to solely rely on regional taginfo data, because especially for small regions and/or rare-ish tags, there might just not be sufficiently much data to be useful. But for sorting entries by regional usage it could definitely be nice. 👍

//cc @woodpeck @joto: how would you assess the possibility of accessing geofabrik's regional taginfo API from iD?

PS: note to self: this josm ticket contains some useful info about matching geofabrik regions: https://josm.openstreetmap.de/ticket/18729

[Dimitar5555]

I'm also not a big fan of the regional presets/fields.

May I ask you why?

They seem to create yet another field to translate in Transifex. It may have changed since last time I checked.

There are also countries where some values are extremely rare but do exist occasionally. If these values are omitted, then they’ll be undiscoverable

This is actually a valid downside of the regional fields approach. 🤔 It's however not something that could not be fixed, though: for example, there could be a new property added to the schema which allows one to customize the order of the options, or alternatively to hide extra options in an ellipsis … entry.

I think that the elipsis ... option may be better and it should remove the scroll bar for most (if not all) countries.

[tyrasd]

[Regional presets] seem to create yet another field to translate in Transifex. It may have changed since last time I checked.

Since version 5, one can cross reference strings between presets (e.g. the regional presets/fields can implicitly reuse the name, aliases, placeholder text and value strings from the main preset/field), solving this problem. 😊