Mechanism for disputed map labels about basemaps HOT 2 OPEN

I wrote a bit about how Google Maps handles localization here: https://oliverwipfli.ch/localization-in-google-maps-2024-05-19/

They support 81 languages and 249 regions. I wonder what the best way would be to encode different geopolitical perspectives in vector tiles.

A trivial solution would be to make one build per language/region pair but then you get 81*249=20169 builds which is a bit too much. On the other hand, a user might just get the combinations they need...

Another option would be to create groups of countries that have the same perspective. Because many countries should have the same perspective.

from basemaps.

@wipfli what a great write-up, thanks for sharing!

For the languages and a global basemap I see a few solutions:

1. The global PMTiles build acts as a datastore for "every" language, with middleware trimming off surplus names where requests from clients to server should have a language code, with segmented edge caching by language.
2. The global PMTiles build has a config that limits the number of extra names so just 2 (default ambiguous name and localized name like name_en) to some small number of localized names are exported during tile cut. Then you don't need a middleware layer or edge cache segmenting.
3. Split the localized names into a different sidecar request, more like how Apple Maps does it.

In my experience, file size impact from names is extreme for low-zooms (0-5) and moderate for mid-zooms (6-9), because the number of localized names drops off significantly the farther zoomed in you are. Less of the place=* features will have name translations, and few of the other features like highway=* features have name translations. Limiting the number of named features in low-zoom and mid-zoom tiles should also be employed. Introducing automated translations (especially between latin and non-latin based languages) would ballon that back up regionally.

For the disputed boundaries (and map labels in the places layer):

The approach taken with Tilezen is to mark the point-of-view onto the line and point features so the style can turn them on or off. This means there is a default kind key-value and optional series of kind:{country_code} key-value pairs. These are most visible at low-zooms (where one can see multiple conflict areas in the same map view), but also important at high-zooms for consistency so that point-of-view is carried thru from the Natural Earth zooms to the OpenStreetMap zooms.

For both name localization (based on 2-char language code, though some require 3-char and 6 char) and region (based on 2-char country codes) localization, the style template and should allow for many variants for the combination of the lang and region codes.

See also:

• https://github.com/tilezen/vector-datasource/releases/tag/v1.9.0
• https://github.com/tilezen/vector-datasource/releases/tag/v1.8.0

It's fairly easy to implement the low-zoom solution into Protomaps basemaps from Natural Earth as it's straight mapping of input and output. The high-zooms from OSM is tricker to walk all the relations and there is more business logic during the ETL.

from basemaps.