Opened 5 years ago
Closed 5 years ago
#4550 closed defect (wontfix)
st_asmvtgeom sometimes returns null for valid geometries (postgis 2.5.3)
Reported by: | anneb | Owned by: | pramsey |
---|---|---|---|
Priority: | medium | Milestone: | PostGIS 2.5.4 |
Component: | postgis | Version: | 2.5.x -- EOL |
Keywords: | st_asmvtgeom | Cc: |
Description
in PostGIS 2.5.3, function st_asMVTGeom sometimes returns NULL for valid (but complicated) polygon geometries. The problem depends on the zoom-level. Apparently, the problem occurs with some levels of simplification. On other zoom-levels, the same source geometry is output correctly to as mvt.
example of the problem (in tile z=7, x=66, y=42):
with data as (select st_geomfromewkt('SRID=3857;MULTIPOLYGON(((725189.152109922 6815047.4380655,725313.493934068 6814594.30359714,725255.113930394 6815000.20381502,725326.659505309 6814567.13706215,725376.325951706 6814473.11001708,725323.05983762 6814562.79542736,725337.107185082 6814482.96470687,725455.242593412 6814194.32538979,725373.040398379 6814174.06448492,725453.765899427 6813976.80692352,724958.276702709 6813976.80692352,724958.276702709 6815047.4380655,725189.152109922 6815047.4380655)),((725251.633972098 6815032.51269983,725453.685664168 6815047.4380655,725553.665184441 6814604.72817644,725375.473761016 6814574.45666661,725279.127438692 6814977.08584902,725332.798208279 6814566.38845648,725251.633972098 6815032.51269983)))') as geom)
select st_isvalid(geom),
geom as inputgeom,
st_asmvtgeom(geom,
ST_MakeBox2D(ST_Point(626172.1357121639, 6574807.4249777235), ST_Point(939258.2035682457, 6887893.492833804))) as nullgeom,
st_asmvtgeom(st_simplifypreservetopology(geom, 50),
ST_MakeBox2D(ST_Point(626172.1357121639, 6574807.4249777235), ST_Point(939258.2035682457, 6887893.492833804))) as simplifiedgeom
from data;
Change History (2)
comment:1 by , 5 years ago
comment:2 by , 5 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
I'm closing this as Won't fix. This doesn't happen in 3.0 with wagyu, which is both more stable and faster, so I don't expect anyone to work on this.
This is a known limitation that comes from the interaction between the MVT transformation and the validation process. It might happen that the MVT transformation produces an invalid polygon and the validation step changes its coordinates to decimal to fix it, which requires us to go back the transformation step again. No matter how much I've tuned the process (changed parameters, reorder operations, etc) there are some,situations that we can't fix, so we return NULL.
This has been addressed in the 3.0 release by using a different backend (Wagyu), which not only fixes this problem but it also can give 30x performance in cases like this.