Try   HackMD

Below text is going to be posted as a GitHub discussion on the rgrass repo.

Meeting minutes on interfacing GRASS from R

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

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 saves 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 with stars
    • remote GRASS data with gdalcubes.
      (unsure whether that is an accurate description of the discussion!) - Vero: I believe the latter 2 where framed like open questions rather than statements

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

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

Last changed by 
 
florisvdh
0
97
Published on HackMD