Comment

Comment by 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.

parent perrygeo 3 years ago

Discussion

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton