Meeting minutes on interfacing GRASS from R

[florisvdh]

Meeting minutes on interfacing GRASS from R

Further edits are welcome.

2023-06-04 15:00 CEST
Conversation as part of the GRASS Community Meeting in Prague 2023
Participated: Roger Bivand (online), Vero Andreo (online), Vaclav Petras, Anna Petrasova, Helmut Kudrnovsky, Micha Silver, Floris Vanderhaeghe

Package management

GitHub repo ownership

• Since Roger is retired and will stop maintaining the rgrass package, this repo needs to move to a GitHub organization. Decision has not been taken about which one, but some obvious possibilities are:
  • rspatial (administered by @rhijmans):
    • because terra, the current preferred rgrass workhorse for R object transfer to/from GRASS database, is hosted there.
    • but has only one member
  • r-spatial (administered by @edzer):
    • 19 members
    • also hosts the QGIS-R interface package qgisprocess
    • but does not include terra

Retiring rgrass7

• Vero will promote the retirement of rgrass7 and user uptake of rgrass; Roger prepares a short text for that. Follow-up at https://github.com/rsbivand/rgrass/issues/77. News item was created and merged already: News: add post contributed by @rsbivand regarding rgrass7 retirement grass-website#370.
• At least the openSTARS package has not yet taken steps to migrate to rgrass. Contact with @MiKatt was tried by email and in GitHub; no response so far. Anyone who can get in touch: please do so.

Needs & desires with relation to internals

Using the GDAL-GRASS GIS drivers to read GRASS data

• With help of Markus and Vaclav, Floris has explored the possibility to directly read from the GRASS database with GDAL, using terra (rasters & vector), sf (vector), stars (spatiotemporal arrays, including rasters). This requires the standalone GDAL-GRASS GIS drivers for vector and raster to be installed next to GDAL and GRASS. This approach avoids the export write operation to a file before reading into R.
• Currently rgrass does not provide this approach. But it is not new: Roger mentions that in earlier states of the R package, code was included to follow this approach if the extra drivers were available. Roger advises to look at the latest state of https://r-forge.r-project.org/projects/spgrass/ to consider re-uptake (checkout with svn checkout svn://r-forge.r-project.org/svnroot/spgrass/; see also https://r-forge.r-project.org/R/?group_id=2020 and https://github.com/r-forge/spgrass). The GDAL-GRASS approach was dropped before moving development to GitHub.
• The reason for dropping support for the GDAL-GRASS driver was the belief of it not being maintained that much, and because it would be difficult on Windows. @neteler countered both after the discussion; he's eager to continue support and it's also being used in Geoserver. It would be great if rgrass would adopt it. Windows is no problem if OSGeo4W is used.

Conclusion: work is needed to re-integrate the GDAL-GRASS GIS drivers. Also the CRS representation needs attention, either on the driver or on the terra side (see observations in https://github.com/rsbivand/rgrass/issues/75). An idea could be to propose a Google Summer of code project for this topic.

R packages used for data transfer to/from GRASS database

• It is agreed that it is not needed to provide ways for terra and sf and stars to do the data transfer with GRASS in rgrass (as explored above). The minutes in https://github.com/rsbivand/rgrass/issues/34 (Dec 2021) are outdated on that; since then development has been done to:
  • prefer terra for data transfer since it aligns the data model of GRASS GIS most closely:
    • consider rasters as 2D objects
    • provide support for both rasters and vectors
  • add a vignette of how to coerce to and from terra objects – hence supporting sf and stars as well.
• It can still be considered at some later stage to support:
  • spatiotemporal data from GRASS, e.g. with stars
  • remote GRASS data, e.g. with gdalcubes

Dependency management

The XML package is currently used to parse the XML string returned from GRASS modules called with the --interface-description flag (see vignette about launching R in GRASS / GRASS in R). But the package is currently less popular and maintained than the xml2 package.

Maybe XML is going to get unsupported at some future time, so better to step over and migrate the XML functions to xml2 functions. This especially applies to parseGRASS().

Continuous integration

Latest state of this can be found in https://github.com/rsbivand/rgrass/issues/61.

@VLucet was in the process of getting GRASS installed in different GHA workers (operating systems). When would this be ready @VLucet?

Needs & desires with relation to the user interface

Names of functions & arguments; many arguments

• Function names:
  • the namespace can be improved to make function names more consistent, and perhaps more appealing.
  • maybe some functions don't need to be exported.
  • the function names with 'GRASS' are quite atypical.
  • Conclusion:
    it is preferred to drop the GRASS suffixes, use lowercase function names with snake_case, and consistently use a prefix common to all exported functions, e.g. rg_ (referring to rgrass) so that (similarly to sf and qgisprocess). So execGRASS() would be turned into rg_exec(). A proposal of function names and which to keep exported is needed.
• Arguments:
  • the function documentation is not so attractive to users, since it is overwhelmed by rather complex or non-self-explanatory argument names and their sometimes complex explanations, e.g. many control arguments in execGRASS(), with perhaps some potentially superfluous ones like legacyexec.
  • still, most are probably needed in specific situations. In most cases however, the defaults are OK so these arguments are not needed by most users, but they flood the function documentation and may scare novices.
  • Conclusion:
    • it is agreed to wrap the control arguments into a single control argument that takes a list of (original) elements. Or put more generally, to collapse certain sets of arguments.
    • this would happen in the new, renamed functions, which can then call the original functions in order to avoid rewriting the existing functions, and in order not to break existing R scripts of users, or reverse dependent packages.
    • the original functions will first be deprecated, and after a while they'll become internal.
    • also, argument names are to be improved (made more comprehensible) where possible.

TO DO: make an issue with proposed new function names, usage (new arguments with defaults), and an indication of 'becoming internal'. So also including old function names that are kept (internally).

Documentation

• See above for function documentation.
• Besides the vignette https://github.com/rsbivand/rgrass/blob/2c90736/vignettes/use.Rmd about launching R in GRASS / GRASS in R, there's also need for a vignette describing the data input/output and execGRASS() functions.
• The package Description could be improved a bit.

Also pinging @neteler, @wenzeslaus, @petrasovaa, @micha-silver

[hellik]

Decision has not been taken about which one, but some obvious possibilities are:

    [rspatial](https://github.com/rspatial) (administered by @rhijmans):
        because terra, the current preferred rgrass workhorse for R object transfer to/from GRASS database, is hosted there.
        but has only one member
    [r-spatial](https://github.com/r-spatial) (administered by @edzer):
        19 members
        also hosts the QGIS-R interface package qgisprocess
        but does not include terra

I tend to suggest r-spatial as QGIS-R interface is already there and raising awareness of each other R interfaces and finding synergies in delevoping and maintaining are important, e.g. regarding MS windows operating systems flaws ....

[hellik]

as a side note, Windows batchfiles for use with R are living in the winGRASS code. the functionality of these batch files is simply to find installed R in windows and add it to %PATH% during a winGRASS session. then just type R into the winGRASS console and R is starting within a GRASS session without any further needed user action.

this worked in winGRASS (Osgeo4W and standalone installer) based upon OSGeo4W version 1. Now, since the change to OSGeo4W version 2 as build environment for winGRASS some time ago, these batch files have not been taken over to the OSGeo4W environment.

therefore a revision is needed

• if these batch files are still working?
• if there is a new version of these files?

 * Windows batchfiles for use with R / (GNU GPL v2)
   http://code.google.com/p/batchfiles/
   https://github.com/ggrothendieck/batchfiles (new code repository)

• if and, when yes, how should these batch files be used in the new GRASS-R-interface in winGRASS

[florisvdh]

During the upcoming GRASS GIS community meeting 2024, beginning end of this week, I'd like to contribute to (re-)implementing the GDAL-GRASS GIS driver and to the idea of user-friendly wrappers. For the latter, see issue #89.