geolith vs Planetiler (Overture + OSM)

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

geolith vs Planetiler (OSM Only)

A second benchmark isolates OSM-only performance, removing Overture data entirely. This tests the core tile pipeline: OSM PBF reading, Natural Earth, shapefiles, and India boundary.

Test Configuration

Both tools processed the same OSM-derived layers: earth, water, boundaries, roads, buildings, and places. Planetiler additionally processed daylight landcover (0.3s wall time, negligible impact). No Overture themes (divisions, bathymetry, pois) were included.

Results

Analysis

Planetiler wins on wall time (1.4x faster) in this OSM-only configuration, primarily due to its streaming pipeline that overlaps reading and encoding phases. geolith's 4-phase architecture processes each stage sequentially.

However, geolith shows significant advantages in resource efficiency:

• 25% less CPU time (587s vs 778s total)
• ~2x less memory (5.4 GB vs 10.9 GB)
• OSM processing itself (pass 1 + pass 2) took only 47s — comparable to Planetiler's ~69s

Output sizes are within 13% (472 MB vs 418 MB). The difference is due to geolith including OSM waterway features (rivers, streams, canals) that Planetiler filters differently.

Parallel shapefile improvement: With parallel land + water polygon reads, geolith improved from 4:48 → 3:31 wall time — a 27% reduction. Land and water polygons now overlap on separate OS threads:

• Land polygons: ~106s
• Water polygons: ~135s (bottleneck)
• Combined wall time: ~135s (vs ~223s sequential)

Phase Breakdown (geolith)

geolith CLI

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

Planetiler CLI

java -Xmx24g -jar protomaps-basemap-HEAD-with-deps.jar \
    --osm-path=western-zone-latest.osm.pbf \
    --output=western-zone-planetiler-osm.pmtiles \
    --bounds=67.67,14.39,80.92,24.72 \
    --nodemap-type=sparsearray --nodemap-storage=mmap \
    --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.