OpenStreetMap's New Vector Tiles

Does this reduce the operating costs of hosting OSM-based maps, since presumably they require less CPU spent on rendering and vectors consume less storage/bandwidth?

Yes, vector tiles are much easier to self host.

You have for example https://protomaps.com/ or https://openmaptiles.org/ or https://versatiles.org/ (random order).

Yes and No.

No because the official OSM tile layer is heavily subsidized by Fastly (€720k last I checked) and rendering by AWS (€40k)

Yes because technically it would use fewer resources thus easier on AWS+Fastly and also easier to self-host

In last risk assessment I read closely(1) OSM noted "If we lost [Fastly] sponsorship, we would likely cut off all third-party access to the standard tile layer and run a small number of Varnish servers."

As I understand it, primary drivers for vectors was not cost more improving internationalization, generally enabling client-side rendering decisions, and driving a modern toolchain that would net multiple follow-on benefits

I'm a bit behind, there is more recent info available at (2)

1.https://operations.osmfoundation.org/2024/01/25/owg_budget.o... 2. https://osmfoundation.org/wiki/Finances

openfreemap.org creator here. Yes, with vector tiles you are basically hosting static files, the server has nothing to do, except HTTPS encryption. Even gzipping is already done in the tiles.

For vector tiles osm.org this is not the case. They should be generated on the fly from the database to show mappers the current state of the map with minimal delay. Yes, the resulting results can be cached like static files, but much more work is done on the server.

You can learn more about this in the blog of the developer who develops this tile server: https://www.openstreetmap.org/user/pnorman/diary/403600

p.s. current link to the demo page: https://pnorman.github.io/tilekiln-shortbread-demo

OP asked "Does this reduce the operating costs of hosting OSM-based maps".

openstreetmap.org has a very complex setup for real-time updates, but in general, hosting OSM-based maps is much cheaper with vector tiles.

No, because you've been able to self host (or have somebody host them for you) vector tiles for a long time with very little effort, and yes that will somewhat offload processing to clients, and, more importantly allow many styling decisions to be made by the client (but not all).

Static or infrequently updated vector tiles can be generated from OSM data by a number of tools, but those most popular right now are https://github.com/systemed/tilemaker and https://github.com/onthegomap/planetiler

The actual -new- thing is that the work Paul has done for the OSMF allows on the fly (aka in minutes) updates of the vector tiles. This is important for OSM contributors as a feedback mechanism and the main reason the OSMF operates the current raster tile service.

What is currently a bit out in the open is which usage restrictions will apply to to using the vector tile service as, just as with the raster tile service, the intent is not to compete with or replace third party services and a vector tile service could potentially do that.

I wonder if it would be feasible to distribute tile data in a DHT. There is a single source of truth that could seed the DHT and users would share the load of serving the data. It'd have to be opt-in on individual nav devices for privacy and battery reasons, but anyone running their own OSM proxy would have an incentive participate.

Yet you forget that tiles based maps are plays very nicely even with simplest HTTP caching (even multiple layers of them). Compared to vector stuff that needs caches that are range requests aware, or some magic block storage.

I somehow prefer to stick to tile based maps because caching, easy rendering and I also care about sat images, with cannot be vectorized.

I think we need both of those.

These are tile-based maps — vector tiles, rather than raster tiles.

Any caching you do on raster tiles also works here.

> Static or infrequently updated vector tiles can be generated from OSM data by a number of tools, but those most popular right now are https://github.com/systemed/tilemaker and https://github.com/onthegomap/planetiler

this is the first I've seen of these alternative tools compared to using Tippecanoe(https://github.com/felt/tippecanoe). Are they considered to be higher performance?

Different use case.

Tippecanoe takes geojson and splits it up into tiles, we are talking about doing that with OSM data here. Typically you will want to apply some normalisation of the input data, then you need instantiate the geometry of the OSM objects, then split things up according to the vector tile schema in use and then write the tiles.

Oh okey, So I confused them with PMTiles..

Way too much latency I am sure.