Block deprecated high-use tag values fetched from taginfo

[boothym]

When editing an existing pitch which is simply tagged leisure=pitch, you type the sport in the sport field. However unlike the main preset list, which adds sport=soccer when searching for football, the sport field allows both hockey and football to be added. These are ambiguous and should be avoided - is it possible to remove them, and add soccer when typing in football?

[bhousel]

Sorry, there isn't really a way to filter this field to only "good" values. OpenStreetMap lets people type anything into most fields, and the sport=* field is reused on any features that relate to sports, so the field will have a lot of suggested values in it.

For certain features like ice skating rinks or racetracks, we can display a small subset of sport=* values that make sense for that feature. But for outdoor pitches, the potential sport=* values would be a very long list..

[boothym]

Sorry, there isn't really a way to filter this field to only "good" values.

I understand that it's just a list of values from taginfo. But can it not be done the other way about by filtering out the "bad" values? Basically remove hockey and football from the dropdown list.

OpenStreetMap lets people type anything into most fields

Sure, but I thought iD was about making things easier for beginners etc. - hence why you have presets so people can type in "football" and get the correct options. New users won't know that hockey and football are discouraged.

At the very least the actual searching could be improved - as you can see in the first image, typing in "hockey" autofills hockey, but doesn't show field or ice hockey unless you scroll down.

[bhousel]

New users won't know that hockey and football are discouraged.

Why are they discouraged?

[slhh]

These terms are used for different kinds of sports in American and British usage:

• american football vs. soccer
• ice hockey vs. field hockey

OSM-Tags should use British English, but I don't think non-British users do strictly follow this rule.
Therefore, the intended meaning is often unclear.

[boothym]

They are discouraged because they mean different things in different countries, and should be replaced by a more specific and unambiguous word. Football can mean about six different sports across the world: https://wiki.openstreetmap.org/wiki/Football

My issue with it is: if someone edits a pitch without a sport tag, they are more likely to type in the sport field than search for the sport in the main preset list. Therefore they won't have the benefit of translations - e.g. football -> soccer for someone in the UK.

OSM-Tags should use British English, but I don't think non-British users do strictly follow this rule.

Up to a point, yes - but for example with pavement, sidewalk is preferred in OSM because its meaning is clear.

[bhousel]

It sounds like there could be a useful case for allowing some fields to have a tag value blocklist, which would let us exclude some deprecated but popular results from what we fetch from taginfo.

I don't want to add this feature just for the sport=* tag, but are there others? This would be for a tag value that is returning a lot of results, not something that is used 500 times and can be fixed in one session with level0 if somebody cares enough to do so.

[slhh]

I have already suggested a blacklist and also a whitelist in #3709 , and they are even more useful as long as taginfo limitations prevent solving #3709 in full.

Blacklisting and whitelisting needs to be preset specific for many cases.

Main usecases seem to be:

• blacklisting of deprecated values
• blacklisting of values which are misleading if suggested by the editor. Of course the user still needs to be able to type in the value manually.
• keys used by severeal presets requiring different subsets of values. For example we could improve the useability of the service field of the railway preset by blacklisting the highway specific values, or by moving the railway specific values to the top by whitelisting these.

[bhousel]

I have already suggested a blacklist and also a whitelist in #3709 , and they are even more useful as long as taginfo limitations prevent solving #3709 in full.

Yes but #3709 was mostly about something else (using taginfo to determine reasonable pairings) , and I still think the idea of automatically retagging things would upset people.

blacklisting of deprecated values

This case is the only one I'm suggesting - and I'm not yet convinced we should do it.

[slhh]

@bhousel I think you have totally misunderstood what I have meant with retagging.

I agree retagging existing features automatically would likely upset people. Where automatic retagging is possible, we don't need iD to do this anyway. There are better tools for automatic edits than iD.

What I was talking about is from the users view more a further abstraction of presets, fields and there values. I have misleadingly used the term retagging because the way to implement it would likely be an internal postprocessing of temporarily generated tag values.

Presets and fields are an abstract thing. There names do not necessarily match the key names.

ID isn't asking the user: "Does the feature fit to the formal definition of man_made=tower? And which value has to be used for the tower:type key?"
Instead iD is somehow asking the user: "Is the feature a tower? Which type does it have?"
Now iD is responsible to generate the tags matching the meaning of what the user has entered or selected. This doesn't mean that field value and tag value have to match literally.
In case the user states it is a tower of type pole the tag to be used is man_made=pole, but not man_made=tower plus tower:type=pole because the formal definition of man_made=tower is more strict than the definition of tower in general language.

[bhousel]

I thought about this more, and let's not do this.

The OSM community needs to take responsibility for the tags, not expect editors to build in a bunch of extra logic to know which tags are better than which other tags. If sport=football is indeed deprecated, then somebody should make a Maproulette challenge or something to clean them up. iD will stop suggesting the tag when it is no longer in widespread use.

[slhh]

@bhousel
This might work in simple cases, where the change can be purely based on osm data and aerial imagery.
Where local knowledge is required for the change the community doesn't have any chance to eliminate the deprecated tag against an editor suggesting it based on statistics, at least where a tag looks useful at first glance.
ID is not forcing the users to read the wiki by design, and this makes the situation even worse, because users don't read that the tag is deprecated.

[boothym]

@bhousel

iD will stop suggesting the tag when it is no longer in widespread use.

Just curious about this point - sport=football is currently at ~3,400 uses, so how low does it need to go before it stops being suggested in the sports field? Because sport=gaelic_football (deprecated) is at 62 uses yet still gets suggested when typing in either gaelic or football.

[bhousel]

Just curious about this point - sport=football is currently at ~3,400 uses, so how low does it need to go before it stops being suggested in the sports field? Because sport=gaelic_football (deprecated) is at 62 uses yet still gets suggested when typing in either gaelic or football.

Sure @boothym the code is here:

iD/modules/services/taginfo.js

Line 93 in 8720f7e

return parseFloat(d.fraction) > 0.0 || d.in_wiki;

You can also go to taginfo and search: https://taginfo.openstreetmap.org/keys/sport#values Then type "football" in the search box. You can also see the raw JSON results.

Basically for value lookups, the value must have fraction > 0.0% OR have a wiki page.
Since sport=gaelic_football has a wiki page, it gets returned.

[boothym]

Since sport=gaelic_football has a wiki page, it gets returned.

So if gaelic_football goes down to zero uses, it will still be returned because it has a wiki page? Even if the wiki page is only there to tell people the tag is deprecated - probably like the rest in this category: https://wiki.openstreetmap.org/wiki/Category:Tag_descriptions_with_status_%22deprecated%22

[bhousel]

So if gaelic_football goes down to zero uses, it will still be returned because it has a wiki page?

Yes, I think so..

[boothym]

And there's no way to exclude those with status=Deprecated in the wiki (or would that need to be something taginfo does)?

[bhousel]

And there's no way to exclude those with status=Deprecated in the wiki (or would that need to be something taginfo does)?

Yes, we just take whatever we get from taginfo. There are a few related issues in the taginfo repo about this:

taginfo/taginfo#196
taginfo/taginfo#218

Taginfo doesn't have any built in logic to try to decide wiki pages are "good" or "bad" or parse deprecation statuses (which are admittedly pretty arbitrary).

/cc @joto (whom I agree with)