Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mechanism for disputed map labels #239

Open
wipfli opened this issue Apr 28, 2024 · 2 comments
Open

Mechanism for disputed map labels #239

wipfli opened this issue Apr 28, 2024 · 2 comments

Comments

@wipfli
Copy link
Collaborator

wipfli commented Apr 28, 2024

The protomaps basemap should have a mechanism for disputed map labels.

For example, Turkey is the only country that recognizes TRNC as a country, see wikipedia https://en.m.wikipedia.org/wiki/Northern_Cyprus. So a map localized to Turkey should show TRNC as a country label.

Related are divisions and perspectives in the new overture schema https://docs.overturemaps.org/schema/reference/divisions/division/

@wipfli
Copy link
Collaborator Author

wipfli commented May 19, 2024

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.

@nvkelso
Copy link
Collaborator

nvkelso commented May 20, 2024

@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:

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.

@wipfli wipfli changed the title Mechanism for disputed map labele Mechanism for disputed map labels May 24, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants