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.
As is typical, there was quite a bit of discussion but no indication that such a feature would be welcome. Best not to worry about what carto does and focus on other styles that are open to forward progress instead.
Correct, that was in response to a question specifically about monolingual naming discrepancies, but I intentionally chose examples in which the federal and state agencies have shared jurisdiction over the same body of water: the U.S. Army Corps of Engineers owns the land and manages the reservoirâs water level, but you obtain a fishing permit from the state Department of Natural Resources. Depending on the direction youâre coming from, twosigns just 100 feet (31 m) apart call it Kerr Lake Reservoir or Buggs Island Lake, respectively.
In a sense, this is similar to an international body of water: each countryâs citizens prefer a different name depending on the language they speak, but the relevant international governmental organizations officially use English, and thereâs a historical tradition of using English on the high seas in general (though some regions have older traditions in other languages).
I donât think of name as a tie-breaker in these cases. Rather, itâs a fallback strategy for when the data consumer doesnât have enough context to personalize the label further for the individual user. Back on land, the name(s) in the native language(s) are the most sensible âimpersonalâ fallback, but there are no such constraints at sea. Otherwise, we might as well be tagging the Sulu Seaâs name in SamaâBajaw and the Natuna Seaâs name in Moken based on the local seaborne population.
I got the impression that the OSM Carto maintainers were interested in displaying something nicer but werenât on board with interpreting the semicolon differently than any other punctuation character, as they do with ref and as e.g. Mapbox and OSM Americana do with name. @imagicodeveloped a proof of concept that relies more heavily on name than most vector styles. If I understand correctly, it would intentionally leave the Atlantic Ocean unlabeled because:
It lacks a name tag.
It has one or more name:* tags.
No administrative boundary relation surrounds the ocean that could have a default_language tag.
This seems consistent with OSM Cartoâs language-neutral design goal, since it lacks a mechanism to personalize the map according to the userâs language. However, it might surprise users who expect the ocean to be acknowledged in some manner.
