[R-sig-Geo] Adding SQL "where" to readOGR

[Roger Bivand]

On Wed, 3 Jul 2013, Barry Rowlingson wrote:

> 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