MapColonies / shigola / d6dbcb1d5

57%

master: 44%

push

github

fix(provider): space a tile by its scheme's CRS, not the layer's (MAPCO-11614) (#19)

* fix(provider): space a tile by its scheme's CRS, not the layer's (MAPCO-11614)

ST_AsMVTGeom maps a geometry onto the tile grid affinely, across whatever
envelope it is handed, so the envelope decides which CRS's axis the tile is
spaced by. replaceTokens built !BBOX! by converting the tile's extent into the
layer's SRID, and an mvt_postgis layer hands that straight to ST_AsMVTGeom --
so every tile came out spaced by the layer's CRS, whichever scheme the request
had named.

That is right only while the two coincide, which they did for as long as a
3857 layer in WebMercatorQuad was the only combination served. For a 3857
layer in WorldCRS84Quad it produces a mercator-spaced tile inside a
plate-carree frame: at zoom 1, everything between the equator and 85N lands in
the bottom 8.4% of the tile. Tiles touching 90N are spaced across 238,107,693
metres rather than 20,037,508, because floating-point tan at the pole stops
just short of infinity; tiles touching 90S reached PostgreSQL as
ST_MakeEnvelope(...,-Inf,...) and failed outright with `column "inf" does not
exist`.

!BBOX! keeps its job -- the envelope in the layer's SRID, which is the one the
spatial index is built in and the one to select rows with. !TILE_BBOX! and
!TILE_SRID! are the tile in the scheme's own CRS, which is what ST_AsMVTGeom
clips against, with the geometry transformed to match. Writing both is what
lets one SQL string be exact in every scheme -- the thing .github/cite's
comment said was impossible because nothing in the SQL said which grid the
request came from. Something does now.

Two token fixes ride along, both the same mistake in a different place.
!PIXEL_WIDTH!, !PIXEL_HEIGHT! and !SCALE_DENOMINATOR! divided the tile's span
by 256 in the scheme's own units -- degrees for a geographic scheme -- and
then called the result metres; they now come off the scheme's matrix, which
states resolution in ... (continued)

52 of 65 new or added lines in 2 files covered. (80.0%)

7625 of 17170 relevant lines covered (44.41%)

75.83 hits per line