Here is the link to MapLibre GL Js documentation Add support for right-to-left scripts.
But I think like @NeatNit that MapLibre GL Js should natively supporting RTL language script.
1 Like
This is a known issue in both Mapbox GL JS and MapLibre GL JS.
This plugin only supports Arabic-language ligatures and contextual forms by piggybacking on a part of Unicode thatās only intended for compatibility with legacy character encodings. Translating the proper Unicode characters to this compatibility shim requires a huge lookup table. This has to happen before reversing the character order, as required by other Arabic-script languages and Hebrew, which requires additional data to correctly wrap lines and such. Even when compressed, the data would bloat the overall GL JS package by more than Mapbox was initially willing to accept.
At the time, there was an assumption that most maps only displays labels in a single language that uses a left-to-right writing system. That assumption breaks in an OSM context, where we expect more multilingual capability. Even something like OSM Americana, which tailors the labels to your preferred language, still needs to be able to correctly display native Arabic or Persian names below those labels.
It might be possible to delegate the Arabic transformations to the browser using a technique Iām pursuing for complex text in general. It needs more investigation. But for the time being, installing the RTL plugin on the website would at least get Arabic and Hebrew to a usable state.
4 Likes
There is country where the standard is to use 3 languages (scripts) in ānameā attribute like Morocco : Node: āŖSidi Slimaneā¬ (āŖ1864970021ā¬) | OpenStreetMap
Apologies, not sure where to post this exactly, so Iāve settled for here.
Iām seeing an artefact where, upon zooming, some places names are being rendered twice. E.g.,:
(London)
(Birmingham and Sutton Coldfield)
Itās present across all styles but is not present on the VersaTiles demo site.
2 Likes
Spotted the same thing for Southport at https://vector.openstreetmap.org/demo/shortbread/#12.95/-27.96751/153.39965 but only at zoom 12.95
Itās not the style; itās in the underlying tiles. Iāve logged it as 65. Oddly the kind of place is different in each case, and the population is different between the duplicates.
2 Likes
This is caused by one of the long-standing issues in OSM data: duplication of places as nodes and as relations.
See the hundreds of messages in an OSM Carto PR and issue as an example of some of the discussion, as well as links to discussion in other styles. I donāt know any cartographers who like the current situation.
Iām going to open an issue on shortbread for this.
9 Likes
Briefly stated, āburpingā double- (sometimes triple- or more) name=* tags is desirable, as it āreduces to oneā what really should be only one occurrence (of a name, often) in the first place.
But, methods by which our data are structured sometimes cause duplication. Predictability is tricky.
Stating the problem (multiple name tags sometimes need āburpingā to be only a single tag) is (an initial) part of the solution. Good for us for clearly stating and doing (both). OSM has work to do, but it is entirely possible; we can do this.
Iām really excited about the work happening here!
Can you clarify a bit the role of the Spirit project in these efforts? I found it a bit hard to understand how it fits in with the big picture here.
It seems like right now, the tilekiln definitions that power these Shortbread tiles are part of the spirit repository, but are largely unrelated to the āStreet Spiritā style (which seems to be the center of that repository, but doesnāt use Shortbread vector tiles).
Is the plan for this project either of:
- Migrate the āStreet Spiritā map style to draw features from Shortbread vector tiles, rather than depending on its own āproprietaryā tile format?
- Keep Street Spirit on its own tile format, and host both the Shortbread tiles and the Street Spirit tiles; serve the Street Spirit map (using its own tiles) alongside the already-published Versatiles maps (using the Shortbread tiles)?
Additionally, will the tilekiln/themepark definitions that power the āofficialā hosted OSM Shortbread tiles live within the spirit repository forever, or will they move to their own repository?
1 Like
So do I!
Is there any news about the usage policy? Can we expect anything like the current policy for raster tiles?
To promote widespread use without overloading the osm.org servers, would it be possible to deploy mirror servers?
Iām sure it will be possible to deploy other instances, but I understand that calculating tiles from minute diff requires a lot of resources, and I donāt see any reason why several different servers should do the same calculation.
Thatās why Iām asking about mirror servers, which would store copies of the tiles, with an update mechanism from the main OSMF server.
1 Like
The plans have changed since the original proposal, which adds to the confusion.
Street Spirit is an existing project that aims to be a general purpose map style for OpenStreetMap, and one of its purposes is to show off what can be done with OpenStreetMap data. The project that got approved and funded was to start with minutely Shortbread tiles and then work on Street Spirit. Thanks to some personal issues (medical and otherwise) this has taken a lot longer than I wanted.
When I planned the Shortbread work I realized there was a lot of overlap between it and Street Spirit, so I decided to have them live together so they could share tables, lua transforms, etc.
The Street Spirit code needs some maintenance to make sure it still works with all the Shortbread changes.
Street Spirit has its own schema as Shortbread is not suitable for its goals. The format for all the tiles is MVT.
Yes.
Theyāre not official OSM tiles. Theyāre OSMF-provided but nothing makes them more officially shortbread than any of the other sources of tiles. Thereās no plans to split the repo.
4 Likes
Hi,
I wanted to do exactly that for cartes.app using the tiles on vector.openstreetmap.org but it seems to me that type/ID are lacking. And the same for the tiles on tiles.versatiles.org. Can someone confirm this ? Is there a short- or mid-term plan to add type/ID in OSMF vector tiles?
2 Likes
Hi @PlayGuide, i tested the tiles today for OsmAPP and I can confirm that the MVT tiles are missing id.
@pnorman - please, is there a plan to add the MVT id in future?
For the planetiler it is <osm_id>X, where X=1/2/3 for node/way/relation.
In openmaptiles stack the scheme is X=0/1/4 instead.
For more context, see an issue describing the pattern and effort to unify the schemes.
// edit: added an issue with question https://github.com/shortbread-tiles/shortbread-docs/issues/87
2 Likes
As mentioned above, the schema used by the OSMF demo vector tiles is described here and the steering committee for āwhatās in the schemaā are the people here (most of whom youāll probably recognise).
If you wanted to create a proof-of-concept you could fairly easily - start from this repository, and modify your local process.lua to add the data that you want. This diary entry that I wrote a while back might help with the process.
1 Like
Thanks @SomeoneElse for all the links and @zby-cz for creating the issue, I will continue the discussion on it.
For our own custom OMT tiles, @maelito2000 choose X<id> with X=n/w/r but I donāt remember whyā¦
Well, we already have a production map with clickable POIs using our OMT tiles, so I donāt think we need a POC for Shortbread tiles. It was so obvious to me that the type/id should be included in the OSMF demo tiles (even though itās not officially in the shortbread specifications) that I was really surprised it wasnāt there.
3 Likes
No. This is not part of the shortbread schema. The relationship between vector tile features and OSM objects is many-to-many. One vector tile feature will routinely be composed of multiple OSM objects, while sometimes one OSM object will be split into multiple vector tile features.
Including ID prevents feature merging, and the two combined can increase tile size from 2x to 5x.
4 Likes
We only put ids on POIs and other features that we want to make clickable. E.g., trees are not. Node points are 1-1. Relation points are straightforward to handle.
The impact on weight is not significative, the impact on user experience is enormous.
2 Likes
I checked the config we use for cartes.app tiles :
- types are indeed added by
process.luaonly on POIs and some other interesting elements (like boundaries, places, peaks, rivers, ā¦) - but for IDs, we use tilemaker with option
"include_ids": trueinconfig.jsonso IDs are added on all elements.
I couldnāt reproduce this, I found only 14% weight increase when adding IDs on all elements (when switching "include_ids": from false to true), either with the openmaptiles schema or the shortbread schema. Did I miss something ?
1 Like
Most of the difference is from feature merging, not the IDs themselves.
1 Like