[postgis-tickets] [PostGIS] #2556: ST_Intersects results depending on insert order

[PostGIS]

#2556: ST_Intersects results depending on insert order
--------------------------------------------------+-------------------------
 Reporter:  gekorob                               |       Owner:  pramsey      
     Type:  defect                                |      Status:  new          
 Priority:  high                                  |   Milestone:  PostGIS 2.1.2
Component:  postgis                               |     Version:  2.1.x        
 Keywords:  st_intersects intersection geography  |  
--------------------------------------------------+-------------------------

Comment(by pramsey):

 Thank you for the complete and easily replicable ticket. Confirmed,
 something is amiss. (OSX, pgsql 9.3, postgis 2.1). You note your 2.0
 postgis provides correct (though slower) results?

 For future reference, when you see order-dependence in results usually
 you're seeing something wrong in the geometry caching system. The uncached
 initial results and cached secondary results are disagreeing. In your
 case, there's something *else* going on, since curiously both the brute
 force and the tree results agree, but the cached result does not.

 ST_Intersects is actually just a synonym for distance == 0, and the
 algorithms are shared between the two operations, so the first thing I
 always do when I get a report like this is compare the distance results
 for various ways of running the query:

 {{{
 select id, name, st_distance(extent,
 st_geogfromtext('SRID=4326;POLYGON((-46.625977 81.634149,-46.625977
 81.348076,-48.999023 81.348076,-48.999023 81.634149,-46.625977
 81.634149))')) from images;

 select id, name, _st_distancetree(extent,
 st_geogfromtext('SRID=4326;POLYGON((-46.625977 81.634149,-46.625977
 81.348076,-48.999023 81.348076,-48.999023 81.634149,-46.625977
 81.634149))')) from images;

 select id, name, _ST_DistanceUnCached(extent,
 st_geogfromtext('SRID=4326;POLYGON((-46.625977 81.634149,-46.625977
 81.348076,-48.999023 81.348076,-48.999023 81.634149,-46.625977
 81.634149))')) from images;
 }}}
 Usually I find a distance between the two algorithms, the tree and the
 uncached brute force. In this case, the difference is between the wrapped
 cache function and the others. This will take some effort to debug, which
 won't happen for a while as I have other paid work at the moment.

-- 
Ticket URL: <http://trac.osgeo.org/postgis/ticket/2556#comment:1>
PostGIS <http://trac.osgeo.org/postgis/>
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.