Hacker News Reader

Comment by bdon | Hacker News Reader

Most production raster tile systems use osm2pgsql + Mapnik. These are not easy to install. You may need to generate two or three sets of raster tiles for different pixel densities. The total number of tiles will explode past around zoom level 15. https://switch2osm.org is a good intro.

The newer way to do raster tiles is to actually generate vector tiles first, and then do the rasterization dynamically. Mapnik can do this, renderers like MapboxGL can be run in headless mode to do this as well.

Yes, I wish this was easier too.

View on HN

In addition, modern browsers can display vector tiles directly. Mobile and apps have a somewhat harder time with this. https://www.maptiler.com/ has a good introduction for this wrt Open Street Map.

Vector tiles with OpenLayers doesn't feel as smooth to me compared to MapboxGL or Tangram https://openlayers.org/en/latest/examples/mapbox-style.html but it seems to be improving rapidly.

Last time I checked (almost 2 years ago) OpenLayers did not support webgl backend for vector graphics. That's why it was slower.

Aren't those vector tiles a little heavy, since they're likely json?

Of course I can guess a lot of data can be removed and simplified, but still, PNG seem lighter...

It depends on the application, but I don't think they're necessarily larger in size. I believe the format is quite compressed (Mapbox Vector Tile/MVT, which I believe is a variant of protocol buffers).

Many vector tile encoders have wide flexibility in geometry simplification/removal depending on zoom layer and this helps big time with tile size. I find them to be quite nice in lower bandwidth situations because you can overzoom them and still have them look good: if you zoom in and the tiles for the next zoom level haven't loaded, the vector geometry is still able to look decent, rather than pixellated like a raster tile.

Compressed? Are you saying decompression is done with JS?

You're mixing up the formats slightly: MVT is sqlite with a particular schema; OSM raw data is PBF with a particular schema.

Isn't mbtiles sqlite?

It might be that pbfs are stored inside sqlite? The whole thing is really incredibly confusing to be honest.

What I can tell you is that my vector slippymap XHR is requesting .pbf files, so that would definitely imply protobuffers as the wire format. Ultimately that's using t-rex and mapbox-gl.js, so... not sure if there's something intermediate. But the mapbox docs say sqlite? I'm just very confused now.

https://docs.mapbox.com/vector-tiles/specification/

Yep, versus https://docs.mapbox.com/help/glossary/mbtiles/ -- I had them backwards. My confusion might have been because of the name similarities (mbtiles vs mvt), which took me 3 tries to even just type correctly.

I believe, but haven't bothered to profile, that they're lighter. You can also pre-"render" the vector tiles and store them in eg S3. All styling is done in-browser, which means you can do neat things like swap out the styles client-side for dark mode without needing to reload map tiles.

The primary standard for vector tiles is Mapbox Vector Tiles (it's an open standard), which is really just a sqlite database following a particular schema.

My own personal experience developing against both png and vector tiles over the past few months is that vector tiles are better in just about every way for the kinds of things you use maps for in apps. I expect that some dataviz applications, though, would be better served by raster tiles, since you'd end up generating a raster overlay anyways.

A popular open source server-side rasterization program is tileserver-gl: https://github.com/maptiler/tileserver-gl

> Yes, I wish this was easier too.

I've used spatialite, and even though the doc is poor, I've managed to do things with it, and it works fine.

I'm not sure I can generate tiles with QGIS and spatialite.

It's true that open source GIS software is not easy to find, since GIS is not easy in the first place.

Reply on news.ycombinator.com