Add OpenMapTiles vector map #4042
Conversation
|
I thought we had agreed that adding support for vector tile layers should be separate from adding any specific layer - certainly at the least I'd like them to be separate commits. The API key should probably be in the configuration file as well, as with the thunderforest layers, rather than hardcoded. What are all the 3D terrain bits about? |
Support for vector tiles is actually just adding If you agree, I can prepare such PR.
I'll look at it.
It is a link to a demo site that shows full capability of vector maps (map rotation, animation, 3D terrain) which is not possible with Leaflet and maplibre-gl-leaflet library. |
|
So are you actually adding two layers here then? The main vector tiles layer and the 3D one? Only the 3D one doesn't seem to be global so I don't think it's going to pass OWG review. I can't look at the other one because it's not actually working currently. |
|
This PR adds only one layer - vector map with carto-like style. Most of the code is actually about updating the link URL in the attribution of this map so that it would point to the same view of the external 3D map demo. |
|
You can see it live at http://osm.openmaptiles.org/ |
|
Ah yes it does work over HTTP but all the other links were HTTPS which doesn't work. I think the 3D stuff should be separated out - most of the code is only actually there to do that I think and I think that's going to be a lot more contentious that the rest of it. |
|
Do I understand correctly that the issue we are talking about is the "3D map ⛰️." link in the footer? We added it there to allow visitors to see the OSM in 3D. We would love to have it directly on osm.org. However, it is not technically possible because the site runs on Leaflet. Therefore, we added it at least as an external link. |
|
Yes that's what I'm talking about - it wouldn't be acceptable as a layer on the site anyway as it doesn't appear to cover the whole world and I think that also makes linking to it questionable which is why I'd rather separate that decision/discussion from the question of adding the vector tile layer to the site. |
|
Can you please report an area that is missing terrain/map? Because I am checking it on my side and the coverage is global - even in the remote places. |
|
Maybe I just don't understand how to operate it then... I clicked the bottom button to switch back to 2D mode, panned to my home area, then tried to switch back to 3D mode by pressing the same button again and nothing happened. Specifically I was looking at https://labs.maptiler.com/showcase/osm-3d-terrain/#style=openstreetmap&lang=en&mode=3d&position=15.46/51.76264/-0.00868 which is 2D and I can't find any way to switch to 3D there? |
|
Oh if I hold on that button and move my mouse I can make it tilt and pan... |
|
You can also drag the map with the right mouse button, or with Ctrl key pressed. Anyway, that area is not very hilly. |
|
Great to see progress on this, thank you for the PR.
This is great! Do you have any guidance for us as to how it handles regional languages, e.g. I want to make sure that the translations work for all of the languages that our user interface works in, hopefully so that there's no mismatch between what you can pick in the UI and what then happens with this layer. I also noticed on the wiki that it says "map labels translations from Wikidata" - can you clarify this? How does this interact with the translated labels available in OSM? If a contributor spots a mistake on the map, can they edit OSM to fix it, or do they have to edit something on Wikidata?
I don't think the layer attribution is the right place for linking to external sites to view other renderings. If we want to link to external sites to view other renderings, which haven't been through the new layer approval process, then let's discuss this separately. And if we want to adapt the site to support alternative (i.e. non-leaflet) tech, then let's discuss that separately too. But I don't think such links should be part of the attribution for another layer, and I definitely don't think that should be part of this PR. |
Supported languages of OMT are documented at https://docs.maptiler.com/schema/planet/#languages Comparison
Currently if the language is not supported then local language is used - same as on Carto map - value from the
I will discuss it with my team. In any case current implementation doesn't fallback to the other languages in the list but I will implement it into this PR. Also falling back to main locale if sub-locale is not available (
We have decided to use names primarily from wikidata because there are more translations than in OSM. If the name is not in wikidata then one from OSM is used.
We will adjust it in this PR. |
What about when the language of the name tag is in a script Maplibre does not support? |
Not sure if I understand you correctly, but for unsupported languages their local If you meant something else then please give me some example. You can try switching to (unsupported) language by setting it as primary in your browser (until I add a fallback to other languages your browser accepts - then try just with a single language configured). |
|
Meanwhile I have removed 3D map link in the attribution. |
+ OMT code cleanup
done |
@tomhughes The map is 3D, but London is rather flat, sending better position: As metioned, you hold Ctrl key and can change the view angle. |
Maplibre doesn't support some scripts (e.g. Burmese, Lao, and other Brahmic scripts), so it can't display the local name. |
That's not exactly accurate. The issue is that MapLibre doesn't support ligatures and combining characters correctly, and instead displays them anywhere from slightly to terribly wrongly. However, OSM-Carto also renders some of these scripts wrongly as the examples below will show (and should probably be documented if they're not already). Whether the "wrong" rendering makes the label unreadable or just slightly off will depend heavily on the script involved, and in my experience, it's the worst in Right-to-Left scripts. This is what MapLibre displays for the United States label, in Lao:
However, it is supposed to look like this: The issue is that the squiggly line above the second-to-last character is supposed to be directly over it, not off to one side. This issue is pervasive across all ligature/combiner scripts. While a Lao reader might still understand the script above, it would definitely look wrong, and this problem in other scripts results in mangled text that's absolutely unreadable to native speakers. This is something which has always been broken in mapbox-gl and is a high priority for maplibre-gl to get right, and it's documented in maplibre/maplibre#193. Examples of rendering the Lao capital of Vientiane, which should appear in local script as: ວຽງຈັນGoogle Maps: OSM Americana (based on MapLibre): OSM Carto: However, looking at these examples, it seems that osm-carto isn't actually any different from what MapLibre is producing. Both MapLibre and osm-carto have the same issue with the diacritic being shifted to the right slightly. Let's take a look at Kathmandu, Nepal, which is supposed to appear as: काठमाडौँGoogle Maps: OSM Americana OSM Carto: Mandalay, Burma, perhaps? Should be: မန္တလေးGoogle Maps: OSM Americana: OSM Carto: Burmese is where we really start to see the problem, with that infinity-sign looking diacritic that's supposed to be under the second character coming in rather mangled. However, OSM-Carto also gets it slightly wrong by jamming the ligature up into the character when there's supposed to be space between them. |
|
It seems that this new vector map does not handle the display of Chinese very well. It displays the Traditional and Simplified varient at the same time, because a DWG member
Even if I forcibly specify locale=zh-TW, the name:zh value mixed with various variants will still be preferred as the display label text |
|
Re "... because a DWG member ... combined the two variants in name:zh" that sounds like a tagging issue that's best discussed elsewhere - perhaps somewhere at https://community.openstreetmap.org/ ? |
It is very on topic. All of the current layers use data external to OSM, therefore that should not be a reason to disqualify the proposed OpenMapTiles layer. |
No, because there is, in my opinion, no valid reason to use Wikidata data for the labels here, they can be easily added to the OSM data if missing. But there might be a valid reason for the use of NaturalEarth data at Carto that I don't know about. Can we now talk about this specific case and not about Carto? |
Thanks for that. I agree that's a showstopper. We specifically ran into this in Americana and had to get it fixed upstream in planetiler. Unfortunately I can't find the planetiler ticket on it. At the time preferring wikidata was regarded as a bug so I'm surprised to hear OMT is doing that. |
Planetiler inverted the logic to prefer OSM name tags over Wikidata labels in openmaptiles/planetiler-openmaptiles#55 for consistency with OpenMapTiles, which in turn tried to be consistent with Mapbox Streets: openmaptiles/openmaptiles#251 (comment). 1 I think the source of confusion may be that, if a feature has a Footnotes
|
The big difference is that other renderers use data that is missing from OSM (terrain shape) or use matching OSM, for performance reasons (Carto). While this would, according to description ("If the name is not in wikidata then one from OSM is used.") would force people to fix mistakes in Wikidata even where OSM data exists and is correct. |
Fortunately, that turned out to be a description of Mapbox Streets rather than of OpenMapTiles. 😉 We don’t have to rely on vague descriptions because we can see the behavior for ourselves. For example, this airport area in OSM has both the By contrast, the OSM area lacks a 
(This screenshot is of a tile inspector behind a login wall that requires a MapTiler API token. However, you can see the same behavior in @ZeLonewolf’s Planetiler-powered tile server’s inspector by hovering over this green dot.) The need to provide feedback to mappers is not necessarily an argument against the Wikidata fallback. The Wikidata fallback can serve to mitigate against edits that OSM doesn’t want. In this case, we could say that this fallback makes it more difficult for mappers to detect gaps in language coverage – if only the Japanese speaker could see the English name, they’d be tempted to add a The problem with such prominent placement on osm.org is that the mapper can’t visually determine whether the label comes from OSM or Wikidata, or that there’s even a discrepancy. OpenMapTiles doesn’t currently expose any metadata explicitly indicating the source of a particular name on a particular feature. However, the style could show both the localized and unlocalized names together whenever the two differ. For example, in the proposed OpenMapTiles layer, a Latinist will see this city labeled as “Francofurtum” based on Wikidata’s Latin label instead of “Frankfort” based on OSM’s 
(MapTiler, Planetiler equivalent) By contrast, OSM Americana shows both the Wikidata fallback and the OSM
I realize this is not an appropriate place to provide design feedback on the proposed OpenMapTiles style, nor to toot Americana’s horn, but I think it’s important that we don’t view localized label sources as a black-and-white, zero-sum issue. |
Yes, this is a topic worth thinking about, especially for languages using non-latin characters (I insist that transliteration across scripts should be treated more leniently, because it is not easy to rely on machines to do accurately ) users, when they first glance at OSM data, when they find a San Jose Airport, and the element is indeed common enough (Negative typical: Old Durham), then the user will will choose to translate its English name into the language used. The question of what is worth translating into different languages and what is not, maybe it can be judged by combining https://wiki.openstreetmap.org/wiki/Names#When_to_avoid_transliteration, at least it is easier than reading such a long list of mailing lists. I've also noticed that there are some renders that use automatic transliteration to complete the data, but it's too early to be an OSM/wikidata fallback Hide it if anyone finds this comment not relevant enough |
This fallback doesn't work well for places that only have a |
This wiki page discusses the issue in more detail. If the feature’s name is translated or transliterated into another language, then it is valid and expected to pair There is a gray area when it comes to features that do have translations but none of them is locally attested or locally relevant. Data consumers face a catch-22 between, on the one hand, the principle that only locally attested names should be tagged in Again, an OpenMapTiles-based layer can address your feedback in at least two ways:
I assume you’re referring to the redundant “Station” suffix everywhere. This is the legacy of Wikidata bootstrapping its labels from Wikipedia (where the suffix is necessary for technical reasons that don’t apply to Wikidata). The issue can be comprehensively fixed in a matter of hours, as I once did for place names in one language in many countries. Nevertheless, it highlights the fact that Wikidata is still a work in progress, just like OSM. If this project wants to hold a featured layer’s external data sources to a higher standard than OSM, then that is indeed this project’s prerogative. |
Note
In such cases it is far less obvious is repeating
In this case the problem is potentially forcing people to fix mistakes in Wikidata even where OSM data exists and is correct. |
Names like “Leeuwarden station” are not intrinsically wrong, just unwanted and a hazard of using a project with different ends. A better solution than resorting to Wikidata could be committing to fix weaknesses in our own language names. |
|
I’m not sure if this Wikidata discussion is really on-topic for this PR. MapTiler could take this issue off the table by disabling the Wikidata fallback on their end, but they’d have to determine whether they want to maintain a separate tileset for osm.org versus their other customers, who generally benefit from mashing up the two sources. I also don’t think this will be the last style to be proposed that incorporates Wikidata in some fashion. In my opinion, there’s no strong need to prevent Wikidata labels from seeping into the website at all cost, as long as they only appear in a non-default style, or they have some kind of special fallback styling, or they’re combined with the OSM
The English Wikipedia used to often omit “station” from railway station article titles, but they adopted this convention after much discussion about considerations that have little bearing on Wikidata label conventions. I’d contend that the Wikidata community would prefer to move “station” from each label to the corresponding description. Regardless, you have a point that Wikidata labels are not necessarily designed to be map labels. Technically they’re more like the
Such as welcoming translations and transliterations that aren’t verifiable on the ground? Even more out of scope for this PR. 😉 |
In my opinion any style that uses Wikidata names even if OSM name tags are provided should not be included (note, if I think that we should not never need to tell anyone that fixing OSM data will not help and they need to fix something on third-party website to fix name display. Or encourage people to remove valid (yes, I am aware about Natural Earth data resulting in some problems on low zoom levels of OSM Carto, but we should not make things significantly worse) (this is my personal preference, not OSMF policy) EDIT: if this style prefer OSM data over Wikidata data whenever possible, it is not a strong blocker in my opinion (though Wikidata licensing quagmire worries me). |
That’s the case we’re talking about here, if I’m not mistaken.
Let’s not turn this PR into a detailed rundown of Wikidata’s faults, as though the style brings in more Wikidata content than it actually does. Besides, Google Maps uses Wikidata for labels, not the other way around. |
|
In the recent release of OpenMapTiles 3.15, the Wikidata translations have been switched off: https://maptiler.com/news/2024/04/openstreetmap-data-prepared-for-advanced-cartography/ Are there any other blockers for accepting this PR? |
|
Can we test the current state somewhere? |
|
@tordans https://osm.openmaptiles.org/ - I've just started it again. |
|
Can the language selector be added as a combobox at the map layers panel? Would be more discoverable and selectable for users without osm account. |
There are already separate issues for adding a language selector for non-logged in users. |
Is it possible to disable automatic transliteration of non-Latin names? |
|
I think it is fine? In the same way as it would be fine to host nondefault layer showing names in Korean/Polish/Japanese? |
|
Any resolution regarding this PR? Can we have this PR merged and closed, I believed, we addressed the concerns and issues of the community. |
|
New layers are approved by the Operations Working Group, which has not happened yet. It was last discussed at their May meeting. I do not see that it has been on an OWG meeting agenda since. |
This pull request adds OpenMapTiles vector tiles among the featured layers. To ensure compatibility with the current stack based on Leaflet, it uses maplibre-gl-leaflet binding.
The main advantage for users is support for labels in multiple languages: users can easily switch by changing language preferences in settings.
An official email with a link to this PR was sent, together with an edit of the “Featured tile layers” wiki page.