For disputed areas, please use the name as displayed on, e.g., street signs for the name tag
Put all alternatives into either localized name tags (e.g., name:tr/name:el) or the variants (e.g., loc_name/old_name/alt_name)
This wiki does not mention the case discussed in this topic, where there is no default common name. We seem to converge to the notion that name should hold the undisputed common name, if there is one, even when there are no name signs on the ground. Then this case shoud at least be mentioned as a special case/exception.
I also think the term “default” is not right. It’s not a name used when all other names are missing, it is the verifiable name. If other variants exist, it is up to the renderers/data users to determine the rules and priorities for the use case of their particular application. Defaulting is a processing rule, not an attribute.
Maybe “undisputed common name”? With absence of ground truth as a special case.
Having read a bit here, so curious. Met someone from southern Iran today, it seemed he stressed “Persian” more than gulf, he showed me the google maps, I asked to look at openstreetmap - there was no Persian gulf there and no Arabian gulf - he could read all the scripts no matter which side, nothing! Just now looked it up back behind the keyboard, Nominatim has a hit for Persian Gulf - takes ages to load that beast. Nominatim also finds “Arabian Gulf” does it have two name:en? (Update: Yes, alt_name:en)
At least for me when logged out, Google Maps labels the gulf as “Persian Gulf” and “Persian Gulf (Arabian Gulf)” if you zoom in a little further. I’m seeing this regardless of language when appending &hl=LANGUAGE_CODE to the URL. However, reputedly, the priority switches depending on IP geolocation, so you might see something else in every language. In order to facilitate something like that in OSM-based data consumers, the relation would need to be tagged with all manner of name:*-IR, name:*-SA, name:*-UE, etc.
Incidentally, the name is the Arabic for “Arabian Gulf” as of changeset 138,526,663. The comments in that changeset explain the choice of name.
I did comment on the CS, I just felt like that. Curiously, in the group, there was a woman from Hungary that never ever heard of the Persian Gulf yet decidedly said to know the Arabian Gulf (she meant the Red Sea.) So, which name is name:* and which is alt_name:* may also be locally decided?
PS: The man from Southern Iran consulted google in the German locale and “Arabian” was in put in parentheses below “Persian”.
PPS: Interestingly, in historic times, the Red Sea was indeed called “Arabian Gulf” (source Wikipedia.)
As far as I can see, since July it has not been tagged with noname=yes, yet it is still not being rendered.
name=* is still missing however (whether correctly or not), so it seems just this condition alone prevents rendering?
If so, this seems like an issue with OpenMapTiles to me. The name:XX tags overrule no name tag (just as they would if there were indeed a name tag). If there is no name:XX for a user’s language tagged, then omit the rendering.
(Purely out of interest, I wonder what would happen if we set the name value to a white space…presumably it’d then render?)
Correct, it’s the lack of name that prevents it from rendering. noname is only relevant to this discussion because some mappers, probably acting on the advice of a validator warning, add noname=yes to affirm that they don’t think the feature should have a name.
This is the cruxt of the issue. name is defined as a feature’s primary name(s). But do we say that a massively multilingual feature, such as an ocean, has many primary names, a primary name that is null (meaning the ocean is unmentionable?), or a primary name that nonetheless we would feel comfortable replacing with a localized name when presenting to a user?
To me, name:* without name is just as awkward as *_name without name. We don’t omit name from this reservoir just because the state and federal authorities have competing reg_name and nat_name for the same lake, or from this river because each of the countries along it speaks a different language. Hardly anyone knows the name of this islet, but that doesn’t mean it should be tagged alt_name without name.
It has no primary name but it has (already-tagged) localised names which can, and should, be rendered.
My opinion (for various reasons) is that English is good enough as a fall back and I would be fine with that being used for name (but I am from the UK, so I’m not entirely unbiased in this).
However, in some ways, that is a separate topic. OpenMapTiles does read in localised names. The omission of name shouldn’t prevent it (or any other renderers) rendering name:XX as appropriate (the exception being if the appropriate localised name isn’t tagged).
OpenMapTiles only includes named features in its label layers since including all features would be a waste of resources. Clearly the code authors assumed that any feature with one or more *_name or name:* tags would also have a name tag and therefore testing for the presence of name would be sufficient to identify if a feature is named or not. This seems entirely reasonable to me, but the logic clearly breaks if we are going to accept the lack of name on a named feature as valid tagging.
More complex logic for identifying named features could surely be written. The condition would need to check for all possible name key variants, or all matching a certain pattern. Or we could just keep things simple and say that a feature with one or more *_name or name:* tags but lacking name is a tagging error.
Presumably the addition of name to any of these features would not be accompanied by the deletion of any *_name or name:*. If name is removed, inevitably leading to the addition of noname=yes, this also would be an oversimplification. Worse, it would be conflated with the situation in which something no longer has a primary name (just an old_name) in the local language but may still be known by a name in some less relevant language. This surely happens sometimes with places and natural features.
Obviously, there cannot be competing *name:*= on rivers where both sides speak the same language, but still have different names - so how is that handled, in case of the lakes mentioned? In my area this affects a river/stream that makes the country border.
I don’t know of a waterway with this, but in Ireland, we use regional language suffixes to tag that a certain place has a different name in (Hiberno) English name:en_IE and (British) English name:en_GB. Perhaps that approach could be useful here
To elaborate on my earlier example, this reservoir is located entirely in Ohio. However, locals and the state government, which manages the lake, insist on referring to by a compound name, while the federal government insists on a simplified name due to federal naming policy. Both names are in the same language but have different scopes, which are clarified by loc_name, reg_name, and nat_name, with name breaking the tie in favor of the local and state name.
Adding a border to the situation, this reservoir straddles the Georgia–South Carolina state line and is managed by the federal government. The reservoir was originally named Clarks Hill Lake. Later, at the federal level, it was officially renamed after Thurmond, as a birthday present from a South Carolina senator to a Georgia senator. However, the states are free to continue calling it whatever they want. Most people on both sides of the border still call it Clarks Hill Lake, which the federal government recognizes as an alternative name. We have that as the name, with Thurmond relegated to an alternative name.
Similarly, this reservoir straddling the North Carolina–Virginia state line is also managed by the federal government. It was originally named Bugg’s Island Lake (or Buggs Island Lake due to the federal rule against apostrophes), but Congress later renamed it the John H. Kerr Reservoir after the Congressman from North Carolina. North Carolinians call it Kerr Lake, but Virginians prefer its original name, having tried unsuccessfully to revert the federal name.
Based on @amapanda_ᚐᚋᚐᚅᚇᚐ’s example, I’ve addedname:en-US-NC and name:en-US-VA to the Kerr Lake relation (hyphens, not underscores, per the BCP 47 standard). It feels weird to use ISO 3166-2 codes here, as though there are two dialects called “North Carolina English” and “Virginia English”, but it gets the point across. I also changed the name to Kerr Lake;Buggs Island Lake, accounting for the fact that it mostly lies in Virginia.
Regardless, we don’t split the lake along the state line, because it’s still one lake in reality, and both states apply the name to the entire lake. This “dialect”-based solution also applies in cases where a jurisdiction insists on a particular name for a feature that it does not claim for itself at all – probably relevant to seas and the like. But it doesn’t absolve us from having to pick one or more names among the various possibilities.
That’s what I initially assumed with my river basins map ( see other forum post), until I saw all the gaps. Eventually I just looked for the presence of any tag key matching the /name(:.+)/ regex.
Rivers are also interesting because sometimes a name applies only to part of the river, even within a single language. For example, in Vietnamese, the overall Mekong River is called sông Mê Kông, but its distributaries are known by a variety of unrelated names, and collectively the river system within Vietnam is known as sông Cửu Long. In other words, the Mê Kông arises in China but the Cửu Long arises at the Cambodia–Vietnam border. In practice, Cửu Long is never translated into English, which applies the same name to the entire river.
Here there are three local (and official) languages competing for the name tag. Norwegian, Russian and Northern Sami. None of them have a clear dominance of use in the area, so the tie can’t really be broken. Yet the river isn’t nameless; it has names in all three languages.
I’ve set the name to Vuorjám - Jakobselva - Ворьема, covering all three languages, but I dislike this solution. I’d love to be able to remove the name tag here, but still achieve the same rendering effect by having carto understand that it should make use of the name:no, name:ru, and name:se tags instead.
This is, IMO the same problem as with the Atlantic Ocean, only that one cannot reach for the lazy option of “let’s just go with the English name”.
The presence of different languages for each region makes it easier. There is no need to split the baby in terms of language. You end up only having to handle one name per region/language.
A semicolon separated list of names would also be a fine solution for the Atlantic Ocean name tag if several languages could be chosen. However I suspect with an object of global scale this list would get out of hand quickly.
