geocompx / geocompr

Geocomputation with R: an open source book
https://r.geocompx.org/
Other
1.55k stars 583 forks source link

GIS bridges #756

Closed Nowosad closed 2 years ago

Nowosad commented 2 years ago

I mentioned this idea on Discord, but we should make a decision about it in the near future.

In the 1st edition of the book, GIS bridges were represented by RQIS (retired), RSAGA (retired/superseded by Rsagacmd), and rgrass7 (now rgrass; not supporting terra yet).

What do you think about:

a) showing examples using qgisprocess (including calling GRASS and SAGA with qgisprocess) b) mentioning other possible bridges, but without a lot of a code (or not at all) -- Rsagacmd, rgrass, whitebox?

@Robinlovelace @jannes-m

Robinlovelace commented 2 years ago

I think we've discussed some of these ideas in #519 but good to revisit them. I think a) and b) sound good. As with the visualisation chapter, there is value in doing a deep dive into one package.

jannes-m commented 2 years ago

We should keep in mind that:

  1. Geocompr is the only place where one can find an (almost) comprehensive introduction to GIS bridges.
  2. QGIS lets the user only access a subset of SAGA and GRASS functions
  3. there is not much value in showing how to call SAGA or GRASS algorithms with qgisprocess since it is exactly the same as accessing any other geoalgorithm
  4. It shouldn't be too much effort to rewrite the SAGA and GRASS parts.

That being said, we can still strive for condensing the SAGA and GRASS sections. At least in the case of SAGA this should be easily possible. Regarding GRASS, we could of course use a simpler example than the traveling salesman problem. But back then, the reviewers asked us to choose interesting problems which one cannot do with R packages or other GIS systems. In any case, we can come up with another interesting GRASS example which is shorter.

gisma commented 2 years ago

As you might imagine, I find the chapter compelling and good. However, it should not be forgotten that the topic of "briding" with its fast-moving nature with regard to APIs/interfaces and third-party software is very demanding and difficult to classify, especially for beginners. In addition, it is an ongoing issue for the maintenance/development of wrapper packages and not always successful as we have seen in recent years. And last but not least, the R-generic packages are also making up ground.

Therefore, I think it would make sense to integrate the qgis_process approach in more detail, precisely because it serves large parts of the leading GI software, even if GRASS, SAGA and GDAL are only partially covered. Here the API concept is quite clear and the uniform interface is likely to remain stable for a while and is therefore highly effective.

Then, depending on the interest, short crisp examples that compellingly document the usefulness of leading and mature packages such as GRASS, SAGA, Whitebox, (depending on how fancy and useful the example and used software is), on the basis of a small use case.

Perhaps there is also the possibility of including external packages in more detail under the case studies?

Nowosad commented 2 years ago

Thanks for the discussion. You can find rewritten GIS bridges chapter at https://geocompr.robinlovelace.net/gis.html. Any comments/suggestions are welcomed at https://github.com/Robinlovelace/geocompr/issues/881.