Ask HN: Using Vector tiles vs. raster tiles for web mapping?

2 points by birdstheword5 2 years ago | 3 comments

I’ve seen people mentioning on HN and elsewhere that raster tiles are now an outdated approach and that everything should be vector tiles. I'm talking only about displaying vector datasets here, not raster datasets.

Vector tiles look crisp and make zooming + rotating the map a much nicer experience. On mobile in particular they are brilliant. However, for apps meant to work in desktop/laptop-based browsers, I've noticed a few things:

- Vector tiles are CPU/ GPU intensive on the user's browser. On my work and personal computers, they are sometimes slower to draw than raster tiles.

- Because of point 1, you have to be careful about what data is shown at a particular zoom level. For example, you often don't get the same level of detail when comparing vector and raster OpenStreetMap tiles for the same zoom level.

- I often have performance issues when displaying national-level datasets with vector tiles. Tools like Tippecanoe help here, but there's only so much it can drop/ simplify. If a raster tile service isn't performing well at low zoom, I simply pre-generate the tiles.

- Overall I feel like I don't have to be as “clever” with my data to make the map perform well when using raster tiles.

My feeling is that they will both vector and raster tiles will continue to be used into the future, perhaps even 50/ 50. Am I in the minority here?

perrygeo 2 years ago |

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 2 years ago | |

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 2 years ago | | |

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