tippecanoe VS go-pmtiles

This is awesome. Such a great use case for nix.

I do a lot of geospatial processing in the cloud and I've been using Tippecanoe a lot to create vector tiles. It pairs well with PM Tiles for storing on the cloud. It seriously increases the web app performance for massive data sets. I queue these up with ECS tasks to process our json/csv/parquet input and create optimize vector tile outputs.

https://github.com/felt/tippecanoe

https://github.com/protomaps/PMTiles

Tippecanoe would be a great addition to your nix packages. I've been thinking more and more about how Nix could fit into this pipeline.

Great work!

I'm the author of a few of the tools mentioned in this post!

A convenient new development is instead of using tippecanoe -> go-pmtiles to create PMTiles archives, you can now output .pmtiles directly:

tippecanoe -o bks2.pmtiles mainroad.geojson ...

This is available in Tippecanoe (https://github.com/felt/tippecanoe) v2.17 and later.

Thanks to Felt (https://felt.com) for supporting this open source work.

tippecanoe

Things I have tried so far: - Just using native vector tile conversion as it involves feature simplification. Doesn't work since smallest feature just disappear, resulting in blank regions instead of "averaged" regions. - Using tippecanoe's built in features to drop/merge in densest zones. Results are disappointing because of unexpected (and too big) differences between each zoom level. - Rasterizing the map, sieving, then vectorizing with smoothing. Doesn't work because pixel information are mixed. I would need a way to rasterize while preserving the land-cover category (with some kind of majority filter ?), but haven't find a way to do this with any QGis built-in or plugin feature.

Take a look at Tippecanoe, which is under active development again[0]. The original developer, Erica Fischer (who is wonderful to work with), has a fork[1] where new work is happening.

[0] https://felt.com/blog/erica-fischer-tippecanoe-at-felt

[1] https://github.com/felt/tippecanoe

https://felt.com/blog/erica-fischer-tippecanoe-at-felt

I just used their pmtiles tool to grab a map of just the area around Half Moon Bay, south of San Francisco.

I grabbed the latest macOS Go binary from https://github.com/protomaps/go-pmtiles/releases

I found a rough bounding box using http://bboxfinder.com/#37.373977,-122.593346,37.570977,-122....

Then I ran this:

    pmtiles extract https://build.protomaps.com/20231023.pmtiles hmb.pmtiles \

Yes, PMTiles is a tradeoff that isn't appropriate for transactional use cases. SQLite is pretty good for that already.

There is a throughput limit on S3 files of approximately 5500 GETs/sec per key. Bare archives on S3 is an appropriate choice for small-scale, zero maintenance deployments. If your application demands any thing close to that level of throughput, you're probably either:

* Serving individual tiles over the internet: you should use the CDN integration http://protomaps.com/docs/cdn ; most tile requests will be cached and only misses will interact with the S3 bottleneck.

* Bulk accessing a spatial subset of tiles: You shouldn't be requesting HTTP GETs for single tiles, but instead entire subsets of tiles with a single Range request made possible by the internal Hilbert curve ordering. This is still WIP here: https://github.com/protomaps/go-pmtiles/issues/31