Adding SQL "where" to readOGR

On Wed, Jul 3, 2013 at 10:46 AM, Roger Bivand <Roger.Bivand at nhh.no> wrote:

It does vary from version to version, and may imply geometric where=,
which may also drag GEOS into its build train.

is that the build train for libgdal rather than for rgdal? Can
libgdal exist without GEOS?

Yes, the build train for libgdal; and yes, libgdal can and does exist 
without GEOS.

how much of the where=
to parse in R before despatch.

How about none of it. What does ogr2ogr do? It seems to just pass the
string through. I don't see why R would have to do anything with it
except check for errors if gdal returns a CPL_YOUR_SQL_MAKES_NO_SENSE
or CPL_YOU_TRIED_TO_DO_SOMETHING_THAT_NEEDS_GEOS_BUT_YOU_AINT_GOT_IT
error.

The error and warning messages from GDAL are often short and opaque, 
including empty layers. For medium-sized data sets, subsetting is 
certainly easier on the R side; for large ones, using ogr2ogr to select 
before import is a viable option.

They may very well also be interesting encoding challenges, because R and 
OGR may (and do) disagree on protocols for handling encoding, for example 
of placenames. A lot are in CP1252 or other variants, few are UTF-8, etc. 
So the search string going from R to OGR may need to know about the 
expected encoding on the "other" side to return hits. If the match should 
be of where=paste("bydel ==", shQuote("?sane")) or some such, the outcome 
will depend on the way encoding is handled.

I'm sure it will be fun!

Roger

I reckon attribute filtering would cover most of the 'can I do sql in
readOGR' messages I've seen.

All welcome!

One day...

Barry

Roger Bivand
Department of Economics, NHH Norwegian School of Economics,
Helleveien 30, N-5045 Bergen, Norway.
voice: +47 55 95 93 55; fax +47 55 95 95 43
e-mail: Roger.Bivand at nhh.no