You’re right, this was confusing and thanks for that feedback. The use of “Baltic Sea” as an example was intended to highlight one of the ways that the community has dealt with the issue of multilingual names. I am not proposing to change the community consensus on how Baltic Sea is named - I’m proposing to give an additional option for cases where no single name is appropriate.
For example, the countries that collectively border the Atlantic Ocean speak fifteen languages, which would likely exceed the character limit of name if the Baltic Sea scheme were used. The community consensus for Atlantic Ocean was to simply omit the name tag. However, this caused mappers to insert noname=yes to silence validators, which is wrong because Atlantic Ocean does have a name. There was no tagging scheme we could use to say “the community chose to omit the name tag because of multiple equally-valid languages.”
This proposal is not about what to tag the Atlantic Ocean or Baltic Sea, it’s about providing a tagging option in the case where the community decision is to omit the name tag.
I like where you are going with this. Are there any prior tagging schemes which use “missing” or “reason” that would suggest that those are the right keywords versus other potential synonyms?
For example, the countries that collectively border the Atlantic Ocean speak fifteen languages, which would likely exceed the character limit of name if the Baltic Sea scheme were used.
in the case of an ocean, it is also harder to justify why only the bordering countries should have a say, there will also be “valid” names in “second row” countries and in general, globally, in almost all languages there will be a name for the atlantic and pacific ocean.
Comment is requested on a proposal to introduce two tags to indicate the
reason why a name=* tag has been omitted from a feature:
Thank you for making the proposal. The suggestion makes sense, whether
with noname=disputed or any other new tag distinct from plain noname=yes.
A nice side effect is that I have become aware of name:signed=no which
in turn allowed me to bring this recently discovered
way into a more
mainstream tagging.
This proposal could be expanded to include other languages too, e.g. noname:en=disputed to mean “There’s no one english language name because it’s not clear which that would be”.
Both name:language=* and language:name=* were proposed for this purpose in 2017 and both were rejected. To the extent that name represents the local language, it can only be used for language-agnostic purposes, such as when a renderer wants to render the local name regardless of the language it’s in. Anything more becomes a guess, which is not something we really want to encourage data consumers to do with our data.
This is related to the existing practice of documenting the source of a name with source:name=*. The proposed noname=* values are more like placeholders, there to prevent a mapper from blithely setting noname=yes without understanding the nuance. The values also happen to be machine-readable, though I’m not sure that matters as much, since the audience for these values would be fellow mappers, not data consumers.
With respect to the proposal, the values noname=disputed and noname=multiple_languages could be a source of confusion among mappers. It sounds like a distinction between a real-world geopolitical dispute and a more project-specific goal of language neutrality. However, geopolitical disputes often involve or are even rooted in linguistic differences.
As a reminder, we got here because some mappers believe the name=* of a global feature must be a perfect name: neutral, universal, unambiguous. The parallel thread suggests, not unreasonably, that this is an unreasonable expectation:
In other words, these values are of no (or little) use for data consumers and won’t change anything for the renderer that wants to put a name on the Atlantic Ocean.
Thank you Amanda to bring this here.
It should lead us to a completely mainstream way of tagging, instead of focusing it on names only.
Dispute, lack of knowledge, lack of signage could actually raise on any key as mentioned upside.
I understand that the proposed values are explanatory, and don’t prevent mappers using the name:language namespace, but at first glance they do appear like troll tagging. “No name” because the feature has more than one name might confuse.
I also wonder what the proposal actually solves? Could this information not simply be stored with the note=* key? We could then also have a link to a discussion where a community decision was made. Or perhaps this would be better solved by having some sort of “disputed” tagging scheme (e.g. improving the boundary=disputed tagging, perhaps a dispute namespace?).
If this is mostly to prevent validators throwing a warning, then validators should (if they don’t already) understand that name:en + name:es (for example) means that name is not required.
I’d also note that the key doesn’t match the syntax convention for keys. It should be no_name=*. However, I appreciate noname=yes is already de facto usage so I doubt there’s appetite to change that.
Two different visions oppose here: note=* would be on human readable only side, while a more robust and defined tagging would allow both human readability and machine usability.
To me the second brings more value.
Furthermore, note=* could be overcrowded with all potential reasons to not define several keys, not only name=*
Sounds like an additional reason to not make it reviewed/approved here, despite the capital experience it brought to the community until now.
No, what I meant is that the specific nomenclature doesn’t make a difference for data consumers, which wouldn’t be using the values directly. But the fact that noname would not be set to yes would address the Atlantic Ocean issue. Still, I’m not 100% convinced this is the best way to address that issue; if we can agree on a name, that would be simpler all around and avoid any surprises with tools that have been treating any noname=* as being unnamed.
The difficulty of satisfying these constraints isn’t limited to international waters. As someone on a non-OSM Discord server recently discovered, OSM Americana’s secret multilingual mode includes a “Europe” almost as big as Europe.
