_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](https://grasswiki.osgeo.org/wiki/GRASS_Community_Meeting_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`](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**

### 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: https://github.com/OSGeo/grass-website/pull/370.
- At least the [**openSTARS**](https://github.com/MiKatt/openSTARS) package has not yet taken steps to migrate to **rgrass**. Contact with @MiKatt was tried by email and [in GitHub](https://github.com/MiKatt/openSTARS/issues/35); 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](https://github.com/rsbivand/rgrass/issues/75) 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](https://github.com/OSGeo/gdal-grass) 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](https://rsbivand.github.io/rgrass/articles/coerce.html) 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**](https://cran.r-project.org/web/packages/XML/index.html) package is currently used to parse the XML string returned from GRASS modules called with the `--interface-description` flag (see [vignette](https://rsbivand.github.io/rgrass/articles/use.html) about launching R in GRASS / GRASS in R). But the package is currently less popular and maintained than the [**xml2**](https://xml2.r-lib.org/) 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 the `execGRASS()` functions.
- The package Description could be improved a bit.

_Also pinging @neteler, @wenzeslaus, @petrasovaa, @micha-silver_