Skip to content
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

Closed
rsbivand opened this issue Nov 3, 2019 · 7 comments
Closed

PROJ >= 6 adaptation in sp and rgdal #78

rsbivand opened this issue Nov 3, 2019 · 7 comments

Comments

@rsbivand
Copy link
Contributor

rsbivand commented Nov 3, 2019

In connection with PROJ >= 6 adaptation in sp and rgdal, I've marked rgdal/R/wrappers.R functions with:

# NOT UPDATED FOR PROJ >= 6
if (new_proj_and_gdal()) warning("NOT UPDATED FOR PROJ >= 6")

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.

@rsbivand
Copy link
Contributor Author

RFC now on http://rgdal.r-forge.r-project.org/articles/PROJ6_GDAL3.html, no need to unzip.

ranghetti added a commit to ranghetti/sen2r that referenced this issue Nov 19, 2019
ranghetti added a commit to ranghetti/sen2r that referenced this issue Nov 19, 2019
## 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)
@rhijmans
Copy link
Member

rhijmans commented Dec 9, 2019

Thank you for warning me about these changes. I think this would only apply to rgdal::rawTransform? It would prefer to handle the warnings; or at least some way to avoid getting the same warning many times. I could call it either once per session, or perhaps better, once each time the function is called that uses rawTransform (but may use it many times in a loop).

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?

@rsbivand
Copy link
Contributor Author

rsbivand commented Dec 9, 2019

Yes, rgdal::rawTransform is affected, but more problematic is the silent degrading of PROJ strings on reading from file in PROJ6/GDAL3 compated to PROJ5/GDAL2. The GDAL C++ function ExportToProj4() drops +datum=, and +towgs84= and +nadgrids= are fragile. The conversion from PROJ string to the internal representation in ImportFromProj4() is not affected as such, so CRS should be able to be instantiated from PROJ strings (we think). My guess would be that just doing raster() on a geotiff will be similar to now (Frank Warmerdam introduced a preference for +towgs84= rather than +datum= ten years ago. Vector data hit the ExportToProj4() problem directly unless the datum is WGS84, NAD27 or NAD83 (IIRC).

That means we cannot rely on Proj strings as read in from files, and we will have to prefer WKT2_2018 either as a comment() to sp::CRS S4 objects, or as an extra component in sf::crs S3 objects.

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 rgdal::rawTransform() remains viable, or whether it can be changed to use a user selected coordinate operation rather than source/target pairs.

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.

@rhijmans
Copy link
Member

rhijmans commented Dec 9, 2019

Thank you very much for your explanation and efforts. I'll try to catch up.

@brendaprallon
Copy link

Hi, I am new to GIS data and I have just stumbled on this problem. Could someone maybe help me understand this?
I am trying to write a raster with CRS '+init=epsg:5877', which works fine with PROJ 5, but not with PROJ 6 - I get the following warning:
Warning message: In showSRID(uprojargs, format = "PROJ", multiline = "NO") : Discarded datum South_American_Datum_1969_96 in CRS definition

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!

@rsbivand
Copy link
Contributor Author

rsbivand commented Aug 7, 2020

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.

@brendaprallon
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants