[R-sig-Geo] R 3.0.0 and spatial classes

[Barry Rowlingson]

On Mon, Dec 17, 2012 at 4:25 AM, Robert J. Hijmans <r.hijmans at gmail.com> wrote:
> Barry,
> Interesting idea. The proj4string discussion is good, but somewhat trivial;
> a major R release merits more than that. Are there bigger things to be done?
> How about a redesign of sp to accommodate objects that have data on disk (in
> a database, wherever) both for raster and points/lines/polys. I.e. that is a
> design where  having all values in a data.frame memory is a special case
> (but packages may require that to be possible); and such a change need not
> break any, or not much, code in other packages.

 Ha! And we come back round to my 'rmap' package from ~8 years ago! It
was a bunch of simple methods on spatial data where the objects
inherited from 'rmap' and a class like 'shapefile' or (potentially)
'postgis' so that when data was required it was gotten using an
appropriate method. The objects themselves didn't actually store any
data (I think now I'd make 'sp' one of the child classes for objects
all stored in memory).

I'd be very keen on something that would make it easier to work with
PostGIS data in this way, certainly...

> Add perhaps a few other
> things, such as matching holes to polygon-parts; rename the proj4string slot
> to something appropriate; change the bbox from a matrix to an Extent (or
> similar) object.

 Definitely +1 on the bbox->Extent thing. I hate bboxes :)

> Perhaps too much work for little gain? Focus on new things? I thought that
> attempt to clean topologies you were working on a while ago would be great
> to wrap up and package.

Was that some hacky thing I was doing with lines, or was I talking
about the pprepair code for cleaning planar polygon partitions? An R
interface to pprepair would be very nice.

Barry