Skip to content

elivagarShortbread vector tiles at planet scale

Reads OSM PBF, writes PMTiles v3. The full planet in 9m32s on a 16-core desktop, peaking at 12.7 GB of RAM.

Elivagar logoElivagar logo

What it does

elivagar turns an OpenStreetMap PBF into a PMTiles v3 archive carrying the Shortbread schema: 26 layers, zoom 0 to 14, one file you can serve directly.

elivagar run denmark-latest.osm.pbf -o denmark.pmtiles \
  --ocean z0-z7:data/simplified-water-polygons-split-3857/simplified_water_polygons.shp \
  --ocean z8-z14:data/water-polygons-split-3857/water_polygons.shp \
  --ocean data/ocean-tiles.pmtiles

Why the memory number matters

Tile generation at planet scale is usually a question of how much RAM you can rent. elivagar is built the other way round: every stock in the pipeline is bounded by construction, so the peak does not track the input size. The planet build above used 12.7 GB on a host that had 30.5 GiB available.

That constraint is why the pipeline looks the way it does - an external merge sort partitioned by Hilbert tile-id range, a byte-budgeted claim window in assemble, a relation-block buffer that spills at a cap, and a memory-mapped way index rather than an in-RAM one.

Honest comparisons

planetiler's published planet table lists 2h38m on a 16 cpu / 32 GB machine, and 19 minutes on 192 cores / 720 GB. Three things belong next to any such number, and this project would rather state them than be corrected later:

  • Our figure is for enriched input. The pbfhogg preprocessing pass is not in it; end to end the honest number is roughly 20 minutes.
  • The profiles differ. Shortbread here, OpenMapTiles there. Not the same work.
  • The planet snapshots differ. Ours is seq 4912, 2026-02-23.

Treat 571.7s as a measurement of this pipeline, not as a record claim.

Released under MIT or Apache-2.0, at your option. | Copyright folk@folk.wtf