-
Notifications
You must be signed in to change notification settings - Fork 52
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
PROJ >= 6 adaptation in sp and rgdal #78
Comments
RFC now on http://rgdal.r-forge.r-project.org/articles/PROJ6_GDAL3.html, no need to unzip. |
## Minor changes - Add NDBI / NDVIre indices (#241) - Add footprint among metadata retrieved using `safe_getMetadata()` (from existing offline SAFE archives) and `s2_list()` (from SciHub online metadata) - Filter offline SAFE archives by footprint instead than by S2 tile ID, so skipping using images which do not contain any data for a specific Area Of Interest - Add method to convert class `safelist` to `sf` (using footprint) ## Fixes - Hide warning using PROJ >= 6 (rspatial/raster#78)
Thank you for warning me about these changes. I think this would only apply to I am a bit confused about the changes that are coming --- and need to find some time to carefully read about them. I understand the need for very high precision for certain applications. But I also think that the PROJ.4 notation serves us very well in R, as it can easily be edited and understood; that most people use WGS84; and that EPSG codes are not generally useful because the number of CRSs is infinite (the number of datums is finite, however). So I wonder if we can stick with the PROJ.4 notation at the user level at as much as possible; and write work-arounds; and provide high precision options for those who need it? |
Yes, That means we cannot rely on Proj strings as read in from files, and we will have to prefer WKT2_2018 either as a Transformation is also affected, with fallback to ballpark accuracy essentially ignoring datum shift. I do not thinnk that there is a viable option to stay with PROJ4 or PROJ5 and GDAL 2, as multiple installs are messy and require too much maintenance. See the links provided, and new discoveries such as axis-swapped coordinates in recent sf issues. I feel that you'll have to see whether There isn't even a good road-map, really, I've folllowed pyproj and GRASS in addition to seeing what QGIS and others have done. Following the PROJ mailingg list may also give a flavour. I'll have a video of a recent talk online next week I think. |
Thank you very much for your explanation and efforts. I'll try to catch up. |
Hi, I am new to GIS data and I have just stumbled on this problem. Could someone maybe help me understand this? This actually happens with multiple EPSG codes. Is there a real problem with this warning, or can I ignore it? If not, is there a easy way around this? Should I just stick with PROJ 5 for the time being? Thank you very much for the attention! |
Please read https://cran.r-project.org/web/packages/rgdal/vignettes/CRS_projections_transformations.html and https://www.r-spatial.org/r/2020/03/17/wkt.html. Packages are transitioning from Proj4 string to WKT2 string representations of coordinate reference systems (CRS). User workflows lag packages, so may be (but are not necessarily) impacted by the change in representation. So the warnings are in place for sp 1.4-* and rgdal 1.5-* to alert users to vulnerabilities, which package maintainers cannot control - only the end user can check whether the outputs from older workflows remain unchanged as CRS representations change. And no, do not try to stick with PROJ 5, it will not be supported in the (near?) future. |
Thank you very much for the quick response, it was really helpful. Hopefully the transition will be settled soon. Meanwhile, I will be paying more attention to this. |
In connection with PROJ >= 6 adaptation in sp and rgdal, I've marked rgdal/R/wrappers.R functions with:
Currently I'm testing the use of a WKT2 comment to piggyback WKT2 on otherwise unchanged
"CRS"
class objects (not pure S4, but adding a slot would break the sp API). Please see r-spatial/sf#1146 and r-spatial/discuss#28. Comments welcome.The text was updated successfully, but these errors were encountered: