search

rsbivand / rgrass

Interpreted interface between the GRASS geographical information system and R
https://rsbivand.github.io/rgrass/
24 stars 8 forks source link

problem with readRAST from rgrass7 #27

Closed olenko closed 2 years ago

olenko commented 3 years ago

I used the command readRAST (rgrass7) to get maps into R. Now, it does not work. I tried several options with 0 result. Updated all R packages. Installed GRASS 7.8.5. Started Rgui within GRASS. Getting

elev <- readRAST("elevation", ignore.stderr=TRUE) Error in sp::CRS(getLocationProj()) : NA

I still can get vector maps via readVECT with no issues.

Is there any way to fix it? If not, what is the current method to get GRASS raster maps into R?

Thank you.

===============

R version 4.0.5 (2021-03-31) -- "Shake and Throw" Copyright (C) 2021 The R Foundation for Statistical Computing Platform: x86_64-w64-mingw32/x64 (64-bit)

During startup - Warning messages: 1: Setting LC_CTYPE=en_AU.cp1252 failed 2: Setting LC_COLLATE=en_AU.cp1252 failed 3: Setting LC_TIME=en_AU.cp1252 failed 4: Setting LC_MONETARY=en_AU.cp1252 failed

library(sp) library(rgrass7) Loading required package: XML GRASS GIS interface loaded with GRASS version: GRASS 7.8.5 (2020) and location: nc_spm_08_grass7 library(rgdal) rgdal: version: 1.5-23, (SVN revision 1121) Geospatial Data Abstraction Library extensions to R successfully loaded Loaded GDAL runtime: GDAL 3.2.1, released 2020/12/29 Path to GDAL shared files: C:/Users/andrew/Documents/R/win-library/4.0/rgdal/gdal GDAL binary built with GEOS: TRUE Loaded PROJ runtime: Rel. 7.2.1, January 1st, 2021, [PJ_VERSION: 721] Path to PROJ shared files: C:/Users/andrew/Documents/R/win-library/4.0/rgdal/proj PROJ CDN enabled: FALSE Linking to sp version:1.4-5 To mute warnings of possible GDAL/OSR exportToProj4() degradation, use options("rgdal_show_exportToProj4_warnings"="none") before loading rgdal. Overwritten PROJ_LIB was C:/Users/andrew/Documents/R/win-library/4.0/rgdal/proj gmeta() gisdbase C:\andrew\GISDATABASE location nc_spm_08_grass7 mapset PERMANENT rows 280 columns 767 north 307000 south 27000 west 151000 east 918000 nsres 1000 ewres 1000 use_sp()

sessionInfo() R version 4.0.5 (2021-03-31) Platform: x86_64-w64-mingw32/x64 (64-bit) Running under: Windows 10 x64 (build 18363)

Matrix products: default

locale: [1] LC_COLLATE=C LC_CTYPE=English_Australia.1252 [3] LC_MONETARY=C LC_NUMERIC=C
[5] LC_TIME=C

attached base packages: [1] stats graphics grDevices utils datasets methods base

other attached packages: [1] rgdal_1.5-23 rgrass7_0.2-6 XML_3.99-0.6 sp_1.4-5

loaded via a namespace (and not attached): [1] compiler_4.0.5 grid_4.0.5 lattice_0.20-41 > elev <- readRAST("elevation", ignore.stderr=TRUE) Error in sp::CRS(getLocationProj()) : NA

rsbivand commented 3 years ago

Thanks, I can replicate the problem. Will analyse and report back.

rsbivand commented 3 years ago

The underlying problem is that WinGRASS is distributed with its copy of proj.db used by PROJ, and CRAN Windows binary packages rgdal/sf with their copies. If they are from the same version of PROJ, it shouldn't matter, if the versions differ, the newer one may use a different structure of table and field names from the older one. g.proj called by getLocationProj() wants to use the proj.db shipped with GRASS and sees the one shipped with rgdal because environment variable PROJ_LIB is set by rgdal. I see EPSG version 10.008 for the proj.db shipped from CRAN, but 9.8.6 with WinGRASS 7.8.5. This is why the problem happens, as the GRASS code expects the older format. One fix may be to fall back to Proj4 if WKT2 fails for that reason. I'll try this first.

rsbivand commented 3 years ago

This is a Windows binary package version matching the source commit just made. Please either install the develoopment version from source, or use this binary and report back. The two proj.db versions still warn of trouble, but there is no failure.

rgrass7_0.2-6.zip

olenko commented 3 years ago

Thank you very much! I can use readRAST from this development version now.

neteler commented 3 years ago

In the upcoming GRASS GIS 7.8.6 (to be released soon, draft release notes: https://trac.osgeo.org/grass/wiki/Release/7.8.6-News) full PROJ6+ + WKT2 support has been included. The related PR is https://github.com/OSGeo/grass/pull/1240 which has been backported to the 7.8. release branch on Feb 19, 2021.

(just for your information, in case it is relevant here)

rsbivand commented 3 years ago

Thanks, I'll check against the stand-alone WinGRASS version - is this already in the 7.9 preview? The key thing is the version of PROJ and its bundled EPSG database in proj.db; this only bites when the proj.db versions on the R and GRASS sides differ (I think).

veroandreo commented 3 years ago

For the next release you should check releasebranch_7_8: https://github.com/OSGeo/grass/tree/releasebranch_7_8, from where 7.8.6 will emerge

7.9 is currently master branch (it will become grass 8.0 hopefully soon 8-))

rsbivand commented 3 years ago

I understand, however, this gives no information about the WinGRASS build process, or the choice of PROJ version made there. On systems not using stand-alone R spatial packages or GRASS, all the downstream software uses the same PROJ and proj.db (unless they are not updated consistently). It looks from https://trac.osgeo.org/grass/wiki/CompileOnWindows#CreateaGRASSself-containedPackage and https://github.com/OSGeo/grass/blob/master/mswindows/GRASS-Packager.bat.tmpl as though building the installer bundles the proj DLL and share/proj from OSGeo4W. It would be most helpful if the active GRASS session could be able to report the PROJ version it is using (see also thread including https://lists.osgeo.org/pipermail/proj/2021-April/010162.html).

If http://download.osgeo.org/osgeo4w/x86_64/versions.html is correct, PROJ 6.3.2 is used for current, and the same for test. So the problem for WinGRASS and OSGeo4W GRASS is that it is being built on a lagging version of PROJ, possibly because CDN handling is not up to speed (or programmes using PROJ have only managed to upgrade to PROJ 6, but not 7 or 8. See also https://github.com/r-spatial/discuss/issues/44, where this case illustrates the possible advantages of r-spatial engaging directly with OSGeo, to help think through robust ways of securing software interoperation.

neteler commented 3 years ago

Maybe @jef-n or @hellik can enlighten us here?

jef-n commented 3 years ago

OSGeo4W testing uses PROJ8 (along with numerous other newer versions) and eventually will replace the current OSGeo4W. The packages there are built using the recipes from https://github.com/jef-n/OSGeo4W.

See also https://lists.osgeo.org/pipermail/grass-user/2021-February/082242.html (repost from https://lists.osgeo.org/pipermail/osgeo4w-dev/2021-February/004050.html / https://lists.osgeo.org/pipermail/qgis-user/2021-February/048137.html)

rsbivand commented 3 years ago

@jef-n Thanks, let's see what versions WinGRASS 7.8.6 chooses to go with. GRASS source can handle recent GDAL/PROJ, so the choice is for those who bundle the release.

Thorsten-Behrens commented 3 years ago

Hi Roger,

the problem still occurs on my setup.

Info:

sessionInfo() R version 4.0.5 (2021-03-31) Platform: x86_64-w64-mingw32/x64 (64-bit) Running under: Windows 10 x64 (build 19042)

library(rgdal) rgdal: version: 1.5-23, (SVN revision 1121)

gmeta() gisdbase C:\Users\Thorsten\Documents\grassdata location demolocation mapset PERMANENT rows 180 columns 360 north 90 south -90 west -180 east 180 nsres 1 ewres 1

Anything else I can test/share to help solving the issue?

Thanks a lot in advance, Thorsten

rsbivand commented 3 years ago

The report was about the WinGRASS stand-alone, not GRASS-in-OSGEO4W. Please provide a full reprex without external scripts and showing exactly what is returned by rgrass7::getLocationProj() in your case. I really do not have the capacity to maintain multiple GRASS Windows binary installs; Windows users will shortly be on their own here. Do also use https://lists.osgeo.org/mailman/listinfo/grass-stats to share experiences; github issues are very hard to find and solutions do not propagate.

rsbivand commented 3 years ago

I do not see that the fix in the development version of rgrass7 does not work on GRASS 7.8.5 from OSGEO4W - without the fix, the difference in proj.db versions matters, but with it, the internal execGRASS("g.proj", flags="w") fails and falls back to the Proj4 string with possible loss of accuracy.

Thorsten-Behrens commented 3 years ago

Hi! I switched to Linux (Ubuntu 2010, x86-64) and have the same problem with rgrass7 0.2-6. This is however under R 4.0.3 and GRASS 7.8.3. I will try to upgrade asap and report.

Thorsten-Behrens commented 3 years ago

Hi Roger,

I switched to WinGrass on my Windows 10 computer, but had to downgrade rgrass7 to 0.2-1 to make it work. All newer version return an error.

R and package versions: R: 4.0.5 sp: 1.4-5 raster: 3.4-10 rgdal: 1.5-35 sf: 0.9-8

Thanks, Thorsten