[Gdal-dev] Re: OGR C API question

[Frank Warmerdam]

Etienne Dube wrote:
> Now, spatial filtering should work with OGR on this dataset. However, (correct 
> me if I'm wrong) the current implementation seems to be broken, it won't use 
> spatial queries to fetch the features from the table. Instead, it SELECTs all 
> the data in the layer, and uses a brute force approach (intersection on all 
> geometries). See the "OGRFeature *OGRPGLayer::GetNextFeature()" function in 
> ogrpglayer.cpp. So, if you're working on large datasets, methods like 
> OGRLayer::GetExtent() or OGRLayer::GetFeatureCount() will take a looooooong 
> time to execute. Same thing if, say, you want to display all the geometries 
> in a small rectangle; OGR will have to intersect this rectangle with all the 
> geometries in the layer, which takes some time to do.

Etienne,

I would just add that OGR does attempt to apply spatial constraints to the
query.  When it is building the WHERE clause to use, it includes the spatial
constraint.  Features that are selected will still best tested conventionally,
but if you have set a small area of interest via the spatial filter, it
should only have to check features in the correct area.

See OGRPGTableLayer::BuildWhere() to see the logic for applying the
BOX3D spatial filter.

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent