geolith vs Planetiler

geolith was benchmarked head-to-head against Planetiler (Java) on identical input data and region bounds.

Test Configuration

Both tools processed the same layers: earth, water, boundaries, landuse, roads, transit, buildings, places, pois, and divisions. Planetiler additionally processed daylight landcover (0.3s wall time, negligible impact).

Results

Summary

• 17% faster wall time (5:15 vs 6:20)
• 4.7x less CPU time (709s vs 3,343s)
• 41% smaller output (2.0 GB vs 3.4 GB)
• ~12x less memory (~2 GB vs 25 GB heap)

geolith achieves competitive performance with significantly lower resource usage. The smaller output is primarily due to tile content deduplication and efficient MVT encoding.

Phase Breakdown (geolith)

geolith CLI

geolith \
    --data ./overture-data/ \
    --osm-pbf western-zone-latest.osm.pbf \
    --natural-earth natural_earth_vector.sqlite \
    --land-polygons ./land-polygons-split-3857/ \
    --water-polygons ./water-polygons-split-3857/ \
    --india-boundary india-boundary.geojson \
    --output western-zone.pmtiles \
    --bbox 67.67,14.39,80.92,24.72 \
    --max-zoom 15 \
    --node-cache

Planetiler CLI

java -Xmx24g -jar protomaps-basemap-HEAD-with-deps.jar \
    --osm-path=western-zone-latest.osm.pbf \
    --output=western-zone-planetiler.pmtiles \
    --bounds=67.67,14.39,80.92,24.72 \
    --buildings_source=overture \
    --overture_buildings_path=./overture-buildings/ \
    --divisions_source=overture \
    --overture_divisions_path=./overture-divisions/ \
    --india_boundary_path=india-boundary.geojson \
    --nodemap-type=sparsearray --nodemap-storage=mmap \
    --download --force

Expected Performance

Bottlenecks

Performance is typically bound by one of three factors:

1. Disk I/O — Reading GeoParquet/PBF input and writing temporary sort files. Use NVMe SSDs for the data directory and --tmpdir.
2. CPU — Feature processing (projection, clipping, simplification) is parallelized via rayon. More cores = faster processing.
3. Memory — External sort keeps memory usage bounded. The main memory consumers are the Parquet reader buffers and the OSM node store.

Tuning Recommendations

Running Micro-Benchmarks

# Run the full benchmark suite
cargo bench

# Run a specific benchmark file
cargo bench --bench tile_encode

# Filter by benchmark name
cargo bench -- "encode_tile"

Micro-benchmarks use Criterion.rs for statistical analysis. Results include confidence intervals and regression detection. Reports are saved to target/criterion/ with HTML visualizations.