geocompr
geocompr copied to clipboard
New section on rgee
Split out from #519.
I've rarely used {rgee} and think that's also the case for @Nowosad and @jannes-m (right?). Any rgee users out there your input + ideas are v. welcome!
Hi, @Robinlovelace . I'd love to collaborate on this section with @csaybar and @junior0428. In fact, we had already begun to write something. For chapter 10 ("Bridges to GIS software"), we want to include a section titled "Google Earth Engine through rgee".
we plan to structure the section as follows:
- What is Google Earth Engine?
- What exactly is rgee?
- Why rgee over Javascript or Python client libraries?
- how to set up rgee
- Integration of rgee with the r-spatial packages
- Application: Monitoring NO2 emissions in major cities across the world.
Besides, we also plan to modify section 10.5 (When to use what?) to include rgee. Are we missing something? Please let us know what you think!
I'd love to collaborate on this section with @csaybar and @junior0428. In fact, we had already begun to write something. For chapter 10 ("Bridges to GIS software"), we want to include a section titled "Google Earth Engine through rgee".
all this sounds good to me, GEE is clearly future proof and in demand so I think a decent sized section on the topic is justified. I would suggest keeping the content minimal in the first instance: maybe a link to the application section would be better than including a detailed worked example? Good idea to modify Section 10.5 also. Overall I really like to look of the structure and look forward to giving the code a spin, perhaps during review of this content!
Note: @jannes-m who led the chapter and @Nowosad may also have suggestions but from my perspective it sounds like all the components are in place for work on this issue to begin :building_construction:
I second what @Robinlovelace said -- this new section would be great to have. We would need to decide on its length at some time (and then we could either decide to keep it all in the book, or move some parts to an external document). I would also be happy to review your work when it is ready (PR would be great).
First of all, thanks for your initiative. A few things came to my mind:
- Though the Google Earth Engine is great, it is closed source which (from an R perspective) led to the development of openEO and stars. Therefore, when writing about rgee, we probably should also add a section on openEO. What do you think? Though I have to admit I haven't used either so far...
- In a broader sense, one could view cloud computing on raster data (not sure if vector stuff is also supported) as a bridge to spatial software (maybe not to GIS, since by definition a GIS is a system for manipulating, analyzing and visualizing geographic data, and in any case somehow reserved for QGIS, ArcGIS, SAGA, etc.). Hence, either we rename the chapter to bridges to spatial software (or alike) or we split out the cloud-computing stuff which in any case is still a missing topic in the book. First option would be fine by me, since a bridge to spatial databases (PostGIS) and to command-line tools like gdal, which are already subchapters, aren't bridges to GIS software either.
Good points Jannes and yes, it may be worth at some point splitting-out the content into another chapter named 'Bridges to cloud-based geographic platforms'. Before we have section on openEO this chapter is good enough for now and we could rename it to 'Bridges to GIS software and the cloud' or similar... How best to proceed will become clear as the content emerges. Any further views welcome but for now it is fine for this content to be a section around here https://github.com/Robinlovelace/geocompr/blob/main/10-gis.Rmd#L581 - Thinking this may be better in the Other bridges section than as a section before 10.5.
Looking at the structure of the chapter again, it's already about more than just bridges to GIS software (GDAL being a library).
As with #741 we can rearrange things post merge also.
Thanks for the discussion, guys. My thinking would be:
- Keep one chapter -- and rename it into "Bridges to spatial software"
- We definitely should (at least) mention openEO. If we have time/experience/etc. we could think about adding a section about it.
I think the renaming makes perfect sense. The era of "desktop GIS" is not yet over, but without cloud computing there is no serious future, especially in the spatiotemporally oriented scientific field. I think the initiative with rgee makes a lot of sense and I expressly welcome it.
Nevertheless, I support @jannes-m position that openEO and stars and, in my view, the STAC and COG concepts (e.g. via gdalcubes) must be mentioned at least structurally. Not only because these are also powerful cloud offerings but also because for me the concept and feature of R par excellence is to support open access, which however absolutely does not mean that interfaces to closed source solutions should not also be supported.
According to the question who could do it: Maybe someone could ask sombody from Edzers group? For instant Marius Appel @appelmar to write a short article about this?
Thanks for thinking of me @gisma. I'd be very happy to contribute a section on openEO, STAC, COG, and gdalcubes. I think it would make sense to split this up into two separate (sub)sections because the openEO and STAC + COG + gdalcubes approaches are quite different (using existing cloud services vs. running a machine on your own). Maybe at a later stage, the sections could be combined with the rgee section into one larger cloud computing section / chapter.
For example, I could cover the following content (just initial ideas..):
-
Interoperable cloud-based Earth observation data analysis with openEO
- What is openEO?
- Existing backends
- Data cubes and processes
- The openEO R package
-
Using STAC and COGs for R-spatial workflows in the cloud
- (How to run R / Rstudio in the cloud)
- What is STAC?
- The rstac package
- What are COGs?
- From image collections to data cubes with the gdalcubes R package
Please let me know, which parts might be of interest to the chapter and what length you would consider as appropriate.
I moved the openEO, STAC, COG, and gdalcubes discussion to https://github.com/Robinlovelace/geocompr/issues/755.