Use floor on screen coordinates to prevent coordinate jump around 0 axes.

[RoelvandenBerg]

Coordinates around the zero axes are squashed because they are cast to int (see below Python code for an explanation).

import math
int(-1.0001), math.floor(-1.0001), int(-0.0001), math.floor(-0.0001), int(0.0001), math.floor(0.0001),  int(1.0001), math.floor(1.0001)

Which results in:

(-1, -2, 0, -1, 0, 0, 1, 1)

This can cause a jump in vectors in tiles (see below). I propose flooring the coordinates to prevent this behaviour. This helps prevent quality issues in our vectortiles.

Example gpkg:
broken_geom_6_36_41.zip

The above geopackage is to illustrate the jump (of a screen pixel). This jump can however increase greatly and therefore create clearly visible artifacts in more complex geometries.

[pka]

Thanks for analyzing this bug! I'm going to mark T-Rex as deprecated soon, since it is replaced by https://github.com/bbox-services/bbox/tree/main/bbox-tile-server. I would like to test this geometry with bbox, expecting that ST_AsMVT does handle it properly. The attached GPKG geometry is in EPSG:28992. Do you reproject it to WebMercator or do you use a custom grid?

[pka]

We probably have to apply the same fix to geozero, which is used in bbox (and probably martin) for writing MVTs: https://github.com/georust/geozero/blob/main/geozero/src/mvt/mvt_writer.rs#L77-L78 !

[RoelvandenBerg]

We indeed use a custom grid (sorry I forgot to add it):

[grid.user]
width = 256
height = 256
extent = { minx = -285401.920, miny = 22598.080, maxx = 595401.920, maxy = 903401.920 }
srid = 28992
units = "m"
resolutions = [3440.640, 1720.320, 860.160, 430.080, 215.040, 107.520, 53.760, 26.880, 13.440, 6.720, 3.360, 1.680, 0.840, 0.420, 0.210, 0.105]
origin = "TopLeft"

And the BBOX in EPSG:28992 is 210050.24,325374.4,223812.8,339136.96 / the polygon in wkt is: POLYGON((210050.24 325374.4,210050.24 339136.96,223812.8 339136.96,223812.8 325374.4,210050.24 325374.4))

[pka]

I was partially able to reproduce the case with bbox in t-rex compatiblity mode (postgis2 = true). The coordinate differences around 0 did occur with/without floor, but I couldn't see a visual difference. In normal mode translation to projected coordinates is done by ST_AsMVT. Looking at the generated coordinates, ST_AsMVT does also round with floor!