Indeed, and for reasons discussed ad nauseam, what OSM Carto is capable of showing is unlikely to change.
As far as I can tell OSM Carto would be perfectly capable of parsing a semicolon delimited name tag and displaying the list of names in an appropriate way depending on the feature type. So far the maintainers have chosen not to do so, but this decision appears to be based on the opinion that putting more than one name in the name tag is never correct rather than any technical limitation. Clearly, this opinion is not shared by a majority of mappers, and multiple names in the name tag is an accepted practice where a single primary name cannot be agreed upon. Since the practice is accepted and unlikely to change, it would be better for everyone if the OSM Carto maintainers would reconsider their overly strict position and support the use of the standard semicolon delimiter. The result of not doing this is less usable data for everyone else.
6 Likes
It’s not clear to me from the linked ticket that the osm-carto maintainer team is opposed to splitting names by semi-colon delimiters, just that nobody has done the work.
I was considering perhaps submitting a PR to add name-splitting to osm-carto, but if, as Andy notes, this change would not be welcome, then obviously I won’t waste my time.
A clear position was not really stated here, but the idea was also not exactly welcomed.
I belatedly realized that the declined openstreetmap-carto issue was only about road names, so I opened a broader feature request:
4 Likes
Separately from what one particular renderer will or won’t, or can or can’t support, as a thought experiment it’s worth considering “which name would you pick from a (somehow separated) list if you had to just choose one”. The place=country nodes in OSM are here and there are some interesting edge cases there - mixtures of left to right and right to left, and also places where picking any one name might be an issue to the local community, like Belgium.
Just in theory, if I would create a map mainly targeting for French folks, I would first render Bruxelles and maybe additional Brussel. If I targeting mainly Dutch folks, my decision might be different and if I just want to render a map for Japanese tourists, I might render name:en instead of Bruxelles - Brussel which none of them will get the reason.
Just at the moment without defined delimiter I’m not able to do anything else except just render name as is, as there is no trigger, that there are multiple names existing.
4 Likes
I think the case where a renderer would pick only one is fairly contrived, because language-qualified subkeys are reliably present, and it’s possible to pick from among them based on a user preference or default_language. But if a renderer needs to show all the names but one, because that name has already been listed separately, that’s harder to accomplish without a formal delimiter:
For example, this Algerian city is known as “Bejaia” in English and tagged as Béjaïa Bgayet ⴲⴳⴰⵢⴻⵝ بجاية in the local languages. If a map wants to label the city in English, followed by the local language(s) in parentheses, a reasonable treatment would be “Béjaïa (Bgayet / ⴲⴳⴰⵢⴻⵝ / بجاية)” (adopting the local language’s diacritics, a common American practice). You might think, no big deal, just look for a whole-word match and allow the delimiter to be a mere space. But by that logic, Cartagena would be “Cartagena (de / Indias)” for English speakers. For speakers of some languages, Havana would be “Habana (La)”.
1 Like
(link)
(link)
(link)
Certainly you can render all the desired names in different languages, that is not a problem at all. The bigger issues is when you want to also provide the local language(s) also. This is not so bad for the Japanese version, which has three distinct names for Brussels, but it produces an undesired result for the French and Dutch, because the glossed local name (Bruxelles - Brussel) repeats the main French/Dutch label. If this had been delimited, we could check each name in turn and determine whether to show it.
You’ll note from my Dutch screen shot that one of the things we’ve done is to omit the glossed name when it exactly matches the local name, as repeating the same text would be silly. However, compound names make that feat impossible without a consistently-reliable delimiter.
4 Likes
Exactly that I was talking about, maybe I expressed it not that clear. Of course it’s possible to render name:fr & " / " & name, but it will look ugly, as on your pictures shown above and in different regions I’m getting different separators.
Americana map is doing already very well regarding this topic 
1 Like
And different from most (all?) the other examples mentioned here in that we are not talking about two languages. Derry and Londonderry are both English-language names, and both name and name:en are tagged as “Londonderry/Derry”. The Irish Gaelic name is Doire. Incidentally I see alt_name is tagged as “Stroke City” in reference to the chosen punctuation - I don’t think OpenStreetMap has enough influence to change it to “Semi-colon city”!
Another tricky example is Vitoria-Gasteiz in Spain, where the name tag does not match either of the local language tags (name.es and name.eu), but does match the tag for most “foreign” languages including English.
3 Likes
The “-” or “/” often reflects the way local cartographic and signposting has traditionally dealt with the issue. It would make sense for OSM to adopt a single convention rather than maintaining a variety of local ones.
I believe it is at least equally valid to maintain a variety of local cartographic and cultural traditions.
This is no different than we do for any set of values.
there are other exceptions as well, IIRR house numbers can be separated by comma.
Each one of those place names should also appear in the appropriate name: list so Nominatim can parse them correctly.
yes, that’s common practice, although it doesn’t tell you which language the name tag is in, it helps if you are interested in specific languages.
We have discussed this some years ago and there were also several solutions, however none of them is established at the moment.
In most places, separating names with a dash or a slash is usually a stylistic choice, not unlike abbreviating or unabbreviating a word in a name. I recognize that there are places like Northern Ireland and New Zealand where the delimiter is also specified officially, but in these cases, arguably the name itself includes the delimiter. I don’t think these cases should unduly influence the practice in other places where there are two distinct names.
Whatever the local convention for separating names in prose, does it violate the convention to place each name on a separate line where space allows? Should it be the role of an OSM mapper to dictate the typographic style to all data consumers, including non-renderers, or should these data consumers have the flexibility to choose an appropriate delimiter – perhaps taking into account the conventions of the user’s own language?
4 Likes
Reading the reactions there, I get the impression, that for OSM-Carto ad-hoc delimiters are not much of a problem. If other consumers have problems with this practice, they should go the usual way of handling that in the community.
Apart from the mentioned 2014 conjecture, that a single feature can only have a single name - this I doubt, it was not valid then, it will never be valid, in fact it won’t pass muster with the reproducibility doctrine in openstreetmap - talk there states some aspects, that go beyond that.
I cannot follow the argument given there though, that if a universal delimiter got appointed, OSM-Carto would have to somehow unsopport ad-hoc delimiter use, as actually, it cannot do that, because there is no measure to decide, if a dash or a slash or whatever is a delimiter in a list of names or a legitimate part of a single name.
PS: Obligatory xkcd: Exploits of a Mom
2 Likes
To add another example of a feature with two equally important names in the same language, many roads that straddle county boundaries in the United States have a different name on the left and right sides:
- South County Line Road; East 1400 North, Elkhart and Kosciusko counties, Indiana, US
- County Road T; County Road FF, Dolores and Montezuma counties, Colorado, US
2 Likes
Just to add another “rendering example” - I have maps at https://map.atownsend.org.uk/ where the name tag can come from one of four different places:
- name:cy in welsh-speaking parts of Wales
- name:gd in Scots Gaelic-speaking parts of Scotland
- name:en in England, and the rest of Scotland and Wales
- name in Ireland.
This avoids issues with some “/” names that were breeding in Wales at one point, sidesteps some historic anglocentric naming in Scotland (now largely resolved, actually) but does honour community-agreed multilingual naming for e.g. Londonderry/Derry where people have been more sensible with it**. Obviously this doesn’t help with the literal edge cases that @clay_c mentions above, but it does mean I can completely ignore the “name” tag most of the time.
Just to be clear - this is all with old-school raster tiles, and there’s only one set of tiles here - when the database is loaded the different geographical areas are split out, translated, and then merged back.
** Personally I’d have gone for “Dingle / An Daingean” rather than “Dingle - Daingean Uí Chúis”, but that’s a debate within Irish language circles.
1 Like
I posted in Reformat semicolons in names · Issue #4755 · gravitystorm/openstreetmap-carto · GitHub that some examples from this thread (not known to me at that time or ignored, that was some time ago) convinced me otherwise.
BTW, it may be worth mentioning this examples at related OSM Wiki page.
1 Like
My conclusion after reading the issue and related discussion is that the “/” character is pretty much a hack to show two names at the same time. I find this a strange work-around as place labels should be based on user’s prefered language and available translations. Though I get sense the real reason is due to European customs that I am not familiar with. If this the case the ln we really should come up with a better solution.
See Derry/Londonderry name dispute - Wikipedia for an example where this is not enough.
In OSM it is here: Node: Derry/Londonderry (267762522) | OpenStreetMap
4 Likes