Opened 6 years ago
Closed 6 years ago
#4181 closed defect (fixed)
St_AsMVTGeom: Avoid type change due to validation
Reported by: | Algunenano | Owned by: | Algunenano |
---|---|---|---|
Priority: | medium | Milestone: | PostGIS 2.4.6 |
Component: | postgis | Version: | 2.4.x |
Keywords: | Cc: |
Description
To comply with MVT spec (2), St_AsMVTGeom forces polygon validation using lwgeom_make_valid
and setting the winding order properly.
The problem with this setup is that some polygons, under certain bboxes, can be transformed to lines during validation:
SELECT ST_AsEWKT(ST_AsMVTGeom( 'SRID=3857;MULTIPOLYGON(((-8238034.11943289 4970934.90416362,-8238026.20761928 4970930.11708391,-8238049.70095916 4970891.1459086,-8238058.64331211 4970896.5565545,-8238035.14999485 4970935.52777282,-8238034.11943289 4970934.90416362)))'::geometry, 'SRID=3857;POLYGON((-8242969.13027341 4975133.29702555,-8242969.13027341 4970241.3272153,-8238077.16046316 4970241.3272153,-8238077.16046316 4975133.29702555,-8242969.13027341 4975133.29702555))'::geometry, 4096, 16, true )) as the_geom_webmercator; the_geom_webmercator ------------------------------------------------------------------------ SRID=3857;MULTILINESTRING((4112 3546,4112 3547),(4112 3548,4112 3547))
In this case, after transforming the polygon to MVT coordinates in only has 3 points left, so make_valid transforms it into 2 lines. I've tried to encode a similar polygon using Mapnik and it's simply dropped out of the MVT.
Although this type change isn't against the spec, it causes issues in some MVT rendereres as they don't expect mixed types or a geometry switching types depending on the zoom level.
Change History (10)
comment:1 by , 6 years ago
Milestone: | PostGIS 2.4.5 → PostGIS 2.4.6 |
---|
comment:2 by , 6 years ago
comment:6 by , 6 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
Still happening in some cases:
SELECT 'PG46', St_AsEWKT(ST_AsMVTGeom( 'SRID=3857;MULTIPOLYGON(((-8230324.85567616 4984496.35685962,-8230307.1114228 4984654.46474466,-8230285.21085987 4984959.60349704,-8230324.85567616 4984496.35685962)),((-8230327.54013683 4984444.33052449,-8230327.23971431 4984450.39401942,-8230327.26833036 4984449.87731981,-8230327.54013683 4984444.33052449)))'::geometry, 'SRID=3857;POLYGON((-8238077.16046316 4989809.20645631,-8238077.16046316 4980025.2668358,-8228293.22084265 4980025.2668358,-8228293.22084265 4989809.20645631,-8238077.16046316 4989809.20645631))'::geometry, 4096, 16, true)); ?column? | st_asewkt ----------+------------------------------------------------------------------------ PG46 | SRID=3857;MULTILINESTRING((3244 2244,3244 2246),(3244 2243,3244 2244))
comment:7 by , 6 years ago
The steps taken for that geometry:
- INPUT: A valid multipolygon made of 2 polygons:
SRID=3857;MULTIPOLYGON(((-8230324.85568 4984496.35686,-8230307.11142 4984654.46474,-8230285.21086 4984959.6035,-8230324.85568 4984496.35686)),((-8230327.54014 4984444.33052,-8230327.23971 4984450.39402,-8230327.26833 4984449.87732,-8230327.54014 4984444.33052)))
- After the simplification step it stays the same (it was already simplified).
- Clipping wasn't necessary, so it also stays the same.
- After snapping it to the MVT grid we have 2 polygons, with the second one being invalid:
SRID=3857;MULTIPOLYGON(((3245 2224,3253 2158,3262 2030,3245 2224)),((3244 2246,3244 2243,3244 2244,3244 2246)))
- After validation we have a geometry collection formed by 1 polygon and a multistring made of 2 lines:
+ SRID=3857;GEOMETRYCOLLECTION(POLYGON((3245 2224,3262 2030,3253 2158,3245 2224)),MULTILINESTRING((3244 2244,3244 2246),(3244 2243,3244 2244)))
- Since MVT is incompatible with collections types, mvt_geom drops the geometry with the smallest geometry type:
SRID=3857;MULTILINESTRING((3244 2244,3244 2246),(3244 2243,3244 2244))
I intend to fix it by saving the initial type and preferring something equivalent when extracting the basic type at the last step.
For reference, what Mapnik does for geometry collections is to duplicate the features (one feature per each geometry in the collection), but this also has some drawbacks like duplicating what should be unique values.
comment:10 by , 6 years ago
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
2.4 wasn't affected by this second issue as it is handling the extraction differently (but it was affected by the original one that it was solved with the first patch).
In 16831: