[postgis-users] The operator && is not overlapsoperator basedonthe OGC SF SQL

[David Blasby]

> This means that if one has only bounding boxes geometries then this is valid
> "geom && candidate" <=> "geom && candidate AND intersects(geom,candidate)"

No, this isnt correct.


You are absolutely correct, the "&&" is poorly named.  This is for
historical reasons (the && operator was defined as "overlaps" by the
original postgresql geometry types).  It would be better named
something like "MBR_intersects".
A documentation change should be made so this is more clear and doesnt
conflict with the OGC named relationship.

g1 && g2 <==>  intersects ( envelope(g1) , envelope(g2) )

The "&&" is extreamly useful because its (1) fast and (more
importantly) (2) indexed.

Most of the time, you will do your query like this:

SELECT ... FROM ... WHERE the_geom && <geometry/bbox> AND <geometry op>;

The && is indexed (so its really fast) and will return an
"approximate" solution (all geometries whose bounding box intersects
the "search geometry's bounding box").

When you provide the "AND <geometry op>" portion, you refine the
approximate solution to the exact solution.  For example, "AND
touches(the_geom, <geom>)" or "AND intersect(the_geom,<geom>)".

Since pulling millions of geometries off the disk is slow, and the
geometry operations are computationally intensive using the index
speeds things up!

 NOTE: there are some situations where using "&&" isnt appropriate.
For example, "AND disjoint(the_geom,<geom>)" isnt going to be
effective because the "&&" approximate solution isnt correct.

Use "&&" when 
 geometry_op(the_geom,<geom>)  ==> intersects(envelope(the_geom),
envelope(<geom>))

dave