[R-sig-Geo] sp: a package with classes and methods for spatial data in R

[Edzer J. Pebesma]

Tim Keitt wrote:

>Very cool. I'd been thinking of something similar, but not had the time
>to act on it. Looks like we need to add OGR wrappers to rgdal so that
>vector data can be read in.
>  
>
I think Barry has been there with Rmaps. It would
be nice to integrate this functionality into rgdal, because OGR
is part of rgdal, and the external-library dependence is still,
well, a bit clumsy for R under Windows.

>A couple of immediate items I noticed:
>
>1) "sp" is rather terse, no? I like more descriptive package names.
>  
>
Yes. Think of ts for time series. We thought of "spatial", but
that name has been taken long ago. sp is the first two letters
in spdep, splancs, spproj, ... Other suggestions, please?

>2) I think it is always a good idea to let typing describe internal
>states (ie making objects stateless). It leads to much cleaner
>interfaces and many fewer coding errors. If there are two different ways
>to represent a grid, make two classes. If they are perfectly
>substitutable (functions can take either), join them with a super-class.
>If one is a perfect subset of the other, then make it the parent class
>and the extension the child (inherits). See GDALDataset and
>GDALReadOnlyDataset. GDALDataset is a perfect superset of
>GDALReadOnlyDataset and so can be passed to any function needing the
>interface of GDALReadOnlyDataset. This is formalized by having
>GDALDataset inherit from GDALReadOnlyDataset. If you are writing
>functions that check or update the internal states of your objects
>(except ordinary insertion and deletion of contained items), then you
>should think twice about the object hierarchy. This is why there are no
>"is.writable" or "make.writable" functions in rgdal. That's all handled
>by type declarations (meaning you can customize dispatch on types in
>your methods ;-)
>  
>
I've been struggling with this for quite a while, and I do value
your suggestions. In an earlier attempt I tried two classes,
but I got strangled by the many setIs() and setAs() constructs
needed, which in addition didn't seem to do what I wanted.

Trouble is: right now SpatialGrid extends SpatialPoints: they're
points that happen to lie on a grid, so they carry grid topology
and an index to which grid cells the points belong. The full grid
representation in some sense is a special case of this, because
all points are there, in ordered form. In the data requirement
sense they're not: full grids don't need coordinates nor an index.
Data-wise, the extension is reversed: a full grid is the most
general case, the partial grid needs in addition an index (and,
-disputably-, coordinates). I'll think a bit longer about the
superclass idea, and struggle further with the setIs() stuff.

It's very convenient to have grids that behave like specially
ordered points.

>3) As long as we can override methods of the interface, all will be
>well. We can substitute external data representations when we need to
>scale to larger datasets. Try allocating a 50Kx50K matrix in R. There
>will be times when we will want to have data be in a database or on disk
>and still manipulate it with the "sp" interface. I don't see any
>barriers to this at the moment. These external wrappers will want to
>inherit from existing classes, so see point 2 above.
>  
>
I was playing with Europe on a kilometer grid, and wasn't
too happy about how much it filled the machine's memory.
This sounds extremely valuable; could this be done by moving
parts from rgdal into sp, or do we need to copy? Again, full
integration is out of the question because of the Windows/
CRAN/external library issue.

>Love the image gallery! Nice work!
>  
>
Thanks! Again -- what is still missing?
--
Edzer