In theory Maputnik is supposed to be an easy to use graphical editor for styles. In practice it’s design model pre-dates expressions everywhere in Maplibre/Mapbox GL so it is a real pain to use with the more modern features.
When I did my presentation on doing some styling I ended up hand-waving the editing the style part and just adding directly to the JSON. Before I cut it the instructions on how to add the appropriate layers with Maputnik were over half the talk.
If you want to load the OSMF shortbread tiles the TileJSON URL is https://vector.openstreetmap.org/shortbread_v1/tilejson.json.
You can also run through the switch2osm guide and point Maputnik at the resulting style JSON
We control the CSP. If we add a new featured layer it’ll get added to the CSP.
It would be nice to get people more involved in discussing issues. You’ve been involved in the barriers discussion but it’s hard to get others to care.
I didn’t plan on doing it yet. As far as I understand, the current plugin for iD suits many people. I don’t use it because I don’t often shift satellite images (I prefer JOSM:), and it sometimes breaks iD loading.
However, sometimes I use Strava to check out the paths that cartographers draw. This is the closest use case to me.
Another annoying, incomprehensible bug that has recently started to appear for me.
When navigating backwards/forwards by browser history, the map breaks — it’s just a gray background. This seems to be a website bug, as I’ve encountered it several times even with the script disabled, but perhaps the script somehow exacerbates the issue.
If it were a completely new featured layer, they’d have to submit it in accordance with the new tile layers policy. If it’s a style that can use the OSMF shortbread tiles it becomes simpler as we know the tiles meet the technical criteria.
We’d then look at if it meets the soft criteria. If we were hosting the style and assets in addition to the tiles we’d also need a sane build and release process.
but I’d expect someone would need to create something in chef to do the equivalent work**. For completeness the output that I get is this;
Created spec file: /var/www/html/vector/spec_osmf_shortbread.json
Created metadata file: /var/www/html/vector/metadata_osmf_shortbread.json
Installed fonts into: /var/www/html/vector
Created style json: /var/www/html/vector/style_osmf_shortbread.json
Created web page: /var/www/html/vector/index_osmf_shortbread.html
Access via: https://map.atownsend.org.uk/vector/index_osmf_shortbread.html
svwd03sprite@2x.png and svwd03sprite@2x.json copied to /var/www/html/vector
svwd03sprite.png and svwd03sprite.json copied to /var/www/html/vector
My index_osmf_shortbread.html wouldn’t be needed as osm.org has its own resources that deal with MapLibre etc. The .json for the style refers to locations for e.g. the sprite files and glyphs which can be deployed wherever convenient. Glyphs are optional with recent MapLibre versions; see e.g. here and links for loading fonts by other means. The only thing that the deployment line above uses the “tilemaker” repository for is the fonts. I currently don’t have @3x or @4x sprite files in the repository, but “pull requests welcome” if that was a problem, or my scripted ImageMagick sprite creation process could be moved to something else.
** I’m not familiar with how this is done on the website so can’t really comment.
In fact, you can build the style yourself and simply provide a bundle archive with the style files. Technically, everything is simple here: no external infrastructure, the main thing is the correct relative paths to resources. Now the ball is in OSMF’s court.
Since osm-carto has decided to filter the shop=* tag values by popularity… The script now warns if the type=* value is not used for a relation or is used less than 50 times according to taginfo
Requests for new layers to go to the Operations Working Group who will use these guidelines to evaluate the proposed layer and, if accepted, implement the change.
I created my Shortbread-based map style to try and make clear the difference between the data in the vector tiles and the (very basic) Versatiles Colorful representation of that. People were saying “Shortbread is data poor” based on the map style, which is unfair:
(both of those styles use exactly the same vector data tiles)
I’d be delighted if someone wanted to add my shortbread style to osm.org and was prepared to go through the work to make it a featured layer within the current infrastructure (both bureaucratic and technical - as I said above the current deployment mechanism would need adapting for OSMF’s infrastructure). That would need someone willing to commit time to the exercise, and that someone isn’t me…
What’d be actually much nicer rather than having X (currently 8) entries in the layer switcher would be the ability to define my own layer. Historically that might have been just a path to some raster tiles (and of course the Better-osm-org user script allows this - but having to run it as a user script will put most people off). Looking forward it’d be nice to be able to define a path to different vector map styles that uses a supported schema (e.g. Shortbread v1.0).
Actually creating a map style (especially as a derivative of an existing one) is actually really easy - the first pass of that railway one I did yesterday took about an hour, including some basic documentation. More people don’t do it because (a) they think that it’s hard - they look at Maputnik and ask themselves “what the (expletive) does that all mean” and (b) they want to neither create nor host their own vector tiles, and suspect that the OSMF Shortbread ones won’t be suitable for the reasons noted above.
A couple of caveats - Shortbread is designed a a simple schema containing the most important and frequently used OSM data. It isn’t the schema that I would have created, but the v1.0 version is as good a place to start as any. OSMF’s vector tiles do have a usage policy, and that’s going to become more important as things become more popular.