The fastest way, if you don't have resources and don't mind being up to a few months behind, is to use OpenMapTiles vector tiles [1].

The download is an SQLite database with a standard-ish structure (MBTiles), you can either write a small server or use theirs.

I needed vector tiles in other projections — WGS84 equirectangualar, an Arctic one, and an Antarctic one. Generating those took many hours on a cluster.

[1] https://openmaptiles.com/downloads/planet/

It's not comparable to OSM tiles as it's paid for licencing for commercial use.

That's correct — I'd forgotten that, as my project has the open data use license.

However, as an example, the one-time $40 for Colorado is likely to be much cheaper than generating them yourself, and is probably adequate if you don't need to keep up to date.

Vector tiles is interesting and they are actually supported by GeoServer http://docs.geoserver.org/stable/en/user/extensions/vectorti.... However I wasn't able yet to integrate them to my GeoServer installation.

Has anybody else been able to try this?

We are looking at moving to Vector tiles after the deployment of openstreetmap raster tiles is completed. We need to look at the performance closely though because on some devices it was slower with Vector tiles. I think we still want to go that direction we just have to quantify some of the performance.

You can render raster on the fly from a vector based tileserver, and optionally use vector maps for clients where it makes sense (mobile for example).

I've been running a large OSM raster rendering stack for a while, for the whole planet. Moving on to a vector based stack right now, which is what you should do if you are starting today. The reason being the server, with vector tiles pre-rendered, can very quickly render raster tiles on the fly. It's fast enough that for most cases, there is no need to cache them. Once I get the new stack fully burned in, we'll swap our raster rendering stack out for the new vector stuff and do raster on the fly. I might cache the rasters depending on throughput, but from what I can tell it should be basically a non-issue.

The difference between raster tiles and vector tiles is that in raster tiles the rendering (conversion to actual images) is done on your server (either when each tile is loaded for the first time or you may initialize a bunch of zoom levels for your area yourself; this may take hours to days depending on your area size) while for vector tiles you just send the descriptions/shapes and the inages are created on the client side. It is expected that the client performance won't be as good as with raster tiles and slow clients like mobile phones will struggle while trying to render the images.

One interesting idea would be to have both raster and vector tiles; then in your client side code you could detect if the client is a mobile device or a desktop pc (I am not sure if you can detect more things about how speedy the device would be) and serve the corresponding tileset (ie the vector tileset if the device is desktop or the raster one if it is mobile). This way you will definitely decrease the load on your server and most clients won't have performance problems!

In any case, the clients will get faster as the time passes so after some years vector tiles would probably be the norm because they have the huge advantage that it is very easy to style them on-the-fly in any way you like (while, to style raster images you need to re-create them all from scratch).

which tileserver are you using?

would it be possible to learn more about your setup?

Thanks!

I am using more or less the instructions from switch2osm https://switch2osm.org/manually-building-a-tile-server-18-04... however for a Centos 7 server (we use Centos in my organization).

This results in having a tile server that generates & serves raster tiles using:

* carto to generate a proper stylesheet

* mapnik to create the tiles

* apache with the mod_tile module to serve the tiles

* renderd to be used as a bridge between apache/mod_tile and mapnik

* Postgres/PostGIS as a database to host the data

The actual data is an OpenStreetMap pbf file downloaded from http://download.geofabrik.de/ which is inserted to the database through osm2pgsql.

The above are used for the raster tile server only.

In addition to this, I am using geoserver (http://geoserver.org/) which is a Java web app (runs in tomcat) that is used to view/edit and (mainly) serve geospatial data. What I usually do is that when I need to display a new shape (shp) file I use shp2pgsql to insert it to a table in my PostGIS database (using something like this shp2pgsql -s SRID SHAPEFILE.shp SCHEMA.TABLE | psql -h HOST -d DATABASE -U USER) also another good tool is ogr2ogr which can convert between various formats (it also supports kml, for example ogr2ogr -f "PGDump" koko.sql test.kml).

After the shp file is inserted to the database, I can create a datasource for this dataset from GeoServer and publish this dataset to the web (i.e the dataset will have a URL of the form http://1.2.3.4:8080/geoserver/Dataset/wms); it can then be consumed by client applications (in javascipt) using leaflet or openlayers. Notice that GeoServer can easily publish various file formats for example an SHP directly (you don't need to insert it to the PostGIS; this is something I do for better control of my datasources).

PostGIS is the component that supports the vector tiles (http://docs.geoserver.org/latest/en/user/extensions/vectorti...) so I want to integrate it the OpenStreetMap data that is hosted in my PostGIS (which is used for the raster tiles); I haven't found the time yet though.

I think it's a great setup and it works great for the needs of the organization I work for; actually, I like it so much that I want (for a long time) to write a rather comprehensive tutorial on how to set ip up along with some notes on how to do various PostGIS things but I don't know when (and if) I'll find the time for something so large :/

You mention being "a few months behind", what is the reason for this lag?

My apologies, I'm out-of-date with the commercial offerings of OpenMapTiles — I work on an open data project, eligible for OpenMapTiles' free license which has old (currently one year old) tiles.

With a commercial license, the tiles are from 2 July.

I assume the commercial tiles are a few days behind as it's just not worth most people's effort to stay up-to-the-hour — different map services can offer that, this company is making easy self-hosted map tile packages.

The free license is presumably using older data to encourage an upgrade.

Tile generation wasn't THAT bad. We only cover Colorado and Wyoming, and generating the tiles for those at the zoom levels 5-18 takes around 7 hours to pre-render (using "render_list_geo.pl"). The end result is around 25GB of rendered meta-tiles.

Much better than the NAIP aerial imagery, which takes around 3TB for the source data, 280GB for the resulting tiles, and around a full day to generate.

Yes it wasn't bad for a single area (we cover only Greece and it was quick and easy for such a small country). However I couldn't imagine of the resources needed to cover the whole world!

Oh, and we are using the mapbox.js viewer rather than leaflet.

Mapbox.js is a leaflet extension to make it easier to use Leaflet with Mapbox services. So you're using both!

Would it be possible to put Free map tiles in something like DAT or IPFS, to share the load? Kind of like Peertube, but for maps.

For sure, substack did this with peermaps + IPFS, check it out: https://peermaps.github.io/

Source: https://github.com/peermaps/peermaps

Also writeup about the architecture: https://github.com/digidem/osm-p2p-db/blob/master/doc/archit...

If you use vector tiles, and render them client side you could do this. For raster tiles, where you're storing images, there are too many images to do this practically.

And then you need to think of how to do data updates. OSM updates minutely.

Data updates are not required for many applications. You probably don't want to be google maps! For example I haven't updated the OSM data for more than a year and I don't think that there are any problems with the data being stale. It all depends on the application of course.

One major advantage of not updating your data very often is that the tile-images won't need to be re-generated thus you save a lot of (CPU intensive) resources! I think that another commenter mentioned that he generated the tiles in a CPU intensive system and then just off-loaded the images to not-so-fast system for serving.