[hamiltont]

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

[treyd]

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.

[gloflo]

Way too much latency I am sure.

[Borg3]

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.

[Symbiote]

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

Any caching you do on raster tiles also works here.

[Borg3]

Oh okey, So I confused them with PMTiles..