[gdal-dev] Problems doing spatial query with OGR

[Clay, Bruce]

Frank:
  Thanks for your reply.  I did the Luke Skywalker thing and used the
source based on your input.

I did forget to mention that I am working with Oracle Spatial.

It seems that the ExecuteSql overload that contains the spatial filter
is only called if the dialect is set to "OGRSQL".  Making that change
apparently requires others.

I can not use the "BETWEEN" statement with the date field and I can not
find a date format that works with the WHERE clause.  For some reason
the data type in OGR space is OFTString but it is DATE in Oracle space.
If I use the "generic" dialect I can do date comparisons.  My guess
along with some of the odd Oracle error messages that I am receiving is
that is causing at least part of the problem.

I think the spatial filter might actually have worked because the
returned feature count was lower but I could not tell for sure because I
could not get the where clause to be accepted.

Is there a way to make date/time comparisons in the OGR SQL dialect?

Bruce


-----Original Message-----
From: Frank Warmerdam [mailto:warmerdam at pobox.com] 
Sent: Wednesday, May 28, 2008 11:17 AM
To: Clay, Bruce
Cc: gdal-dev at lists.osgeo.org
Subject: Re: [gdal-dev] Problems doing spatial query with OGR

Clay, Bruce wrote:
> Environment: Windows XP Visual Studio 2005, GDAL 1.5.0 with the C#
SWIG 
> bindings.
> 
>  
> 
> I am trying to determine the number of features within a geographic 
> bounding box for a specific time period.  The code I am using is shown
below
> 
>  
> 
>     OSGeo.OGR.Feature feature;
> 
>     int numFeatures;
> 
>  
> 
>     string sqlString = "select count(*) from " + tableName + " where "
+ 
> queryDefString;

Bruce,

I don't think you mention the driver you are operating against.  I'm
guessing
it is a real RDBMS?

There is a problem that when we do ExecuteSQL() against a real database
the spatial filter has to be applied *after* the query since we have no
way
of inserting it into the actual SQL sent to the database.  That means we
can't alter the answer to the "SELECT COUNT(*)" part.  All we can do is
filter
features coming back from that select which in this case will be a
single
non-spatial attribute.

In fact, I'm not sure that the spatial filter is even honoured in this
fashion
by all drivers, though it ought to be.

If you really want to do this, my suggestion is to set an attribute
filter
with your WHERE statement, and a spatial filter on the OGRLayer, and
then
do GetFeatureCount().  That is more likely to work.

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    | President OSGeo,
http://osgeo.org




This message and any enclosures are intended only for the addressee.  Please  
notify the sender by email if you are not the intended recipient.  If you are  
not the intended recipient, you may not use, copy, disclose, or distribute this  
message or its contents or enclosures to any other person and any such actions  
may be unlawful.  Ball reserves the right to monitor and review all messages  
and enclosures sent to or from this email address.