About the future of rgee

[Cidree]

Dear Cesar,

I write this issue based on your answer to #355. Could you please describe your thoughts about the future of rgee?

I understand that maintaining a package like rgee can be painful and time-consuming. For earth observation engineers or similars, using Google Earth Engine is essential nowadays, and the rgee package is amazing for people who use mainly R. However, if rgee won't be maintained in the future I suppose we'll need to migrate back to the JaviScript API or geemap in Python for future projects.

Best regards,
Cidre

[rion-saeon]

@Cidree Cesar has given an elaborate comment about its future. There are also workarounds provided below his comment that you should attempt. I don't think it warrants opening another issue like this. Please consider closing this.

[csaybar]

Hi @Cidree, thanks for opening this post. I think I can express my ideas more clearly here, and other users can also share ideas on this issue. As I mentioned in #355, rgee has gone through many changes since we started in 2021. While much of the rgee code can be reused for a new API for R, the main challenge for me is creating a stable API that is easy to maintain over time.

Here are a few challenges/problems I encounter:

Retrieve data using gee is weird

Sorry to say this, but the GEE API is poorly designed, and there seems to be no intention to improve it. GEE refuses to adopt the STAC standard and creates weird methods like ee.data.getPixels and others in ee.data.* . Many users, myself included, don't want to use its platform for analysis. We just need a fast and straightforward endpoint to access the data. This is something that other providers like Microsoft (Planetary Computer) understood from the start and adopted STAC very early.

I'm bringing this up because now that there are six different ways to download data (getInfo, Export.image.toDrive, Export.image.toGCS, ee.data.getPixels, ee.data.computePixels, ee.data.getDownloadId), which method should be the default in ee_as_star, ee_as_terra, etc.? ee_as_terra, ee_as_star, ee_as_sf, and similar functions were created when the only "for free" way to get data was by transferring data from GEE to Google Drive and then to your local system. If GEE improves its accessibility, we should only need rstac to access GEE data.

I don't understand ee.Authenticate

The most common issue reported by users in Python and R was related to Authentification. rgee was created when ee.Authenticate didn't exist. Now, there are five different ways to authenticate (localhost, Colab, gcloud, notebook, gcloud-legacy, https://developers.google.com/earth-engine/guides/auth), which is quite overwhelming. I don't like comparison, but with the Planetary Computer, authentication is unnecessary. Just enter and get the data.

Many of the GEE authentication methods are intrusive and require users to create a Google Cloud Platform account. There must be valid reasons for this, which I may not understand, but I feel uncomfortable contributing to this becoming the standard.

The API is in active development, and users should expect the API to change

This is the first line you will see when visiting the GitHub GEE repository. GEE's future direction is unconfident; breaking and creating new stuff is the standard. Just to give an example, in the Python ecosystem, geemap has always been the go-to package for creating webmaps. However, suddenly, the GEE team decided to create earthengine-jupyter with the apparent intention of replacing it. The package didn't catch on, so they started working with the geemap author. My point here is that GEE is quite unpredictable. You can put a lot of effort into building an R, Julia, or Python package, and in the next #GeoForGood, they can release something that replaces you.

Final words

I personally disagree with the recent direction taken by GEE API. I still use GEE, but less every day. rgee needs a significant redesign (rgee2). I don't have much time (I started the Ph.D.) and don't intend to keep maintaining rgee, so probably the best is to archive the repository. Deeply sorry for the inconvenience.

If anyone is interested in creating rgee2, I can help migrate the code from rgee. I would start by defining a clear API that is as non-invasive as possible. Installation and authentication should be handled externally to rgee2, leaving users to manage these aspects themselves (like eemont).

[Cidree]

Thank you very much for your response!

It's a pity that the design of GEE has so many uncertainties. However, thank you very much for creating this package and making it so useful for these years. Wish you good luck with your PhD and future projects!