CRS() loading rgdal

[mdsumner]

I'm interested in this comment here about depending on sp 1.2-1

https://github.com/rspatial/raster/blob/master/R/raster.R#L20-L25

Would you prefer to depend on that version of sp (it's one step later than current). Or, flush out the uses of CRS() and replace with saved or manually-constructed sp objects? Either way we need to review the uses of CRS() to add the argument.

It's bugging me that crop() requires a load of rgdal.

library(raster)  ## no rgdal loaded
## causes rgdal to load, because CRS() in raster.R without doCheckCRSArgs = FALSE
crop(raster(), extent(100, 110, -50, -30))

It becomes apparent in dev versions of rgdal and sp, because I'm seeing messages about PROJ files (but the session info is enough to show this with github-raster, and CRAN-sp/rgdal).

[rhijmans]

I think that in the example, crop() does not trigger rgdal, but raster() does.
Should I change the raster@crs slot from "class 'CRS'" to "character" ?

[mdsumner]

Ah, thanks - I suppose that's an easy way around it, good idea!

That implies a flush out of all CRS() and crs() calls?

[rhijmans]

But before making rash changes I need to understand this whole business of loosing PROJ.4 strings a bit better.

[mdsumner]

I started to write on that but was worried it not authorative enough ... basically only a few +datum strings are recognised, others are stripped. WKT2 should be used, but proj strings are ok for coarser use, in proj 6 we can also use strings like "epsg:4326" (no init anymore).

I've been working on hypertidy/PROJ for the new version, something I can use that's not format-bound.

[rhijmans]

I think this is fixed now, at least in some cases. I think I can only use doCheckCRSArgs = FALSE when the crs =NA, otherwise the wkt comment is not created. In your example using the default raster parameters, a "longlat" crs is created. I think you can work around that by doing raster(crs=NA)

[mdsumner]

ok thank you, understood