Our great sponsors
-
-
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
-
-
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
TileServer GL
Vector and raster maps with GL styles. Server side rendering by MapLibre GL Native. Map tile server for MapLibre GL JS, Android, iOS, Leaflet, OpenLayers, GIS via WMTS, etc.
The thing being discussed is designed for cloud, so I think self managed is a better description?
https://protomaps.com/docs/cdn
Self hosting pmtiles is straightforward also, make a file available to a server that supports range requests:
https://protomaps.com/docs/pmtiles#2.-serve-your-file-locall...
If you have any geospatial data, you can tile it with tippecanoe [0], which gives you an mbtiles file. Protomaps lets you easily convert the mbtiles file into a protomaps file which you can then use.
Protomaps doesn’t limit you to any particular type of tiles, it’s just a format which allows you to read tiles out of a single file with HTTP range requests.
[0] https://github.com/mapbox/tippecanoe
Hmm, I haven't heard of any open source projects re-implementing Google's client library, and I imagine it would be difficult to keep parity with a closed-source project.
Most open source efforts have consolidated around MapLibre GL https://maplibre.org which is a maintained fork of Mapbox GL before their switch to a source-available license.
Hi, the value add in the commercial offering is described here:
https://protomaps.com/docs/faq#openstreetmap
I also maintain open source tooling for anyone to replicate and consume all of OSM, as well as a free download portal:
https://github.com/protomaps/OSMExpress
https://app.protomaps.com/downloads
Most of these examples go up to zoom 10 or so because they cover a wide area. It's not prohibitive to increase that zoom in a small area because the total number of tiles will still be low. Also keep in mind that for vector data it's possible to "overzoom" and allow the client zoom levels to be higher than the physical data levels.
In terms of self hosted maps for outdoors use, I have some open source repos from a few years ago that may help with that. [0] is a style based on the openmaptiles vector tile schema for outdoors purposes. I believe that readme has some overall instructions, plus other repos in the org are for making data. (Nowadays planetiler is probably the best way to make OSM vector tiles though)
[0]: https://github.com/nst-guide/osm-liberty-topo
Tiles, vector or raster, to be consumed for general use are not really in the scope of the OpenStreetMap project. This is surprising to many because it's the first thing you see on OSM.org; the tiles there are for the explicit purpose of feedback to data editors, and make a best-effort to synchronize the instantaneous state of the database in the tiles, unlike Protomaps which delivers a snapshot.
Paul Norman has a project called Tilekiln to adapt vector rendering for this use case on OSM.org: https://github.com/pnorman/tilekiln
You might want to peek at https://github.com/headwaymaps/headway . I have never used it myself, but it at least shows how to integrate the different pieces.
The individual software components often have alternative with a similar scope. So if you don't like a choice headwaymaps made, browse around.
The data sources are mostly "unique", i.e. everybody downloads from the pages (Geofabrik, Who's On First, etc), so not much to gain here.
Editing styles has some alternatives, but the OpenSource editors are far away from the quality of the Mapbox editor. Maputnik or editing the 1000+ SLOC JSON by hand are the way to go, imo.
Personally I use GeoFabrik to download OSM extracts → osmconvert to extract the smaller bounding box I am interested in → tilemaker to render vector tiles to individual .pbf files I can serve like it's 1999. The bounding box extract is not necessary, but it's much faster if you need to tweak things in tilemaker. Both tilemaker and osmconvert are packaged for at least Debian out of the box, so setup is easy enough. Rendering a decently sized metro area takes < 30mins with this from scratch of compute, < 5min with the bounding box extract.
Note that adding icons (sprites) or fonts is extra work that comes on top. And while the tools themselves are great, there's still a lot of gluing/plumbing/fitting things together that you'll need to do. If headwaymaps works for you, it's probably the easiest choice.
Firstly, I just want to say thanks for the reply, but more so thanks for your work, its moving opensource mapping forward.
In my work we are looking at switching from mbtiles hosted with tilserver-gl(https://github.com/maptiler/tileserver-gl) to pmtiles to remove a server process. But we we self host already and we are already using maplibre-gl 2.
I can see why the implementation in the blog post would be better for high traffic deployments (ours isn't). It also points out to me I don't understand how a CDN would handle range request for hosting the pmtiles file directly, it probably doesn't?
As far as the mapbox stuff,in my mind, pmtiles is a direct competitor (successor) to the mbtiles format, which was a revolution in comparison to everything that came before it. A successor I welcome because it makes it even easier for me as a developer to self host and not be dependent on a SaaS to run my maps.
The modern opensource map stack wouldn't exist without mapbox and I'm personally grateful to them for that. Most people who use pmtiles will use mapbox's opensource style spec to style them, and descendants of their open source code to render them. But as a developer now its an obvious choice to not use their services after years of using them.
However I'm not doing high traffic stuff and they never made much money off me anyway.