RFC: Intentionally omitted name tags

[Minh_Nguyen (Minh Nguyễn)]

@rainerU

There have been many discussions on this topic, mainly concerning bi- or trilingual territories and, if I remember correctly, they all ended up with a hyphen or slash separated list in the name tag as solution.

@ZeLonewolf

This discussion of documenting the list of local multilingual names for a feature is interesting, but is off-topic.

But boy have I got the thread for you:

Multiple delimited names in the name tag

Recently there has been discussion in #communities:us and #communities:de about the practice of putting multiple names in the name tag. I’m starting a topic here because the scope of discussion expanded fairly quickly. Original local topics: Slash-separated Native American names Wie sollte man mit der Zweisprachigkeit (u.a. Straßennamen) in der Lausitz umgehen?

Name lists in OSM Americana; or: how I learned to love semicolons

OpenStreetMap Americana has joined other prominent OSM data consumers in supporting the semicolon delimiter in names. I tell you, a cat must have three different names Normally, keys like name are only for the feature’s primary name in the local language, while other names are relegated to different keys such as alt_name, official_name, and short_name. But sometimes a feature has multiple names of equal standing due to an inconsistency, border, or dispute in the real world. Likewise, names in o…

---

@rainerU

Each renderer who wants to display names as used by the local population would need its geographical database with information about the lingual situation for any point to be rendered. I as a renderer would expect this data from my geographical data provider, OSM in particular.

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.

@JeroenHoek

Instead of omitting name because it is disputed, why not document that it is and give data consumers who care the option to decide based upon that information?

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:

@ezekielf

But expecting a named feature to have a name tag seems like a reasonable expectation for a data consumer to make.