Interfacing QGIS from R

[florisvdh]

Currently we have two very functional R packages:

• qgisprocess, providing qgis_run_algorithm() and a number of associated functions, in order to run QGIS algorithms and interface with R objects.
• qgis, building on top of qgisprocess and providing a wrapper function around qgis_run_algorithm() for each algorithm, e.g. qgis_buffer(), including R documentation for these hundreds of functions.

Both packages are very valuable, and the second depends on the first. Also, different users may prefer just one of both approaches, and many users run the risk of not knowing about both packages.

Given the limited strain on the system to have both packages loaded (cf. JanCaha/r_package_qgis#32), it may be an interesting idea to provide a single package to access all functions, so that users don't need to bother.

• literally merging both into one package seems not feasible; the number of *.R and *.Rd files in qgis (automatically generated) is extremely large and would drown the other functions, also e.g. in the documentation (pkg index, website).
• which leads me to the idea of a metapackage – just following along the lines of tidyverse here. Imagine something like (this is manually crafted output - there's no such package!!):

> library(rqgis)
── Attaching packages ───────────────────────────────────────────── rqgis 0.1.0 ──
✔ qgisprocess 0.2.0
Attempting to load the cache ... Success!
QGIS version: 3.28.3-Firenze
Having access to 785 algorithms from 9 QGIS processing providers.
Run `qgis_configure(use_cached_data = TRUE)` to reload cache and get more details.
✔ qgiswrap    3.28.3

The namespace of tidyverse is very limited; attaching the packages is just defined in .onAttach(). So that would also apply here.

What do you think @paleolimbot @JanCaha @jannes-m @Robinlovelace @Nowosad, others?

Some thought is also needed about package names. @JanCaha perhaps qgis or rqgis (as in the above example) is more ideal as the metapackage name then. For now I used a name qgiswrap to represent your package but of course it's up to you to consider, please share your thoughts on this. qgis has the disadvantage that the reponame cannot be named as such when also a fork of QGIS is present as a repo with the name QGIS.

Perhaps all three could use the same hexagon sticker background as qgisprocess, with just a different name at the bottom 🙂.

[paleolimbot]

I personally wouldn't bother with a metapackage...plenty of code to maintain already!

[jannes-m]

I agree with @paleolimbot. Pointing prominently to the other package on the github landing pages might also help to raise awareness of the different r-gis interfaces.

[JanCaha]

I also dont see that much point in the metapackage. qgis cannot work without qgisprocess and it is quite unlikely that user will want both packages at the same time. I believe that either you want the flexibility of qgisprocess or you want to mirror QGIS calls as closely as possible (which you would do by calling functions from qgis package).

I see a strict dependance between the packages, not these packages work in similar manner relationship.

[florisvdh]

Thanks for explaining your views on this! I'm probably one of those users that want it all 😉, but that may be an edge case. I'll store this idea in the freezer.

Anyway it's a good idea to refer from one package to the other and vice-versa, in the package documentation and the repo's readme, as @jannes-m suggests.

I'll let this issue open, mainly to remind that we should implement such referencing, and perhaps more ideas will follow.

[Robinlovelace]

👍 to cross-referencing between the two. When that's done, with reference to key differences, this issue can be closed. Typically I'd offer to give this a go but super busy atm alas.