-
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
Choice for printed crs output #168
Comments
The WKT string is too verbose. EPSG codes are not informative. The proj.4 description is a short and very expressive. I cannot think of a better alternative. |
Thanks for your response @rhijmans . As I understand it, proj4strings returned by rgdal/sp nowadays will not necessarily contain all needed information anymore to adequately define the CRS (it will depend on the CRS at hand), because GDAL3/PROJ>=6 only partly support proj4strings (e.g. +datum and +towgs84 keys are dropped). It may be not too harmful here in the sense that proj4strings would just be used in printing (when using recent GDAL/PROJ), but proj4strings are to be regarded as obsolete. To keep the printed CRS short, I'd still prefer a name or a code (which can be used to look up the correct WKT string) over a string of CRS parameters one cannot just trust. The following slides of R. Bivand (from slide 55 onward) provide an interesting example of proj4string degradation (with consequences): https://github.com/rsbivand/whyR20_files/raw/master/bivand_200927.pdf |
At this point I prefer having more information rather than less. If you want the gory details, you can use |
Related to #78. Going forward with PROJ 6+ and GDAL 3,
raster
currently (since at least c9f4464) supports WKT and EPSG-codes so that proj4strings can be avoided in code, which I find really great. Also, the arguments and functions already used the general termcrs
, which avoids confusion between alternative CRS representations.Currently, when printing a
Raster*
object, a proj4string is still printed. As a suggestion to provide more consistency when avoiding proj4string, i.e. when PROJ 6+ and GDAL 3 are used, it seems useful to print the WKT string or a descriptive CRS name. @rhijmans are there intentions to make changes in this area?It could for example improve consistency with
sf
, where a CRS name is printed if possible:Created on 2020-09-28 by the reprex package (v0.3.0)
Session info
The
sf
documentation says:printed proj4string with current raster (caf4148)
Created on 2020-09-28 by the reprex package (v0.3.0)
Session info
The text was updated successfully, but these errors were encountered: