Don't show value suggestions for full_name, loc_name, reg_name

[maro-21]

Do not show value suggestions for keys: full_name, loc_name, reg_name, short_name, sorting_name, artist_name, nat_name, long_name, bridge:name in All tags.

[quincylvania]

Sorry, we don't support tag-specific functionality in the raw tag editor.

[maro-21]

What do you mean? I don't understand.

[quincylvania]

The "All tags" section is for editing plain keys and values. We don't have code like "if this is the name tag, do something special". That's what the fields are for.

[maro-21]

I meant this: if you add manually alt_name and click an arrow - there are no value suggestions - this is ok. The same with for example name and old_name.
But when a key is one of the above, if you click an arrow, there are random value suggestions from different languages, which is not ok. Because names are unique and it doesn't matter what values were used on the other side of the world.
There should be some code which prevents the editor from listing these values for alt_name.

[quincylvania]

I meant this: if you add manually alt_name and click an arrow - there are no value suggestions - this is ok. The same with for example name and old_name.

@maro-21 Yes, iD automatically ignores the keys with the greatest number of unique values, including name and alt_name but not full_name. Though I suppose this behavior is actually enforced at the service level and not the UI level, so we can ignore these keys in order to be less taxing on TagInfo if nothing else.

[1ec5]

@joto (taginfo maintainer) has previously recommended that we avoid making this sort of query for common freeform keys like name, for which each feature generally has a different value. #3975 disabled value suggestions for the 100 keys with the most distinct values, plus opening_hours:

iD/modules/services/taginfo.js

Lines 201 to 218 in a7ce956

	// Fetch popular keys. We'll exclude these from `values`
	// lookups because they stress taginfo, and they aren't likely
	// to yield meaningful autocomplete results.. see #3955
	var params = {
	rp: 100,
	sortname: 'values_all',
	sortorder: 'desc',
	page: 1,
	debounce: false,
	lang: currentLocale
	};
	this.keys(params, function(err, data) {
	if (err) return;
	data.forEach(function(d) {
	if (d.value === 'opening_hours') return; // exception
	_popularKeys[d.value] = true;
	});
	});

(You can see the same list by sorting this table by the “Values” column.)

alt_name is 30th on the list, so suggestions are disabled. But the other keys mentioned above are much further down in the list.

This heuristic was originally added to prevent slow taginfo requests from clogging the queue. But I suppose it can also be confusing for the user when they enter a value like “ABC” for a freeform tag and it gets autocompleted to “ABCD” just because that happens to already have been entered a bunch of times.

One improvement would be to disable suggestions for a key where the most common value only makes up a very small proportion of the key’s usage.

Conceptually, the number of distinct values for a tag is just a proxy for the key’s data type. Suggestions are most useful for enum-typed keys, less useful for numeric keys, and not particularly useful for freeform keys. In theory, we could query OSM Wikibase for keys whose key type (P9) is well-known values (Q8) and only present suggestions for those keys. But I’m not confident that all the enum-typed keys have been tagged with that statement in OSM Wikibase. There’s a discussion about adding support for additional data types; ideally, we could blacklist keys whose type is “string” or “numeric”.

/ref #3955 (comment)
/cc @nyurik

[maro-21]

I think we can also add dates to this list.
Source:date for example has a value "2014-03-24" used 7,534,698 times but it comes probably from an import so I don't think I will use the same value again ;-).

source:date
start_date
survey:date
source:geometry:date
population:date
check_date
date
source_date
construction_date
end_date
opening_date
survey_date

[quincylvania]

I think we can also add dates to this list.

@maro-21 Yes, there are probably hundreds of keys we could technically exclude here, but I see relatively little benefit compared with the burden it would place on iD to maintain the list.

A smart solution based on data type as suggested by @1ec5 sounds theoretically workable, but I personally don't see it as a high priority right now. The worst offenders are already skipped and users can otherwise ignore unhelpful suggestions 🤷‍♂️

[maro-21]

There are more ;-)
inscription
note:access
note:ja
contact:fax