<div>Thanks for the confirmation. I'll tweak my queries accordingly.</div>
<div> </div>
<div>Craig<br><br></div>
<div class="gmail_quote">On Thu, Feb 11, 2010 at 10:53 AM, Frank Warmerdam <span dir="ltr"><<a href="mailto:warmerdam@pobox.com">warmerdam@pobox.com</a>></span> wrote:<br>
<blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote">
<div class="im">Miller, Craig wrote:<br>
<blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote">I was browsing the PostGIS driver code today and noticed that when used with ExecuteSQL the spatial filters appear to be getting applied on the client side instead of the PostGIS side. Am I understanding the code correctly?<br>
</blockquote><br></div>Craig,<br><br>Yes, that is correct. When using ExecuteSQL() we pass on the SQL<br>directly without alternation which means we need to do the spatial<br>query manually after the fact.<br><br>On the other hand, when you access postgres/postgis through a normal<br>
OGRLayer, we do attempt to incorporate the spatial and attribute filters<br>into the internally generated SQL used to read the features.<br><br>Best regards,<br><font color="#888888">-- <br>---------------------------------------+--------------------------------------<br>
I set the clouds in motion - turn up | Frank Warmerdam, <a href="mailto:warmerdam@pobox.com" target="_blank">warmerdam@pobox.com</a><br>light and sound - activate the windows | <a href="http://pobox.com/~warmerdam" target="_blank">http://pobox.com/~warmerdam</a><br>
and watch the world go round - Rush | Geospatial Programmer for Rent<br><br></font></blockquote></div><br><br clear="all"><br>-- <br>Craig Miller<br>Geospatial Software Architect<br>