I’ve noticed slash-separated Native American placenames popping up in a few places, for example:
name=Oneida / kanaˀalóhaleˀ
Is this a community thing or a lone mapper thing (insofar as there’s ever a distinction in OSM)? Not sure whether I should be adjusting my rendering code accordingly.
Mostly a lone mapper thing, but it’s a de facto accepted practice. Some mappers have taken it upon themselves to add the native names of reservations and settlements, not without some controversy, but in general we would like names to reflect what locals use. We even add Yiddish names to some predominantly Hasidic Jewish communities. Wherever name=* is multilingual, we add name:en=* as well.
That said, these names are mostly added by non-natives with little local context, so it’s not always easy to verify them. Some reservations have been mapped with the name of the ethnic group(s) inhabiting them, rather than the name of the administrative boundary. The Navajo Nation, being the largest reservation by land area and having the most widely spoken Indigenous language north of the US-Mexico border, is a rather easy case, with well-documented distinctions between these concepts:
The entity mapped on OSM here is the Navajo Nation Reservation, so it’s appropriate to use Naabeehó Bináhásdzo in this case. But not all tribes have such a distinction, and if there is one, it may not always be well-documented. For Pueblos (small tribes in New Mexico centered around villages) like the Zia Pueblo, the name of the people may as well be the name of the village and the reservation.
Ideally we would like to engage tribal communities more in mapping their own lands. This would make it easier to verify place names, not to mention it would give tribes a sense of stewardship over their part of the map.
Ideally I’d rather just see one name in the name tag, regardless of which language it is in, and then the appropriate name:lang tags to clarify the situation. If a name tag does have more than one name in it, then they should ideally be semicolon delimited to give data consumers more flexibility. I would consider other delimiters such as / in a name tag to be a tagging error.
Where applicable, I think the Native American name should be on an object but I do not think combining names in different languages in the value of the name tag is the way to do it.
Near as I can tell, there is an ISO language code for all of the Native American languages that were/are used in my area. I suspect that is true for the rest of the US as well. The wiki is pretty clear about how to tag an object with names in different languages and I don’t see why we need to invent a new scheme for Native American languages.
For my preferred mapping style see Mt. Pinos or Mt. Lemmon. These are mapped slightly differently in that Mt. Lemmon has the native name value in the alt_name tag as well. I know that some map renderers will take that and display both the English and native names which would achieve the goal I think was desired by the mapper(s) who combined the names with a slash. Here is a rendering of Mt. Lemmon that picks up the alt_name:
One issue I will note is sometimes the easy Native American name to find is for one dialect of the language and it may not be clear which dialect it is and therefore which ISO code to use.
Morocco:
I would say that the practice of putting multiple language/script values in a name tag is an accepted practice but there’s no standardization as to how they’re delimited. This also presents a rendering problem for us (OSM Americana) as well, and right now we just live with these labels just showing up on the map when we need to render a local name.
In the case of Oneida, New York, I think this is little more than linguistic geekery on the part of one non-native speaker. The Native American population of Oneida was estimated at 1.0% as of last year, and the Oneida language has no official local standing as far as I can tell. There’s no problem with tagging the Oneida-language name as name:one=kanaˀalóhaleˀ or the town’s namesake as name:etymology:wikidata=Q1572875 (the Oneida people), but it’s misleading to stuff the name in name as if it’s one of the town’s primary names in use. Otherwise, hang on while I rename New York City to “New York;Nueva York”.
Agreed. Data consumers can and do pretty-print the semicolon as some other punctuation, such as a slash or em dash, but that’s a matter of style; matters of style should not be dictated by OSM.
Mappers will never accept semi-colons appearing in rendered names on osm-carto. Unless that problem is solved, semi-colon delimiters in the name tag is a non-starter.
So is tagging for the renderer. 
Tagging for the renderer is absolutely an accepted practice (hence the space and slash delimited names).
Let’s not mix that up with mis-tagging for the renderer.
It is mistagging for the renderer – a particular renderer at the expense of others. It’s one thing when a multilingual name is specified to have a slash in reality, such as “Aoraki / Mount Cook” in New Zealand, or when a monolingual name contains a slash, as in “Parkview/Woodbrook” in Baltimore. The point of a semicolon delimiter is to be able to distinguish cases like these from cases where a different delimiter wouldn’t be a misspelling.
To the extent that other delimiters are an accepted practice, I don’t agree that it’s an accepted practice in the U.S. Many POIs in the U.S. use a semicolon as a delimiter for multiple names.
I’m surprised that you didn’t bring up the example of Londonderry/Derry! Of course, that’s a case where there’s two alternatives to the name, depending on national/political affiliation, and picking one to go in name and the other to go in alt_name would be untenable.
While I (to be clear) agree that semi-colon separation would be the right answer from a data model perspective, the fact that a semi-colon would appear on the osm-carto map makes this a utopian, ivory tower discussion that would be unacceptable to the mapping public.
However, if osm-carto were to treat semi-colons like spaces or line breaks, this would be a 100% workable solution. If osm-carto already does this, please stop me now…
This can go one of two ways:
name tag is “mis-tagging for the renderer” or “lying to the render” and should be called out as a tagging error, despite the practice being widespread.I don’t particularly care either way, as long as data consumers can be convinced to get on board. Currently some data consumers support semi-colon delimited values, and I’m not aware of any that support slash delimited values. So the semi-colon route seems more likely. Currently "/" (solidus), " " (space), "-" (hyphen), and "#" are called out on the wiki as old separators that should be replaced.
I mean… it’s obviously not lying to the renderer. Those slash-separated names are in fact names used for the thing. The harshest criticism we can really give this practice is something like “formatting data to look nice on certain renderers while making things hard for other data consumers”. This isn’t the same as tagging a flowerbed as landuse=commercial because it renders in pink on osm-carto.
This is the United States subcategory, and the place in question is in the U.S. There’s no global standard for a particular delimiter in place names – far from it.
In the case of Derry/Londonderry, mappers have had to add a semicolon-delimited alt_name just so Nominatim will find it by both names.
I disagree with the implication that replacing the semicolon with another delimiter or truncating the result at the semicolon is a blue-sky idea. To the contrary, styles based on the Mapbox Streets source replace the semicolon in this way with an em dash.
When GraphHopper tells you to turn onto this road, it replaces the semicolon with a comma:
The Mapbox Navigation SDK puts the names on different rows and says just one of the names aloud for brevity.
This is within the realm of possibility: since 2014, openstreetmap-carto has been replacing semicolons in ref with a newline. However, the maintainers declined to pretty-print semicolons in name based on the opinion that name should not have multiple values in the first place. We can see that this decision has backfired, encouraging mappers to add multiple values anyways but in unstructured form.
For sure, it would be a monumental task to persuade mapping communities in multilingual regions to change their agreed-upon name delimiters, but that’s off-topic here. I’m not aware of any entrenched standard in the U.S. This is an opportunity to establish the semicolon as the standard delimiter for the relatively few cases where name needs multiple values in this country.
The only reason why a slash has become so prevalent in U.S. place names over the past month or so is that one mapper unilaterally applied it across the country. They’ve also been chided by Canadian mappers for the same practice.
It’s a minor lie for sure, but I do consider it a lie under the current guidelines*. name=Oneida / kanaˀalóhaleˀ asserts to a data consumer that the one primary name for this feature is “Oneida / kanaˀalóhaleˀ”. This is incorrect since that string contains two different names. name=Oneida;kanaˀalóhaleˀ asserts that the two co-equal primary names for this feature are “Oneida” and “kanaˀalóhaleˀ”. This would be correct in a case where neither name is more primary than the other. In this particular example, that is probably not true as @Minh_Nguyen noted earlier, so just take this as a hypothetical example.
*If the guidelines were to change to say that slashes are acceptable delimiters and data consumers should treat them accordingly (including spaces around them), then I would no longer consider it a lie. However, that would mean that slashes would need to be escaped in names that truly include them. The semi-colon was chosen as a delimiter for good reason.
Here is a test case in the US that I modified to use the semi-colon delimiter.
In addition to render support, editor support will also be needed (example from JOSM):
I believe this is also an issue in osmose.
Thanks, bidirectional text is a great argument for a formal delimiter. Computers have a lot of difficulty deciding whether mixed-direction text should be reversed or not, and a language-neutral punctuation character doesn’t help at all. In Unicode plain text, displaying bidirectional text in the correct order sometimes requires the use of invisible control characters. I think most mappers would prefer to use a semicolon that would be parsed out more literally.
Osmose has been flagging the slash-delimited name anyways. I asked the developers to exempt any double-barreled name that’s a concatenation of multiple other name tags:
Good discussion - thank you!
Generally I’ve seen the slash as a political compromise when a place really does have two equally used names. As alluded upthread, “Londonderry / Derry” is the obvious one, but there’s also “Bruxelles - Brussel” (with a dash rather than a slash… sigh).
In the UK, and Wales in particular, we follow the general principle (which I think is sensible) that the name= tag reflects the dominant language spoken locally. So it’s Swansea rather than Abertawe, but Y Bala rather than Bala. There are a few rare examples where the slash is used because there isn’t one dominant language (Aberteifi / Cardigan, and Ynys Môn / Isle of Anglesey).
But I’m aware that this isn’t a universal practice, and we did have one rather awkward episode a few years back where a mapper from another country came to study in Wales, and assumed that the “slashes at every opportunity” approach from his home country would also apply there.
It seems logical to me that applying the Wales principle in the Oneida case would result in removing " / kanaˀalóhaleˀ" from the name tag, given @Minh_Nguyen 's stat of a 1% population. But I’ll leave it to you locals to have that fight
In the meantime I’ll do a little bit of work on my Lua rendering profile for North America to filter out this sort of thing.
