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
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 other languages normally go in language-specific subkeys like
name:es for Spanish. But in some places, multiple languages are commonly spoken, so there isn’t a single “default” language.
Historically, mappers in some officially multilingual regions have standardized on various ad-hoc delimiters between these names, such as a slash or hyphen, with the expectation that a renderer would lazily show the entire
name tag verbatim. To put a positive spin on it, let’s call this map of mostly the Baltic Sea a celebration of linguistic diversity:
By default, though, Americana does some nicer things with names like tailoring the map to your preferred language. It also appends the name of a city in the local language, giving the map a more cosmopolitan flair and maybe prepping you for your next trip overseas. The main
name key is supposed to be suitable for this purpose, but appending the
name tag verbatim isn’t an option: if one of the names in it happens to match the name in your preferred language, you’d get a verbose, repetitive label, crowding out other labels for no good reason.
Unfortunately, there’s not much else to do when the
name tag forms a list using common punctuation or mere spaces, because these delimiters are so ambiguous:
Some 15 years ago, the global community standardized on the semicolon as a uniform, machine-readable character to separate multiple values in a single tag. It was intended to apply to all tags, and data consumers have done lots of things with it in non-name tags. But mappers have adopted it more slowly for
name than for other keys, probably due to the effect it has on renderers that label
To show the benefit of a more structured approach, Americana now parses semicolons out of every name tag. When the
name:* tag for your preferred language contains multiple names separated by semicolons – say,
name:es=Aquí;Allí;Allá – each semicolon turns into something more presentable, such as a line break. The same happens with
name if you set your preferred language to an unsupported language like
mul (as in “multilingual”), or if the feature is only tagged with multiple values in
name but not tagged with a more specific
name:*. Your preferred language’s name for the feature only appears once, even if one of the local languages calls it by the same name.
San Francisco has multiple names in Chinese, each of them quite common both locally and abroad. Its
name:zh tag contains three names separated by semicolons, which show up if you set your preferred language to Chinese:
In Kaser and New Square, New York, most residents speak Yiddish, so
name contains both English and Yiddish. Depending on your preferred language, you’ll see the names in English, Yiddish, and your preferred language laid out appropriately, without repeating a name:
Americana can only lay out the labels intelligently because the semicolon delimiter is predictable and unambiguous. Unfortunately, ad-hoc delimiters are still much more common than semicolons in names globally and even in the U.S., where there has never been much discussion about delimiters. Hopefully as more data consumers add support for semicolons, mappers will follow suit.
Thanks for everyone who’s already using the standard semicolon to separate multiple values in the
name tag in those tricky situations when other name keys just won’t do. This gives renderers and data consumers of all stripes the flexibility to do something a little more useful with the
name tag, and now you no longer have to worry about the map looking sloppy.
8 posts - 5 participants
Ce sujet de discussion accompagne la publication sur https://community.openstreetmap.org/t/name-lists-in-osm-americana-or-how-i-learned-to-love-semicolons/7686