Closed florisvdh closed 3 years ago
Maybe, explicit CRS setting can then be just dropped as well, insisting on PROJ 6+/GDAL 3
Nope, it will always clash for datasets constructed by ESRI software. The ESRI CRS specification (which is abundant in Geopunt data sources) of its 'Belge 1972 / Belgian Lambert 72' CRS, which it says to be 'Well known ID 31370', is syntactically different from the official EPSG specification of EPSG:31370. Notably, it specifies 'false easting' and 'false northing' with a precision of 10-5 m and 10-4 m respectively (EPSG: precision 10-3 m), and it switches 1st and 2nd standard parallels.
This results in negligable actual coordinate differences (supporting the approach of overriding the CRS with official EPSG:31370), but as the ESRI 'Belge 1972 / Belgian Lambert 72' CRS is technically different from official EPSG:31370 'Belge 1972 / Belgian Lambert 72' CRS, despite ESRI's reference to it, the ESRI variant results in clashes when confronted with actual EPSG:31370 (this can be observed e.g. in R and in GRASS). Overriding and setting as EPSG:31370 seems the best option.
Also the Geopunt metadata state that the CRS is EPSG:31370 (example) while technically it is different from EPSG:31370.
UPDATE: the ESRI version of 'Belge 1972 / Belgian Lambert 72' is known by PROJ as ESRI:102499
= "Belge_Lambert_1972_bad_FE_FN" (referring to bad false easting & northing). Compare below WKT2 strings.
projinfo EPSG:31370 -o WKT2:2019
projinfo ESRI:102499 -o WKT2:2019
This would allow dropping the
Suggests: sp
part.
Meanwhile, it is advised to import or suggest rgdal
for functions that use raster
. While raster
does not import it, raster
does use rgdal
(it's in its 'suggests') in functions used by n2khab
. And this makes renv::init()
and renv:snapshot()
standard implementations incomplete, i.e. missing rgdal
(example fix here).
this makes
renv::init()
andrenv:snapshot()
standard implementations incomplete, i.e. missingrgdal
From the documentation of renv::dependencies()
and from tests, it can be concluded that rgdal
will only be added to renv.lock
by default when either a package (that is explicitly loaded in a project) imports rgdal
(as defined in its DESCRIPTION
file), or library(rgdal)
explicitly appears in a project script.
Both sp
and raster
have rgdal
in their Suggests
section. So the challenge lies entirely with renv
/ the renv
user; we should not try to handle this in n2khab
.
So we won't follow:
Meanwhile, it is advised to import or suggest rgdal for functions that use raster.
Follow-up to #67 and #84.
CRS representation is to be revisited once
raster
from CRAN accepts simple EPSG-code as input forcrs<-
(as on GitHub), i.e. withraster>=3.3-16
. This would allow dropping theSuggests: sp
part.Maybe, explicit CRS setting can then be just dropped as well, insisting on PROJ 6+/GDAL 3, on condition this omission causes no further clashes with other object's CRSes. The same may be considered for
sf
data sources at that time.