[Rspatial-devel] spTransform

[Edzer Pebesma]

On 04/19/2013 06:02 PM, Roger Bivand wrote:
> On Fri, 19 Apr 2013, Edzer Pebesma wrote:
> 
>>
>>
>> On 04/19/2013 04:58 PM, Roger Bivand wrote:
>>> OK, but I can't release rgdal yet - there is an AddressSanitizer issue
>>> which means I have to install GCC 4.8 to check, clang wasn't able to.
>>> I'll say when I'm ready - rgdal will have to depend on the new sp, so
>>> that can go first, but should be checked to see what happens if old
>>> rgdal is installed with it.
>>>
>>
>> No, the dependency is reversed: rgdal has to go first, and then sp will
>> have to SUGGEST: the new rgdal 0.8-7; I updated the respective
>> DESCRIPTIONS. I went through checking all packages depending on
>> modified sp.
>>
>> I would be surprised if cran would halt releasing rgdal, for the reason
>> that you haven't managed to install a compiler that's only been out
>> there for three weeks (r-devel)... sounds pretty insane.
> 
> No, ASAN is much more specific than valgrind, and Brian means this
> seriously, like clang 3 weeks ago. Also if the method is defined in sp
> but not in rgdal, how can rgdal be loaded against an older sp that
> doesn't have the definition - it seems illogical.

rgdal defines it conditionally:

if (!isGeneric("spTransform"))
    setGeneric("spTransform", function(x, CRSobj, ...)
        standardGeneric("spTransform"))

I found out the dependency experimentally. I think it has to do with
having both S3 and S4 methods in place, which also sounds illogical. See:
http://r.789695.n4.nabble.com/namespace-S3-and-S4-generic-imports-cannot-both-be-satisfied-td4652576.html
but I must admit I could not follow that discussion, and our situation
involves three packages.

> 
> Roger
> 
>>
>>> Roger
>>>
>>> On Fri, 19 Apr 2013, Edzer Pebesma wrote:
>>>
>>>> spTransform is currently defined, both as S4 and S3 methods, in
>>>> rgdal. I
>>>> try to export it in spacetime (for ST objects), but this doesn't work
>>>> because rgdal is not imported (I'd like to avoid dependence on rgdal).
>>>>
>>>> My suggestion is to:
>>>>
>>>> add the definition of the S4 generic to sp, and have sp export it, but
>>>> not provide methods for it.
>>>>
>>>> This works, but will lead to all kind of warnings when loading rgdal,
>>>> caused by the S3 methods. So my second suggestion is:
>>>>
>>>> remove all S3 definitions & exports of spTransform from rgdal. After
>>>> that, all three work happily together:
>>>>
>>>>> library(rgdal)
>>>> Loading required package: sp
>>>> rgdal: version: 0.8-6, (SVN revision 453M)
>>>> Geospatial Data Abstraction Library extensions to R successfully loaded
>>>> Loaded GDAL runtime: GDAL 1.9.2, released 2012/10/08
>>>> Path to GDAL shared files: /usr/share/gdal/1.9
>>>> Loaded PROJ.4 runtime: Rel. 4.8.0, 6 March 2012, [PJ_VERSION: 480]
>>>> Path to PROJ.4 shared files: (autodetected)
>>>>> library(spacetime)
>>>>> showMethods(spTransform)
>>>> Function: spTransform (package sp)
>>>> x="SpatialGridDataFrame", CRSobj="CRS"
>>>> x="SpatialLines", CRSobj="CRS"
>>>> x="SpatialLinesDataFrame", CRSobj="CRS"
>>>> x="SpatialPixelsDataFrame", CRSobj="CRS"
>>>> x="SpatialPoints", CRSobj="CRS"
>>>> x="SpatialPointsDataFrame", CRSobj="CRS"
>>>> x="SpatialPolygons", CRSobj="CRS"
>>>> x="SpatialPolygonsDataFrame", CRSobj="CRS"
>>>> x="ST", CRSobj="CRS"
>>>>
>>>> I committed both to r-forge.
>>>>
>>>
>>
>>
> 

-- 
Edzer Pebesma
Institute for Geoinformatics (ifgi), University of Münster
Weseler Straße 253, 48151 Münster, Germany. Phone: +49 251
8333081, Fax: +49 251 8339763  http://ifgi.uni-muenster.de
http://www.52north.org/geostatistics      e.pebesma at wwu.de