St_AsMVT Errors on Some Polygons with Inner Rings

[reyemtm]

This is possibly related to issue #3712. I have an impervious surface layer which is a multipolygon layer with many inner rings. Above zoom level 18, so 0-17, the "holes" get filled in using Mapbox GL JS, while the GeoJSON export of this layer when used directly draws with minimal artifacts. It would seem like this is due to simplification, not sure. I did try to use the ST_AsMVT(ST_MakeValid(geom)) but that did nothing.

For an example picture see the issue I made on the pg_tileserv repo - ​https://github.com/CrunchyData/pg_tileserv/issues/48. This has a link to the GeoJSON data as well.

If there is anything I should try or other tricks let me know.

Thanks

[Algunenano]

Can you share the exact Postgis version the server is running (as in postgis_full_version) and the exact call and input for ST_AsMVT/ST_AsMVTGeom? Otherwise this requires mindless tests to try to reproduce your setup.

[reyemtm]

postgis_full_version()

POSTGIS="3.0.0 r17983" [EXTENSION] PGSQL="110" GEOS="3.8.0-CAPI-1.13.1 " SFCGAL="1.3.2" PROJ="Rel. 5.2.0, September 15th, 2018" GDAL="GDAL 2.4.3, released 2019/10/28" LIBXML="2.9.9" LIBJSON="0.12" LIBPROTOBUF="1.2.1" WAGYU="0.4.3 (Internal)" TOPOLOGY RASTER

sql in next reply

[reyemtm]

I have the same issue from two different servers. I did not write either of these queries. Not sure which one is easier to understand out of context - the servers are pg_tileserv and dirt-simple-postgis-http-api, so they can be looked up GitHub for context. This one is from the latter. They seem like pretty straight forward mvt queries.

I added the ST_MakeValid(), but again it did nothing.

`WITH mvtgeom as (

SELECT

ST_AsMVTGeom (

ST_MakeValid(ST_Transform(${query.geom_column}, 3857)), ST_TileEnvelope(${params.z}, ${params.x}, ${params.y})

) as geom ${query.columns ? , ${query.columns} : ',*'} ${query.id_column ? , ${query.id_column} : }

FROM

${params.table}, (SELECT ST_SRID(${query.geom_column}) AS srid FROM ${params.table}

LIMIT 1) a

WHERE

ST_Intersects(

geom, ST_Transform(

ST_TileEnvelope(${params.z}, ${params.x}, ${params.y}), srid

)

) ${query.filter ? AND ${query.filter} : }

) SELECT ST_AsMVT(mvtgeom.*, '${params.table}', 4096, 'geom' ${ query.id_column ? , '${query.id_column}' :

}) AS mvt from mvtgeom; `

[reyemtm]

In QGIS using Check Validity and the GEOS option, this layer, at least in its original form (not transformed) passes validity checks. Using the QGIS option, some polygons fail, and those all show these filled-hole artifacts, but some that pass also show these filled hole artifacts.

[Algunenano]

Ok, sorry but I didn't explain myself. I don't need the SQL template, I need the a reproducible example, that is the data, the steps to load it, and a full query that reproduces the behaviour.

[reyemtm]

Ok will do. For a server you can use either the pg_tileserv or the dirt server. The latter is in Node so its a bit easier to tweak the sql query if need be.

These are not the exact steps I am using but gives the same result. Just tested it.

Data - already in wgs84 - ​https://311.coz.org/data/geojson/utl_stormwater_impervious_view.geojson

Load into QGIS LTR
Run Fix Geometries
Load into Postgres 11/PostGIS 3.0
Run server, either one
Load into Mapbox GL JS latest map as fill
Load the raw GeoJSON as well for reference - no need for account, just use blank style.

If you need anything further let me know. I actually ran into similar issues using geojson-vt to create static vector tiles in Node on this layer. I ended up letting gl js cut the tiles by loading the raw geojson. Not sure what magic they are doing but it works, for the most part. There are still artifacts, but very few. See ​https://gis.coz.org/maps/impervious-areas/?coz-impervious=true&layers=coz-impervious&lng=-82.01075644370012&lat=39.92599948362346#18.08/39.926302/-82.010936 for reference artifacts.

[Algunenano]

Load into QGIS LTR Run Fix Geometries Load into Postgres 11/PostGIS 3.0

Can you share the dump of the table that you are loading into Postgis. That would ensure I get the exact same data.

[Algunenano]

I've loaded the dataset into CartoVL (based on MapboxGL) and there are some issues (lines across the polygons) in certain places, but when loaded individually in QGIS the tiles are ok. They are also ok when analyzed individually under node-mapnik.

I'm inclined to think this could be a problem during the stitching of the polygons (there is nothing in the spec/format to make that easier) but I'm not 100% certain about it and right now I don't have an easy way to test with other renderers.

[Algunenano]

I've done some more tests changing how big is the buffer around the tiles and it does indeed look like a stiching issue.

Using a extent of 4096:

• Buffer of 0: Lots of artifacts when stitching across tile boundaries.
• Buffer of 4096/256 = 16 (the smallest one in CARTO): No artifacts at all
• Buffer of 256 (Postgis Defaults): Ocasional artifacts (less than with buffer 0)

Note that CartoVL by default uses extent / 256 as the buffer for historical reasons (from the time a tile was 256x256 pixels) but it could probably be smaller.

Can you give a try to one of those services with a smaller extent and see if that makes your issues go away? They are changed in ST_AsMVTGeom and I from experience I would recommend it to be as small as possible (the extent / 256 seems to be working well for us).

[reyemtm]

I have tried some various buffers with not much different results in both GL JS and OpenLayers3. Seems that the issue goes away after zoom 18 on some tiles, 19 on others.

[Algunenano]

The individual tiles look fine, so I have a feeling this is an issue in the stiching in the renderers. Nothing we could do there.