On Wed, Apr 23, 2008 at 3:27 AM, Dylan Beaudette <<a href="mailto:dylan.beaudette@gmail.com">dylan.beaudette@gmail.com</a>> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">On Tuesday 22 April 2008, Paul Ramsey wrote:<br>
> The operators (@, &&, etc) all work on bounding boxes. The functions<br>
> all work on full geometries. It is possible for geometries to satisfy<br>
> bounding box containment while not satisfying full geometric<br>
> containment, hence your discrepancy.<br>
><br>
> P.<br>
<br>
</div>Thanks for the clarification.<br>
<br>
Does it make sense any more to use one of the &&, @, etc. operators to<br>
pre-filter geometries, or do the ST_ functions take care of that in call<br>
cases? i.e. can you think of any cases where it would still be a good idea to<br>
use something like<br>
<br>
select st_intersection(a,b)<br>
from a, b<br>
on a && b ;<br>
<br>
Thanks,<br>
<br>
Dylan</blockquote><div><br>In the past, that was the recommended approach. With the ST_ prefixed
functions, PostGIS will automatically include the bounding box
operators for pre-filtering.<br>
It's just that good.<br>
<br>
--<br>
Mark<br> </div></div><br>