Opened 11 years ago
Closed 11 years ago
#2764 closed defect (wontfix)
Strange result from ST_Intersection after converting between geom and geog
Reported by: | realityexists | Owned by: | pramsey |
---|---|---|---|
Priority: | medium | Milestone: | |
Component: | postgis | Version: | 2.1.x |
Keywords: | Cc: |
Description
I'm getting some strange behaviour from ST_Intersection. I want to find the intersections between many polygons/multi-polygons and many linestrings and to do this faster I split the polygons into tiles using ST_Intersection(geom), as recommended on postgis-users. I then use ST_Intersection(geog) on the resulting tiles with my lines. This generally works, but one particular multi-polygon is causing problems, even though it's not near the dateline.
One of the tiles for this polygon ends up being POLYGON((-3 2,-3 2,-3 1,-3 1,-3 2)). This is clearly not valid. When intersected with a LINESTRING that just touches it the entire LINESTRING is returned, which is incorrect.
It wouldn't be so bad if I could filter it out as invalid, but ST_IsValid() returns true. (It returns false for the above text, but not for the original tile, so some precision must be getting lost in ST_AsText.)
The attached repro should clarify things. Note that I had to save it using ST_AsBinary, because after round-tripping through ST_AsText or ST_AsEWKT I can no longer reproduce.
I'm not really sure what SHOULD happen here, but pretty sure it's not this.
POSTGIS="2.1.3 r12547" GEOS="3.4.2-CAPI-1.8.2 r0" PROJ="Rel. 4.8.0, 6 March 2012" GDAL="GDAL 1.10.0, released 2013/04/24" LIBXML="2.7.8" LIBJSON="UNKNOWN" RASTER
PostgreSQL 9.2.8, compiled by Visual C++ build 1600, 64-bit running on Windows 7
Attachments (2)
Change History (5)
by , 11 years ago
Attachment: | poly_intersection_bug2764.sql added |
---|
by , 11 years ago
Attachment: | poly_intersection_bug2764.png added |
---|
Visualisation of the original polygon (light blue), tile (black) and linestring to intersect with (dark blue)
comment:1 by , 11 years ago
I don't think we'll be able to do anything about this. Despite all the other ceremony around it, it comes down to a dimensional collapse problem, as the nearly-invalid polygon collapses during the intersection routine. And we don't have any general solution for that problem at the moment. So you'll have to fix it at the application level, maybe looking for incredibly-small polygons, to filter them out.
comment:2 by , 11 years ago
You mean with something like "WHERE ST_Area(tile) > 1e-10" ? Yes, that seems to work and doesn't even slow things down, it seems. Thanks!
comment:3 by , 11 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
Great I'm closing this out as a won't fix.
Repro