Update GIS bridges chapter

[Robinlovelace]

• [x] No longer depend on RQGIS for book build
• [x] Purge RQGIS code from chapter
• [x] ~~Explain how to use qgis_process from system~~
• [ ] rgee section
• [ ] sf::gdal_utils()
• [ ] More on gdalUtils - e.g. with different versions via Docker?
• [ ] Something on Whitebox
• [x] ~~Something on Reticulate?~~

https://cran.r-project.org/web/packages/RQGIS/index.html

I've just tried to build the book without RQGIS and only 2 chapters are affects. Looking at fixes now...

[Robinlovelace]

Looking for a hotfix in https://github.com/Robinlovelace/geocompr/pull/520

[Robinlovelace]

Update: this is harder than initially anticipated and I'm not sure #520 is the best approach...

[Robinlovelace]

Update: triggering build after https://github.com/geocompr/geocompkg/commit/57e159e059190943d7fb447edd81fb9d8909c079 - hoping that will at least fix the build. Wider issue is how to provide futureproof info on RQGIS. I suggest asking for support with RQGIS3 on the r-spatial discuss repo and in the wider community.

[jannes-m]

I think the easiest solution would be to use devtools::install_version("RQGIS", version = "1.0.4") . What also should work is install.packages("https://cran.r-project.org/src/contrib/Archive/RQGIS/RQGIS_1.0.4.tar.gz", repos = NULL, type = "source")

[jannes-m]

With regard to RQGIS3 we can of course ask the community for help. Another solution is to simply drop the RQGIS part from the GIS chapter.

[Robinlovelace]

With regard to RQGIS3 we can of course ask the community for help.

How about posting something like this on the r-spatial/discuss issue tracker:

Is anyone interested in developing RQGIS3? The original package RQGIS has been archived due to updates to QGIS and the original creators of the package lack the time, at present, to take the package further on it's journey towards CRAN.

[jannes-m]

And another suggestion: we use RQGIS in most chapters (aside from the GIS chapter) for attaching data shipped with the package. I suggest to move this data to spData.

[jannes-m]

FYI: I just received a message that QGIS will turn away from SAGA as a processing tool, which means that one would need to use RSAGA anyways to access SAGA algorithms from within R.

[Robinlovelace]

I suggest to move this data to spData.

Good plan. I've opened an issue in the spData issue tracker. PRs welcome!

[Nowosad]

Maybe @paleolimbot could be interested in helping with RQGIS3? (Based on his interest at https://twitter.com/paleolimbot/status/1250827448465448966)

[paleolimbot]

Thanks for thinking of me! I'm currently tied up with some other spatial programming projects, but feel free to flag me if there's something specific. It looks like there will be a command-line interface for QGIS in an upcoming version, and I imagine waiting for that is the way to go.

[Robinlovelace]

Very interesting, thanks for the link @paleolimbot. Maybe a new package called qgisprocess is the way forward, based on the thread in that PR on the QGIS GitHub repo. Thoughts @jannes-m ?

[jannes-m]

Interesting, indeed! Calling QGIS via the command line would e.g. solve the RStudio bug issue since one would no longer need Python. One could create a new package in the spirit of rgrass7 and RSAGA but one would need to probably start from scratch. And since the cli version is in development presently, it probably needs also time to mature.

[Robinlovelace]

Great. I imagine data transfer would have to happen by reading and writing to the tempdir, unless there is another way.

[jannes-m]

Yes, that's how we did in RQGIS.

[Robinlovelace]

In the short term I think we can close this issue from the perspective of the book by moving the data packaged in RQGIS into spDataLarge. Are you up for giving that a go @jannes-m ? I the longer term the CLI interface and 'shout out' to ask for support with this options looks promising but that can be for a separate issue.

[jannes-m]

Sorry for the late reply! Sure, I can do that, hopefully within the next week. I am on parental leave right now and on the road with the family 😊

[Robinlovelace]

Fantastic, thanks for the update @jannes-m, enjoy the parental leave!

[mbernasocchi]

FYI: I just received a message that QGIS will turn away from SAGA as a processing tool, which means that one would need to use RSAGA anyways to access SAGA algorithms from within R.

SAGA was never the processing tool. QGIS processing framework merely allows using SAGA as one of the backends (like QGIS native algs, grass, OTB, ...).

The new qgis_process which was added in 3.14 (referenced above) is indeed a standalone tool that allow executing QGIS processing models and algorithms without starting QGIS (desktop) Cheers

[Robinlovelace]

Thanks @mbernasocchi, any ideas how much work that would be to wrap qgis_process from within R? RQGIS3 could be the perfect home for such functionality I guess.

[Robinlovelace]

In collaboration with @jannes-m the following now work:

system("qgis --version")
QGIS 3.16.1-Hannover 'Hannover' (b381a90dca)
## QGIS 3.16.1-Hannover 'Hannover' (b381a90dca)
remotes::install_github("paleolimbot/qgisprocess") # install the latest version of the package
## Skipping install of 'qgisprocess' from a github remote, the SHA1 (6e378511) has not changed since last install.
qgis_algs = qgisprocess::qgis_algorithms()
nrow(qgis_algs)
## [1] 970
table(qgis_algs$provider)

##    3d   gdal grass7 native   qgis   saga 
##     1     55    301    196     51    366 

I think that is everything we need to rewrite the chapter using qgisprocess. I would be nice if that package were on CRAN but not essential.

[jannes-m]

In fact, this was the idea to rewrite the QGIS part using qgisprocess. However, I will have to think of another example since the `qgis:eliminatesliverpolygons' algorithm is no longer available. And yes, I am already using the qgis-ext docker image to write the vignettes for qgisprocess.

[Robinlovelace]

Fantastic. I am working on a .yaml file that should allow the code to run in the new version. will report progress on that in #590. Exciting updates, great to see how this could work out really nicely. If you need another example, I found an algorithm unavailable anywhere else that seemed to run ~100 times faster than in R: https://github.com/paleolimbot/qgisprocess/issues/26

[jannes-m]

Good idea, and in any case worth to mention in the book as a real world example. Still I will look for a qgis native algorithm which is doing something which can't be done in R. This was one of the suggestions of the reviewers last time. But if there isn't anything we can take your use case. BTW, the same speed gains can be also seen for intersection stuff.

[Robinlovelace]

Just as a test, could you put in a PR that uses qgisprocess @jannes-m? Guess: it will fail on all tests except the qgis-ext action. No rush of course but curious to see if it works. Will be so cool to have the results of that chapter autodeployed using CI/CD.

[jannes-m]

Sure, the PR can serve a the start of rewriting the r-gis bridges chapter.

[Robinlovelace]

Closing because it's supersceded: #756