Bridges to GIS software - What about system calls to CLI?

[gisma]

I am not sure about your timeline neither if you are interested in this topic. Nevertheless I would like to state that bridging R to GIS, in addition to the great wrappers, also means mentioning the connection via system calls. Especially the "chaotic" and barely comprehensible situation of the SAGA development makes it almost impossible to use RSAGA for higher versions than the recommended ones. What means that if you would like to use the newer developments one has to to the cumbersome job to adapt again and again the wrapper or use stable system calls to the binaries. Even more other tools like Orfeo Toolbox or numerous other powerful tools are lacking even this kind of wrapper support. I have to admit that it would be very worthy to write theses wrappers but from a developers point of view I prefer prefer using system calls to get what I am looking for. Do you think that it is worthwhile to add a sub section like "bridging R via system calls" ?

[Robinlovelace]

I would say so. It can be very useful to know you have access to the system for certain less common commands. The simple request illustrated below has an equivalent in sf but there are certainly cases where the various R wrappers cannot keep-up and system() may help. I know @mdsumner and all of the other authors have thought about this probably more than me but from my perspective: great idea!

d = system.file(package = "spData", "shapes/")
(f = list.files(d, full.names = TRUE, pattern = ".shp"))
#> [1] "/home/robin/R/x86_64-pc-linux-gnu-library/3.4/spData/shapes//auckland.shp"     
#> [2] "/home/robin/R/x86_64-pc-linux-gnu-library/3.4/spData/shapes//baltim.shp"       
#> [3] "/home/robin/R/x86_64-pc-linux-gnu-library/3.4/spData/shapes//boston_tracts.shp"
#> [4] "/home/robin/R/x86_64-pc-linux-gnu-library/3.4/spData/shapes//columbus.shp"     
#> [5] "/home/robin/R/x86_64-pc-linux-gnu-library/3.4/spData/shapes//eire.shp"         
#> [6] "/home/robin/R/x86_64-pc-linux-gnu-library/3.4/spData/shapes//NY8_utm18.shp"    
#> [7] "/home/robin/R/x86_64-pc-linux-gnu-library/3.4/spData/shapes//sids.shp"         
#> [8] "/home/robin/R/x86_64-pc-linux-gnu-library/3.4/spData/shapes//wheat.shp"        
#> [9] "/home/robin/R/x86_64-pc-linux-gnu-library/3.4/spData/shapes//world.shp"
msg = paste("ogrinfo", f[1])
res = system(msg, intern = TRUE)
res
#> [1] "INFO: Open of `/home/robin/R/x86_64-pc-linux-gnu-library/3.4/spData/shapes//auckland.shp'"
#> [2] "      using driver `ESRI Shapefile' successful."                                          
#> [3] "1: auckland (Polygon)"
sf::st_layers(f[1])
#> Driver: ESRI Shapefile 
#> Available layers:
#>   layer_name geometry_type features fields
#> 1   auckland       Polygon      167      4

[jannes-m]

Hey Chris, pls note that RSAGA will be updated soon on CRAN, and then it will support all SAGA versions up to SAGA 6 (I think). Of course, you are right, that the command-line is extremely useful for accessing geo-software from within R (this is exactly what RSAGA is doing as you know). OTB, TauDEM and LiDAR could be accessed though QGIS until version 2.18, with QGIS 3 they will stop supporting these third-party providers or at least they are no longer available through processing. In general, I think a section on system calls would be an interesting addition, however, we are already fighting with space constraints. But maybe we could add a tiny section on this in the R-GIS bridges chapter as an outlook, e.g., how to access geo-software (SAGA, GDAL) via system(). And then we could point to your material and Tom Hengl's book (I remember vaguely that he used the cl through R a lot).

[gisma]

Great, sounds good to me - finally semester classes are over and at last I have some time left over for supporting your great project... I would offer to write a a mini-section about this topic as a draft if mid of February is early enough for this.

[gisma]

Back again to this topic I must admit that up to your answer I have ignored the roadmap and developer discussion of the QGIS 3.x roadmap. Diving into it as far as I have got it, they are going to move all the messy provider algorithm into a seperate plugin approach (if any user will support it). If so, will you cover the new plugin structure with RQGIS? I am just thinking about it because on the one hand, writing about command line interfacing could help the reader to be aware that there is an direct way to deal with all these kind of obstructions (and maybe to enable them to overcome this unlucky situation) on the other hand this seems to me pretty advanced and maybe out of topic. Opinions? cheers Chris

[jannes-m]

The main priority of RQGIS will be to support the processing plugin which will give access to QGIS, SAGA and GRASS7 geoalgorithms. This already will require some time and effort. Not sure, if I really want to support more than that, depends... In any case, as I have said earlier, I think a gentle introduction how to use GDAL from within R via the command-line would round the R-GIS bridges chapter along with the remark that this is also possible with TauDEM, SAGA and other GIS software.

[gisma]

Ok understand this. Have prepared this so far . Additionally I was thinking to give the non wrapped part of geoPAT2.0 a glimpse maybe with a straightforward analysis of the http://doi.pangaea.de/10.1594/PANGAEA.845883 datasets. 5 lines of code and a complex analysis via CLI to LGM climate patterns. But nevertheless give me a hint, as far as I catch the discussion also SAGA and GRASS are candidates to be removed from processing if they do not meet the interfacing design?

[Nowosad]

(@gisma - feel free to let me know if you have any questions about GeoPAT 2.0 - nowosad.jakub at gmail.com)

[gisma]

@Nowosad will do so as soon as we are done with the running application review...

[jannes-m]

see subsection https://geocompr.robinlovelace.net/gis.html#a-short-note-on-further-spatial-apis