[gdal-dev] Spatial Filters and PostGIS

[Miller, Craig]

I haven't done any performance testing.  I was just looking to understand
how to best structure my code/queries to insure that it will continue to
work well with extremely large datasets.





On Thu, Feb 11, 2010 at 11:50 AM, Even Rouault <even.rouault at mines-paris.org
> wrote:

> Le Thursday 11 February 2010 19:53:41 Frank Warmerdam, vous avez écrit :
>
> Craig,
>
> Since GDAL 1.6.0, spatial filtering on layers returned by ExecuteSQL()
> should
> be rather fast (http://trac.osgeo.org/gdal/changeset/14291). I see a
> OGRPGResultLayer::SetSpatialFilter() method that appends an intersection
> test
> to the SQL request, similarly to what is done in OGRPGTableLayer. This is
> only true if the code was able to determine the SRID of the geometry column
> returned by your SQL request. Maybe your request is too complex for that ?
>
> Best regards,
>
> Even
>
> > Miller, Craig wrote:
> > > 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?
> >
> > Craig,
> >
> > Yes, that is correct.  When using ExecuteSQL() we pass on the SQL
> > directly without alternation which means we need to do the spatial
> > query manually after the fact.
> >
> > On the other hand, when you access postgres/postgis through a normal
> > OGRLayer, we do attempt to incorporate the spatial and attribute filters
> > into the internally generated SQL used to read the features.
> >
> > Best regards,
>
>
>


-- 
Craig Miller
Geospatial Software Architect
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20100211/ece0a6e5/attachment.html