Opened 6 years ago
Closed 6 years ago
#4134 closed defect (fixed)
MVT test failure in trunk
Reported by: | dbaston | Owned by: | Algunenano |
---|---|---|---|
Priority: | blocker | Milestone: | PostGIS 2.5.0 |
Component: | postgis | Version: | master |
Keywords: | Cc: |
Description
An MVT test failure is caused by r16671, as discussed in https://github.com/postgis/postgis/pull/268#issuecomment-407780730
One solution is described by Raul in the linked discussion. Another option is the following:
1) Update lwgeom_subdivide
to use lwgeom_intersection
instead of lwgeom_clip_by_rect
.
2) Revert lwgeom_clip_by_rect
to its 2.4 state (changes are based on a bug report that cannot be confirmed)
This should make MVT clipping work as it did in 2.4. I verified that it works locally but it requires rewriting the MVT tests to use ST_Equals
instead of text comparison.
Change History (3)
comment:1 by , 6 years ago
Owner: | changed from | to
---|---|
Status: | assigned → new |
comment:2 by , 6 years ago
Understood about directionality. The differences I was seeing were in the order of components and start point:
-PG9|POLYGON((4096 4096,0 4096,0 0,4096 0,4096 4096)) +PG9|POLYGON((0 4096,0 0,4096 0,4096 4096,0 4096)) -PG43 - ON |MULTIPOLYGON(((0 10,5 5,10 10,0 10)),((5 5,0 0,10 0,5 5))) +PG43 - ON |MULTIPOLYGON(((5 5,0 0,10 0,5 5)),((0 10,5 5,10 10,0 10)))
I'll add that ST_AsMVTGeom was ok with invalid geometries, either as input or after some of its internal transformations. Part of that was
lwgeom_clip_by_rect
being ok with them too. And, at least for 2.5, we want to keep this behaviour. I'll do some performance tests of the possible solutions.I'm avoiding St_Equals as it ignores directionality, which is mandatory in the MVT spec 2.1, and we have already been bitten by it (the tests used to ignore it, so introducing bugs was pretty easy).