Deprecated tag 'alt_name_1' is still proposed by ID

[iiitomo]

How to reproduce the issue?

1. Select an object (eg a track)
2. in its attributes, start typing 'alt' in a new attribute
3. observe that a list of possible values appears, among them 'alt_name' and 'alt_name_1'.

Remark: if the 'alt_name' key is already in use for this object, the default value of the list proposed by ID is the deprecated tag 'alt_name_1'.

Screenshot

Which deployed environments do you see the issue in?

Released version at openstreetmap.org/edit

What version numbers does this issue effect?

2.23.2

Which browsers are you seeing this problem on?

Firefox

[1ec5]

This section of the sidebar is powered solely by taginfo’s list of most common keys and values. We do have some filtering to avoid autocompleting very uncommon keys and values, but otherwise it’s a pretty raw look at the state of the database. The unfortunate thing is that people may intend to add alt_name but accidentally add alt_name_1 because alt_name is already present.

taginfo doesn’t provide any information about the deprecated status of a tag: taginfo/taginfo#313 taginfo/taginfo#375. Ideally, iD could query the OSM Wiki’s API to find out about this deprecation, but that would be a lot of API calls for individual data items. Probably the only thing we could do is special-case keys ending in _1 etc., but note that there are probably legitimate keys ending in numbers, such as old_ref:pre_1945.

[Dimitar5555]

Would it be possible to scrape the wiki on each new release of iD and generate a blacklist for deprecated keys?

[tordans]

Or, someone could create a MapRoulette Challenge to get rid of this data from OSM for good. It's "only" 12k … https://taginfo.openstreetmap.org/search?q=alt_name_1

The idea of the raw "Tags" view ist to be a sharp knife for those that know what they are doing.

What percentage of new alt_name_1 tags are added by iD (in recent years)?

[bryceco]

@tordans 439 of those alt_name_1 instances are this highway. What is the correct replacement in this case?

[tordans]

@bryceco

439 of those alt_name_1 instances are this highway. What is the correct replacement in this case?

History: I remember reading somewhere (I think in this repo) that most of those _1 keys are from a time when imports where made (TIGER?) and from years ago when iD (silently?) appended _1 to keys whenever a duplication happened in iD. A practice that AFAIk has long been abandoned.

About the replacement: That is a good question for the OSM forum / tagging mailing list / a proposal page IMO. My take would be: We have two concepts to represent "this key has mutliple values".

Appending :1, :2 to tags. I personally never liked this, but the old and recently deprecated parking:lane schema documented it as valid solution. From the top of my head I don't know if any other schemas use this. However, it would be more in line with how "subkeys" are build (like source:maxspeed) than the underscore solution.

A better solution IMO would be to follow the semicolon pattern for key that have multiple values. That's at least well established. And for this particular case of alt_name=Interstate Highway 10 West; IH-10 West; Interstate 10 West, IMO a better solution the those _1s. Data consumers like Nominatim could do a full test search on the semicolon field and still produce valid results.

[1ec5]

I remember reading somewhere (I think in this repo) that most of those _1 keys are from a time when imports where made (TIGER?) and from years ago when iD (silently?) appended _1 to keys whenever a duplication happened in iD. A practice that AFAIk has long been abandoned.

Yes, this is more or less how it played out. At the time of the TIGER import, tagging standards were still fluid enough that it wasn’t absolutely certainly wrong to add these suffixes, but the community definitely soured on them in the years that followed.

By the time iD added this functionality to the raw tag editor, the suffixes were already extremely common due to the TIGER import. iD’s behavior was more relevant for non-name tags; if not for this behavior, it would’ve still autocompleted name_1 etc. based on taginfo statistics. In any case, the suffixing was removed in 640730d.

Most number-suffixed tags that remain need manual review anyhow. For one thing, the TIGER name abbreviation expansion bot only touched name as far as I know, not the suffixed variants.