[perrygeo]

Raster tiles (and more generally, server-side rendering) definitely have their place today. You mention most of the relevant points - raster tiles are lighter weight, can be read anywhere (they're just PNGs or JPEG), remain a roughly consistent size regardless of the input data. Obviously, they're ideal for rendering raster source data too, it's really the only option there.

The flip side is: raster tiles have no interactivity, no incremental zoom, no ability to style/reorder/project/analyze geometries client side, and labels or crisp lines end up looking, well, rasterized.

The bit about performance and caching low zooms applies equally to both. Getting large datasets to perform well as raster tiles is challenging, roughly equal in "cleverness" to achieving performant vector tiles IMO. In both cases, you need to consider how your data is filtered/downsampled/styled at each zoom and how those intermediate representations are cached. There's certainly a different set of concerns (raster requires server-side styling for example) but I wouldn't say that raster tiles make anything necessarily easier or faster per se. A lot depends on how much cartographic control you need.

Both vector and raster tiles can be pre-rendered or aggressively cached at the HTTP layer, meaning production performance can be decoupled from rendering speed anyways.

It's really a tossup for me. The best of both worlds might be: model your data in vector tiles then serve it up as either, depending on client preference. Something like Tileserver-GL can act as a dumb vector tile server OR it can render them into images server-side.

[birdstheword5]

I'm glad its a tossup for other people! I've been debating it with myself for a long time.

I agree very much with your "cartographic control" point.

I should have been more specific when talking about performance. For a raster tile, if it is performing badly on the server, that is solvable because you can pre-render beforehand. For vector tiles (which I guess most of the time are coming from a MBTiles file which is a cache) if they are performing badly in the user's browser its not really solvable because you can't do this pre-render step. The only solution would be to find a way to simplify the data more to lessen the load on the user's browser. I don't know if you have a similar experience?

[perrygeo]

> simplify the data to lessen the load on the user's browser.

Yes, that's exactly the challenge. How DO you simplify/compress the data so as to convey the same information with less bits? That's effectively re-stating the fundamental problem of cartography.

Pragmatically, at web mercator z12, what features do you want to show? How about z14? An effective mapping service will dynamically provide the necessary data for a given zoom level, provided that you've defined "necessary" for each potential render.