[FEATURE] Configurable tile extent per zoom in the output

[mourner]

Is your feature request related to a problem?
Currently, if I understand the code correctly, the tile extent encoded in the output tiles is hardcoded to 4096:

planetiler/planetiler-core/src/main/java/com/onthegomap/planetiler/VectorTile.java

Lines 92 to 93 in edbe7f6

	// TODO make these configurable
	private static final int EXTENT = 4096;

It does scale to higher precision for intermediary representations, but then gets scaled back to 4096.

My use case is pretty common — I want to generate a very small tileset, so I'm limiting maxzoom to a lower one (z11) to remove as much size overhead as possible, but this obviously leads to artifacts on tile boundaries because 4096 on max zoom tiles isn't enough precision when you zoom in on the map close enough.

Describe the solution you'd like
I'd like a way to configure tile extent so that e.g. I can leave it 4096 on most zooms, but bump it to 16384 on the maximum zoom level so that it packs as much precision as possible for overzooming.

Describe alternatives you've considered
An alternative is raising maxzoom, but that exponentially grows the overall size because of tile buffers & clipping overhead. Being able to increase tile precision at maxzoom for overzooming would be much preferable.

Additional context
Example of an overzooming artifact when maxzoom is low:

[mourner]

Looks like the mismatch happens even if I set the tile buffer to 0, so the root cause is probably somewhere earlier, in the intermediary processing... So I'm wondering — should this code determine scale based on maxzoomForRendering() and not maxzoom()? It's not documented, but I assumed maxzoom is the max zoom of actual tiles in the output, and render_maxzoom is the maxzoom that influences tile precision.

planetiler/planetiler-core/src/main/java/com/onthegomap/planetiler/render/FeatureRenderer.java

Lines 262 to 266 in edbe7f6

	// Store lines with extra precision (2^scale) in intermediate feature storage so that
	// rounding does not introduce artificial endpoint intersections and confuse line merge
	// post-processing. Features need to be "unscaled" in FeatureGroup after line merging,
	// and before emitting to the output archive.
	scale = Math.max(config.maxzoom(), 14) - zoom;

[msbarry]

It's not documented, but I assumed maxzoom is the max zoom of actual tiles in the output, and render_maxzoom is the maxzoom that influences tile precision.

Yeah it could definitely be documented better but by default when profiles set a min size or simplify tolerance it applies to all zoom levels below max zoom, but at max zoom they use a smaller min size and simplify tolerance to preserve as much detail for overzooming. Initially it was just using maxzoom for that, but that made so it would cram a lot of stuff into tiles at that max zoom level. So render_maxzoom controls what the normal maxzoom for the tileset should normally be, and maxzoom lets you just omit tiles past that zoom level.

Setting extent to be higher at render_maxzoom (and a tighter default min size/tolerance at max zoom) would definitely help the tiles look better when overzoomed, but I think this mismatch at tile edges will still happen if you have a line segment with long distance between points that spans a tile boundary since that line gets clipped and snapped to an endpoint along the tile's buffer:

Maybe a better approach would be for clipping to take the last/next point further outside the tile boundary instead of clipping to the intersection of that line with the tile buffer? It would probably be a little faster too.