Geopackage-provided tiles are malformed in v20

[Monstrofil]

I have this minimal config:

tile_buffer = 64

[webserver]
port = ":9090"

[[providers]]
name = "sample_gpkg"
type = "gpkg"
filepath = "bp.gpgk"
srid = 4326

[[providers.layers]]
name = "landuse1"
tablename = "bp"
geometry_fieldname = "geometry"
id_fieldname = "fid"

[[maps]]
name = "landuse_new"

[[maps.layers]]
provider_layer = "sample_gpkg.landuse1"
dont_simplify = true
min_zoom = 3
max_zoom = 15

When running with gospatial/tegola:v0.20.0, I get this:

When i switch to gospatial/tegola:v0.19.0, geometry becomes normal:

I believe there is a bug in v20.

[iwpnd]

Can you share the file please?

[Monstrofil]

Sure.
demo.zip

ps. change the table name to functional_zones_table.

[iwpnd]

I can confirm the issue in v0.20.0 and everything working in v0.19.0. Also took a look at the data and couldn't find anything wrong with it either. I was able to verify that the gpkg provider correctly gets the feature from the gpkg and creates a valid polygon. I'm not sure why, but the issues appears to occur during encoding to mvt.

[ARolek]

I have a feeling this has to do with this PR #952.

@gdey can you give us some guidance on what our best path forward here is? It seems to me that upgrading the geom package has caused a regression in rendering. I think the geom package version was bumped to bring in a fix for the slippy package to get tests to pass on Apple Silicon. This was discussed in #951

[gdey]

I need to look into this, and the other one listed here. I'll take a look tomorrow. See what I can find, but it does look like an issue with geom.

[iwpnd]

Just for a sanity check. The mvt_postgis provider is not affected.

[ARolek]

Just for a sanity check. The mvt_postgis provider is not affected.

Correct. The mvt_postgis provider does all geoprocessing in PostGIS. The Geopackage provider does the geoprocessing in tegola, which is why this is showing up only in the geopackage provider.

[iwpnd]

which is why this is showing up only in the geopackage provider.

just tested the legacy postgis provider. Same issue there for geometry_type=polygon but fine for geometry_type=linestring. 👀

[ARolek]

@iwpnd indeed, the same issue would show up for the legacy postgis provider. The geom package's line handling is fine, but the polygon handling is where the issues stem from.

[gdey]

Yeah, this looks like an old regression I had with makevalid. Where it would drop certain points due to floating point precision errors.

[ARolek]

Note, @gdey has been working on a fix in the geom package and hopes to have a PR ready soon that should address this issue.

[gdey]

I'm still looking at this. Needed to take a small break, but am look at it.

[tommyannguyen]

confirm v20 data has broken . I revert v19 work ok