-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
raster crs representation #85
Comments
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
|
Meanwhile, it is advised to import or suggest |
From the documentation of Both So we won't follow:
|
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.The text was updated successfully, but these errors were encountered: