Improve sport preset - use multiselect for legacy semicolon separated fields

[homersimpsons]

Hello,

I think that sport preset need to be the same preset as fuel type. In fact a sports_centre can get multiple sports and the current field allow only the creation of one sport.

[bhousel]

It is not obvious from the field, but our Sport field does allow users to type in semicolon separated values, like soccer;lacrosse.

This is the currently accepted way of tagging multiple sports in OSM (see https://wiki.openstreetmap.org/wiki/Key:sport), although I would love it if OSM moved towards tagging multiple values using namespaced keys.. see #3535 for another example of this.

So I've thought about this a bit - I could probably build a field that does it both ways. Meaning, it would recognize semicolon-separated values like sport=soccer;lacrosse and turn that into a multiselect style field with tags sport:soccer=yes + sport:lacrosse=yes (while retaining the old semicolon-separated sport tag for backward compatibility). There are enough tags in OSM that still rely on semicolon-separated values, that I think this would be worth doing.

[homersimpsons]

It is not obvious from the field, but our Sport field does allow users to type in semicolon separated values, like soccer;lacrosse. Of course, I see that, but using this method don't provide presets that help to avoid spelling mistake.

This is the currently accepted way of tagging multiple sports in OSM (see https://wiki.openstreetmap.org/wiki/Key:sport), although I would love it if OSM moved towards tagging multiple values using namespaced keys.. see #3535 for another example of this. Yes, I know that, I do this like that currently, using the field or tag editor

So I've thought about this a bit - I could probably build a field that does it both ways. Meaning, it would recognize semicolon-separated values like sport=soccer;lacrosse and turn that into a multiselect style field with tags sport:soccer=yes + sport:lacrosse=yes (while retaining the old semicolon-separated sport tag for backward compatibility). There are enough tags in OSM that still rely on semicolon-separated values, that I think this would be worth doing. This aproximately what I though, or you could create a new field type, especially for semicolon-separated values. This is a quick draw on paint to show you my point of view on that specific field: There are other field where this can apply, Then maybe could be better. I hope you will understand myself :)

[slhh]

@bhousel Using a multiselect style field for semicolon separated values seems to be fine, but it should generate the semicolon separated tag output only. The current multiselect style fits even better to the semicolon separated value than to the namespace because in case of the namespace there can potentially be other values than "yes", but it would be possible to extend the style to support "no" or even special values too. It just needs to show "no" as a crossed out button, and to show the key part and a special value stacked within the button.

I would love it if OSM moved towards tagging multiple values using namespaced keys.

What is the benefit of having such namespaced keys in the central database? I would see some benefit to have such keys in the Overpass database etc., but Overpass could generate some virtual tags like $$sport:soccer=yes" and $$sport:lacrosse=yes automatically, if sport=soccer;lacrosse is tagged. Utillities like osm convert could do the same.

One benefit of using namespaced tags in the central databese would be to enable using "no" or special values. For example tagging sport:swimming=no on a lake or soccer=no on a park, where such sport is disallowed, would make some sense, special values like sport:soccer=indoor or sport:swimming=open_water too, but this seems to be the least thing you want to have.

Changing a frequently used tag has high costs. These would be significantly reduced if the OSM community decided to change within a short period of time by automated edit, but this seems to be unlikely. Otherwise data consumers have to support both tagging styles over years.

Using up the full sport: doesn't seem to be a good idea anyway. Maybe keys like sport:facility etc. are required later. Therefore, I would prefer a more specific namespace like sport:type: in case of changing to namespaced keys.

[bhousel]

It just needs to show "no" as a crossed out button, and to show the key part and a special value stacked within the button.

I've already told you before that I don't want to do this. It's just too hard to explain to people.

What is the benefit of having such namespaced keys in the central database?

sport=soccer;lacrosse and sport=lacrosse;soccer are the same thing. That make it really inconvenient to consume these multivalued tags from openstreetmap without significant processing. It also makes it really hard to explain to new users how to tag things. (Don't assume they will read a wiki).

Changing a frequently used tag has high costs. These would be significantly reduced if the OSM community decided to change within a short period of time by automated edit, but this seems to be unlikely. Otherwise data consumers have to support both tagging styles over years.

Yes, this is why I said above that I would retain the legacy tag. The code to split and reassemble it is trivial while the user is editing, but complicated if one wants to process every sport tag in the planet and use the data for anything.

@slhh do you actually consume OSM data for anything, or are you just someone who has opinions about how the tags should look?

[slhh]

Yes, this is why I said above that I would retain the legacy tag.

If iD were the only editor, this would be fine. JOSM users are tagging much more manually. You have to expect the data to become inconsistent. Some users might have changed just one style, removed one due to redundance or a JOSM warning etc. How would you handle incoming sport=soccer; lacrosse + sport:soccer=yes? Asking vor permission to solve this situation by an automated edit would be strongly refused, because it is not clear what is meant. Even if the history were analysed with the result that sport:lacross was removed, it would not be clear if it was removed because of redundacy (needs to be restored) or because lacrosse is not available there.

The code to split and reassemble it is trivial while the user is editing, but complicated if one wants to process every sport tag in the planet and use the data for anything.

I'd agree that it is complicated for the smaller data consumers not running their own database, and also that an improvement is required. The real user requirement of the data consumers is to have access to the data in a format being convienient for their application, but the main database does not need to contain this format. Therefore, the main database should be optimized for editing. Data consumers should be served by a slave server being setup from a preprocessed planet file and being updated from preprocessed minutely diffs. This way even multiple slave servers are possible, which are serving different application groups using different preprocessing. The improvements for data consumers could be much higher than possible by optimizing the main database formats.

Such an architecture would also make changes of tagging style easy, because the slave servers can add compatibility tags.

It also makes it really hard to explain to new users how to tag things.

Your approch does make it even harder. Users using the fields does't see any difference and you need to explain to user who are using the all tags section or JOSM to use both tagging styles.

(Don't assume they will read a wiki).

Why do think that they would read instructions to use both styles and not to use other values than yes?

@slhh do you actually consume OSM data for anything, or are you just someone who has opinions about how the tags should look?

Sometimes I do consume data using the Overpass API. Therefore, I understand the requirements of data consumers quite well. In fact I don't have strong preference for one style, as far as the main database is concerned, but I see the problems of a long lasting change. If you were able to get approval of the OSM community to do a hard change by mechanical edit of the whole database, I wouldn't oppose., but I don't see any chance due to a very limited benefit. For some data consumers the current key seems to be even better. For example when querying for features without any sport assigned or for multi-sport facilities with at least 3 kinds of sports.

[bhousel]

Your approch does make it even harder. Users using the fields does't see any difference and you need to explain to user who are using the all tags section or JOSM to use both tagging styles.

Good point.. I guess we should just leave things well enough alone then..

[bhousel]

I fixed this issue last night by adding a multiselect style field that can work with semicolon-delimited tags, and the sport field is now using it. See #3905