Per-tile generation with -R vs batch processing: loss of intra-level consistency and challenges with on-demand size control

[vlv-squid]

Hi Tipeecanoe Team,

I have a follow-up question regarding the use of the -R (or --read-parallel) option for on-demand MVT generation, building on my previous inquiry about intra-level consistency.

My scenario is a real-time tile server where tiles are requested and generated individually. There is no ability to "rewind" the process or perform a multi-pass optimization—each tile must be generated in one shot to serve the request. This constraint raises a more fundamental concern about tile size control.

In batch mode, Tippecanoe can run multiple passes if needed. For example, when tiles exceed size limits, it can increase the gamma parameter (the gap-based dropping aggressiveness) by a factor of 1.25 and retry the entire tile generation. This adaptive mechanism ensures that:

Final tile sizes meet the target limit

The simplification/dropping level is consistent across all tiles in that zoom level

When using -R for per-tile on-demand generation:

Each tile is processed in isolation, without knowledge of its neighbors

There is no "global state" or cross-tile statistics to inform decisions

Most critically, the adaptive retry mechanism (which relies on re-processing tiles that exceed limits) is not feasible in a one-shot request context

My specific questions:

Is it correct that per-tile generation with -R inherently lacks the intra-level consistency that batch processing provides, and that this is a fundamental architectural difference rather than a configurable option?

Given the one-shot nature of on-demand tile serving, is it simply not possible to guarantee tile size limits with the same reliability as batch mode, since Tippecanoe's adaptive size control depends on retrying oversized tiles?

As a potential workaround: Could I approximate batch-mode behavior by specifying initial per-zoom-level parameters—such as a fixed gamma value (or --drop-densest-as-needed with per-zoom settings)? For instance:

Use --gamma to set a consistent drop aggressiveness for each zoom level

Use --drop-densest-as-needed to trigger density-based dropping per tile

Perhaps pre-compute global statistics offline and pass them as parameters?

Would this allow me to achieve reasonably consistent tile densities across a level without the adaptive retry mechanism?

Are there any existing best practices or recommended patterns for using -R in a production tile server scenario where tile size must be predictable?

Thank you for your insights. I'm trying to understand whether this is a fundamental limitation of the -R approach, or if there are configuration strategies that can bridge the gap.

[e-n-f]

Yes, it's correct that with -R, there is no way to make the feature-dropping decisions consistent with the rest of the zoom level, because that one tile doesn't know what decisions might have been necessary to make other tiles work. if you can find a --gamma that makes all the tiles work, then they should consistently apply that gamma. But --drop-densest-as-needed will make different decisions in different tiles.

If you want consistent decisions across the whole zoom level, all I can suggest is to generate the entire zoom level and then select just the one tile that you really want out of the output, as inefficient as that is.

[vlv-squid]

Yes, it's correct that with -R, there is no way to make the feature-dropping decisions consistent with the rest of the zoom level, because that one tile doesn't know what decisions might have been necessary to make other tiles work. if you can find a --gamma that makes all the tiles work, then they should consistently apply that gamma. But --drop-densest-as-needed will make different decisions in different tiles.

If you want consistent decisions across the whole zoom level, all I can suggest is to generate the entire zoom level and then select just the one tile that you really want out of the output, as inefficient as that is.

Yes, that makes sense — with -R there's simply no way for a single tile to coordinate thresholds with tiles it never sees.

We've been experimenting with a different approach: what if you could pre-compute the zoom-level thresholds upfront, before any tile is encoded? The idea is to run a quick pre-scan that builds a lightweight spatial index (a quadtree of vertex counts per cell, plus a distribution of feature extents read from serialized metadata — no geometry decoding, no MVT encoding). From that, you can estimate a single zoom_minextent and a reasonable line_detail for every tile in the zoom level, all in memory, before touching a single tile.

Then even a -R request for one tile just queries those precomputed parameters and encodes with them. Same thresholds as every other tile in the level, so density stays consistent.

The tradeoff is that the precomputed zoom_minextent ends up slightly conservative compared to what the iterative approach would settle on — it coalesces a few more borderline-small features than strictly necessary, maybe 5% or so. But in exchange, you get zero retries and consistent single-tile generation without having to throw away the rest of the zoom level.

Does the idea of pulling the threshold estimation out of the encode loop and into a lightweight pre-pass seem workable to you? I'm curious if you've considered something similar or if there's an obvious pitfall we're missing.