[vincentsarago]

Stacked on #307. Independent of #314.

Why

ST_AsMVTGeom encodes geometries up to TIPG_TILE_BUFFER (default 256) pixels outside of the tile, so lines, polygon outlines and labels continue across tile edges. But the tile filter only selected features intersecting the tile itself, so features in the buffer were never part of the query, and nothing was ever drawn there. This affected both backends: lines and polygon outlines were cut at tile edges, and labels or symbols near the edges were missing.

What

• Collection.cql_where gets tile_buffer (pixels) and tile_resolution options. The tile envelope is expanded by tile_buffer / tile_resolution of the tile size, in the TMS CRS, before being reprojected to the column CRS.
• The buffer doesn't extend past the TMS bounds, so a z0 tile stays within ±180°/±85.05°. Tiles outside of the TMS bounds (accepted with is_valid(strict=False)) are never shrunk.
• PgCollection.get_tile and DuckCollection.get_tile pass mvt_settings.tile_buffer / tile_resolution. cql_where without the new options behaves as before (no buffer).
• DuckDB: the GeoParquet bbox covering filter is built from the same envelope, so it widens too.

Martin does the same: its tile filter expands the envelope by the buffer.

Tests

• New tests/duck/test_tile_buffer.py (z4 tile, 256px buffer ≈ 1.4°):
  • a point 0.5° outside the tile is now encoded, and one 2.5° outside isn't
  • the envelope is expanded by exactly the margin
  • a z0 envelope stays within the TMS bounds
• test_projjson_crs: the z8 tile now has 3 features instead of 1. Two of the points are just outside the tile but inside its buffer (checked against the tile bounds).
• Full suite passes locally (143 tests, PostgreSQL included). The PostgreSQL change is the shared cql_where code plus passing the two settings; there is no PostgreSQL-specific buffer test.

🤖 Generated with Claude Code