Essential Tippecanoe Flags for Production Builds

The six flags that form a reliable production baseline are --drop-densest-as-needed, --extend-zooms-if-still-dropping, --maximum-zoom, --coalesce-densest-as-needed, --no-simplification-of-shared-nodes, and --force — together they enforce the 500 KB tile size limit, prevent silent feature loss in dense areas, collapse redundant geometry, and make automated runs non-interactive.

The diagram below shows where each flag acts in the tile-generation pipeline:

When to Use This Flag Set

Use all six flags together when:

• Your source data is polygon-heavy (land-cover, parcels, zoning, administrative boundaries) and tiles routinely exceed 500 KB without dropping.
• The build runs unattended in a CI/CD pipeline or scheduled cron job where interactive prompts would hang the process.
• Adjacent polygons share edges and you need visually clean seams in MapLibre GL JS without anti-aliasing gaps.

Use a subset when:

• Point or line datasets without polygon adjacency — omit --no-simplification-of-shared-nodes to save CPU.
• Maximum zoom is determined by feature density rather than a fixed rule — see calculating optimal max zoom for urban datasets before hardcoding --maximum-zoom=14.
• You need to preserve every feature regardless of tile size (debugging only) — replace --drop-densest-as-needed with --no-tile-size-limit and do not deploy that output.

Specification Detail

--maximum-zoom=g lets Tippecanoe guess based on feature density; g is useful for exploratory runs but should be replaced with an explicit integer for repeatable production builds.

Production Command

Copy-paste baseline for polygon datasets (parcels, zoning, land-cover):

tippecanoe \
  --layer=parcels \
  --drop-densest-as-needed \
  --extend-zooms-if-still-dropping \
  --maximum-zoom=14 \
  --coalesce-densest-as-needed \
  --no-simplification-of-shared-nodes \
  --force \
  --output=parcels.mbtiles \
  input_parcels.geojson

For Python automation pipelines, wrap in subprocess.run() and capture stderr to detect dropping warnings:

import subprocess, sys

result = subprocess.run(
    [
        "tippecanoe",
        "--layer=parcels",
        "--drop-densest-as-needed",
        "--extend-zooms-if-still-dropping",
        "--maximum-zoom=14",
        "--coalesce-densest-as-needed",
        "--no-simplification-of-shared-nodes",
        "--force",
        "--output=parcels.mbtiles",
        "input_parcels.geojson",
    ],
    capture_output=True,
    text=True,
)

# Fail fast if Tippecanoe exits non-zero
if result.returncode != 0:
    print(result.stderr, file=sys.stderr)
    sys.exit(result.returncode)

# Surface dropping warnings without failing the build
for line in result.stderr.splitlines():
    if "Dropping" in line or "dropping" in line:
        print(f"[WARN] {line}", file=sys.stderr)

Scan stderr for lines matching Dropping features at zoom — more than two consecutive zoom-level extensions beyond --maximum-zoom is a signal to either lower the zoom ceiling or tighten attribute filtering rules to reduce per-feature payload before encoding.

Interaction Effects

--drop-densest-as-needed + --coalesce-densest-as-needed

These two flags operate sequentially. Tippecanoe first attempts coalescing (merging adjacent identical features) to recover space; if the tile is still too large after merging, it then drops the spatially least significant features. Running both gives the encoder more options before resorting to dropping, which is the more destructive operation. Coalescing requires that adjacent features share identical property values — inconsistent casing, trailing whitespace, or null versus "" discrepancies in your source attributes will prevent merges. Pre-validate with ogrinfo or jq:

# Check for whitespace/casing inconsistencies in the 'zone_type' field
jq '[.features[].properties.zone_type] | unique' input_parcels.geojson

--extend-zooms-if-still-dropping + --maximum-zoom

--extend-zooms-if-still-dropping overrides --maximum-zoom temporarily when tiles at the ceiling still exceed 500 KB. Without an explicit --maximum-zoom, extensions can run unchecked and produce enormous .mbtiles files. Always set --maximum-zoom to an explicit integer when using --extend-zooms-if-still-dropping in production.

--no-simplification-of-shared-nodes + geometry simplification

This flag interacts with Tippecanoe’s Douglas-Peucker simplification pass. At shared-node positions (where two polygon rings converge), simplification is skipped entirely; between shared nodes, the standard tolerance-based algorithm applies to both polygons identically. The result is topologically consistent edges at boundaries without requiring a separate topology-repair step. It replaces the older --detect-shared-borders (-ab) flag, which was slower and produced incorrect results on certain T-intersections.

Performance Impact

Memory allocation: --coalesce-densest-as-needed and --no-simplification-of-shared-nodes both buffer intermediate geometry. Allocate at least 4 GB RAM per concurrent Tippecanoe process. For datasets larger than 50 GB GeoJSON, spatially partition the input using ogr2ogr -spat before tiling and merge the resulting .mbtiles files with tile-join.

Output is stored in an MBTiles SQLite container — use SSD-backed storage for the --output path to avoid SQLite write-lock contention that surfaces under network-mounted volumes.

Common Mistakes

1. Using --drop-fraction-as-needed instead of --drop-densest-as-needed

--drop-fraction-as-needed applies a uniform percentage reduction across an entire zoom level regardless of spatial density. In datasets with a mix of sparse rural areas and dense urban cores, this removes features from rural tiles that were already under the size limit while failing to adequately thin the dense urban tiles. --drop-densest-as-needed calculates spatial density per tile and only prunes where the limit is actually exceeded.

Symptom: rural tiles look sparse and important landmarks disappear, while some urban tiles still breach 500 KB.

Fix: replace --drop-fraction-as-needed with --drop-densest-as-needed in the command and rebuild.

2. Omitting --maximum-zoom when using --extend-zooms-if-still-dropping

Without an explicit upper bound, Tippecanoe can generate tiles up to z32 in extreme cases, producing .mbtiles files measured in hundreds of gigabytes.

Symptom: build completes but .mbtiles is unexpectedly large (check with du -sh parcels.mbtiles); sqlite3 parcels.mbtiles "SELECT zoom_level, COUNT(*) FROM tiles GROUP BY zoom_level ORDER BY zoom_level" shows tiles beyond the expected maximum.

Fix:

tippecanoe \
  --maximum-zoom=14 \
  --extend-zooms-if-still-dropping \
  ... other flags ...

3. Coalescing fails silently because of attribute type mismatches

--coalesce-densest-as-needed merges features only when every property key and value matches exactly. If the same polygon boundary is represented with zone_type: "R1" in one feature and zone_type: "r1" in an adjacent feature, they will not merge.

Symptom: tile size does not decrease despite adding --coalesce-densest-as-needed; post-build tile decode shows many small adjacent polygons that should have merged.

Fix: normalise attributes upstream before calling Tippecanoe:

# Lowercase all zone_type values
jq '.features[].properties.zone_type |= ascii_downcase' input_parcels.geojson \
  > input_parcels_normalised.geojson

Then verify with dropping unused attributes — carrying attributes that coalescing does not use is a second source of unnecessary tile weight.

Parent: Tippecanoe CLI Fundamentals

Related

• Visvalingam vs Douglas-Peucker in Vector Tile Generation — the simplification algorithm that --no-simplification-of-shared-nodes selectively bypasses at polygon boundaries.
• Dropping Unused Attributes to Reduce Tile Size — reducing per-feature attribute payload is often more effective than tuning dropping flags alone.
• Calculating Optimal Max Zoom for Urban Datasets — derive the right --maximum-zoom value for dense city-scale data rather than using a fixed default.