Adding SQL "where" to readOGR
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