Add some common name fields

[1ec5]

Added some of the most common name fields as universal fields to all presets:

• Local Name (loc_name)
• National Name (nat_name)
• Official Name (official_name)
• Regional Name (reg_name)
• Short Name (short_name)

For this round, I omitted some common name fields because they weren’t as straightforward:

• alt_name and old_name are likely to be localized and contain multiple values at the same time, but neither semiCombo nor localized provides all the necessary functionality.
• sorting_name is especially relevant in some languages but completely irrelevant in others, so it would be nice to filter the localized field type’s language list accordingly.

Fixes #283 and fixes openstreetmap/iD#1554.

[tyrasd]

Should the name field be added as a prerequisiteTag of these additional name fields?

For this round, I omitted some common name fields because they weren’t as straightforward:
alt_name and old_name are likely to be localized and contain multiple values at the same time, but neither semiCombo nor localized provides all the necessary functionality.

The wiki says that multiple valued names are the exception: “In rare cases, the key is used for multiple semicolon-separated names, e.g. alt_name=name1;name2;name3, but this usage is not preferred.” I would say that a regular localized field is also good enough for alt_name and old_name.

sorting_name is especially relevant in some languages but completely irrelevant in others, so it would be nice to filter the localized field type’s language list accordingly.

ok, let's omit that one (it's also used relatively less often than the other mentioned "names" here: 20k occurrences vs. 100k+ for the others). It might be included in the future on a per-region basis, perhaps.

[1ec5]

Should the name field be added as a prerequisiteTag of these additional name fields?

That may be too strict, since I’ve heard of mappers using combinations like highway=* ref=* noname=yes official_name=* when the official name is too obscure for renderers or routers to present to end users.

[tyrasd]

OK, but in my opinion that seems to be rather an exception / edge case. Also iD currently doesn't "really support" the noname tag anyway. The benefit of having name as a prerequisite tag here would be that users would be nudged towards not only mapping the specialized names, but always also map the canonical name of a feature. 🤔

[1ec5]

noname + *_name also struck me as a contradictory edge case at first, but the memorial highway name designations raised in this discussion are very common in some regions. It’s a complex situation, so I was worried about the editor seeming opinionated about where to put these memorial name designations. But you have a good point about noname not having a field of its own. The negation properties (including not:brand:wikidata) are usually the domain of validator suggestions rather than fields.

I’m willing to try making it a prerequisiteTag and revisiting later if it turns out to be a problem. When applied to a localized field, should iD require for example name:fr in order to show alt_name:fr, or should it only operate on the main part of the key rather than the language subkeys?

[tyrasd]

When applied to a localized field, should iD require for example name:fr in order to show alt_name:fr, or should it only operate on the main part of the key rather than the language subkeys?

Good question. I would say that for a first iteration it's ok to have the fields operate independently (only based on the main part of the key), but perhaps this could be improved further down the line. It could be slightly tricky to balance the UI for this, though: Some places (e.g. major capitals) have lots of name:<lng> tags while typically much fewer (translated) alternative names. A different situation would be in multilingual regions where it could perhaps make sense to sync up locales between the fields. 🤔

[1ec5]

I would say that for a first iteration it's ok to have the fields operate independently (only based on the main part of the key), but perhaps this could be improved further down the line.

Would this be considered a showstopper for this PR, or can the PR land as is for now while we track this idea in a separate issue? These fields are hidden by default unless already set, so clutter wouldn’t be an issue.

[1ec5]

This PR was mentioned in this forum discussion as a way to help mappers avoid listing multiple values in name, at least in some cases.

[1ec5]

Also mentioned in this forum discussion as a way to keep name:en from being conflated with int_name.

[1ec5]

@tyrasd can you please give this PR another look? Mappers keep making controversial edits (politically sensitive in this case) possibly because they don’t know about alt_name.

[tordans]

@1ec5 is there a preview on this PR? Maybe its older than the preview-generator; in this case another change to the PR should re-trigger the preview generator, I think.

I wanted to look into the preview to understand if those new files are "moreFields" or always visible. I don't think having them visible always where a good idea. It will lead to people duplicating terms just to fill out fields…

[github-actions]

🍱 Preview the tagging presets of this pull request here: https://pr-215--ideditor-presets-preview.netlify.app/id/dist/#locale=en.

[1ec5]

I wanted to look into the preview to understand if those new files are "moreFields" or always visible. I don't think having them visible always where a good idea. It will lead to people duplicating terms just to fill out fields…

These are “universal” fields, which behave like “moreFields” but are available regardless of the preset.

[tordans]

@1ec5 I looked this over to get it merged. I read the thread the way that Martin's request was to add name as prerequisiteTag for the fields:

• Add some common name fields #215 (comment)
• Add some common name fields #215 (comment)

I would feel comfortable to merge this without further discussion once that is applied.

[1ec5]

name is now a prerequisite for the other five name fields. I’ve also added an Alternative Name field for alt_name=*, as requested in #215 (review).

As you can see from the preview, a localized field only appears based on the base key, not any localized subkeys. So even though this way has name=*, alt_name:en=*, and alt_name:es=*, the Alternative Name field doesn’t appear by default unless you manually select it from the “Add fields” menu. At that point, iD reveals that there are alternative names after all, just not one in the feature’s primary language:

This applies to the other name fields as well. I think this behavior is suboptimal because some languages simply don’t have an alternative name to speak of while others do, but I think we can track it in openstreetmap/iD#10323. It isn’t a showstopper for landing this PR.

As of openstreetmap/iD#10181, universal fields now sort below preset-specific fields in the “Add field” menu. For some presets with many optional fields, inexperienced users will be less likely to find these name fields. It’s unfortunate but not a blocker for landing this PR.

[tordans]

@1ec5 the general setup of this works as expected.

I checked the wikidata item descriptions which look good as well.

One thing I am still wondering about is, what the difference between those three names actually are https://taghistory.raifer.tech/#***/loc_name/&***/reg_name/&***/nat_name/
Wikidata just repeats the name…
And the wiki is even less helpful https://wiki.openstreetmap.org/wiki/Names#Local_names_(loc_name).

My question is, as a mapper, when I see the options in the more tags dropdown, how will I know when to pick local, regional, national?

I wonder if we should at least remove the regional name with only 40k usage. Or maybe make that an unsearchable field (is there such a thing?) so we only expose what is there, but not offer it in the dropdown.

The difference for local vs. national seems a bit easier to make. Even though I would expect the name or official_name to be the national name …

[1ec5]

The loc_*/reg_*/nat_*/int_* keys are consistent with *_ref, and we can see the same pattern in the three-letter acronyms for network=* in recreational route relations and some of the most common values of flag:type=*. (I left out int_name=* but should probably include it too…) The terms are perfectly intuitive to me in American English, but maybe not in some other dialects or languages?

I don’t think these fields or the documentation should clearly spell out when “local”, “regional”, and “national” apply. There are already complaints about the global “Key:name” page being too long and difficult to digest, so I don’t think going into detail about each country’s peculiarities would help matters at all. Instead, local communities such as Canada should document country-specific expectations on their respective pages.

The raw usage numbers are not particularly meaningful. These keys often clarify geopolitical disputes (some of them quite petty). One I’m familiar with is this lake, for which the national government insists on one name (which national map publishers follow), the locals insist on another, and the state government has sided with the locals. reg_name=* will naturally see less usage than the other two, because most countries aren’t so large and complex that three-way naming discrepancies would ever arise.

This is not to say that the four-way local/region/national/international name classification system is perfect: in the U.S., we sometimes see disagreements at a local/county/state/national level over the name of something, not to mention cross-border disagreements like this lake that’s been the subject of a bitter disagreement over the name between two states. But those situations don’t have clear tagging solutions, whereas these keys are clear solutions for enough situations.

Or maybe make that an unsearchable field (is there such a thing?) so we only expose what is there, but not offer it in the dropdown.

I don’t think this option currently exists. But the stakes are already very low if all we’re doing is putting some more items in this menu. If this PR had been merged in its current state three years ago, I’m pretty sure we’d look back and agree that the benefits would have outweighed any confusion from not knowing the difference between a local or regional name.

reg_name=* demonstrates the point I made in #1229 (review): this key has been used widely for almost 14 years. Nominatim supports it, as do Telenav’s products. Though usage of this key isn’t increasing dramatically, do we have any reason to believe that it would generate global controversy or get rejected in a vote? On the contrary, if we add support for loc_name=* and nat_name=* but not reg_name=*, there is a potential for edit-warring among mappers unaware of reg_name=* as an option.

[tordans]

Thanks for taking the time to get into this more @1ec5. I know this is tedious, but in feel better looking at more angles for a case like this (where I plan to merge something prev. reviewed, long open and global…).

I will merge now, based on the thinking that those fields will mainly present data that is already there – which is a big win – but not cause any "lets fill out every field just because it is there" kind of mapping (which we should avoid with our presets if possible). I think the prerequisiteTag was a good addition to that.

I am still unsure that mappers will really understand when to use loc_name vs. reg_name. And I still thing that the wiki should give guidance on how to use those tags. Eg. one thing I notices with spot checks is that both tags are used with the same value. Which to me falls in the "better save then sorry" and "don't know what each tag will to, cannot hurt to add both" category. Which are indications for a lack of guidance and documentation. But I agree, the tags are used all over the place, so we should make them visible (https://taginfo.openstreetmap.org/keys/reg_name#map vs https://taginfo.openstreetmap.org/keys/loc_name#map vs https://taginfo.openstreetmap.org/keys/nat_name#map). And this kind of wiki updates it not a prerequisite for us merging here, IMO. Fixing the double tagging – or even talking about if that is actually a problem – is also out of scope for this repo.
On the topic of "Unsearchable field": Agreed, the schema builder does not talk about it and the impact is low.

---

Unfortunately we missed the 1k days mark since the PR was opened (1,072 days says ChatGPT) and are a few weeks short of the actual birthdays. ;-)

[1ec5]

Thanks, I do agree that there should be documentation about reg_name=* somewhere, just not on the already overloaded “Key:name” page, which is not about that key. Someone started a bare-bones “ES:Key:reg_name” page in Spanish; a dedicated page about the key could elaborate, though I think country-specific pages would be more sustainable in the long run. Otherwise, a global page will become a pointless comparison exercise, as it has for admin_level=*.

#1288 tracks adding a field for old_name=* and #1289 tracks adding one for int_name=*. I omitted both fields from this PR due to more severe disagreements about how they should be used. If anyone wants a sorting_name=* field, they’d be in a better position to explain why it’s needed in their language than I would.