rgee: Calling Google Earth Engine From R

Google ships two clients, rgee supplies the third

Google Earth Engine is a cloud-based platform that lets users access a petabyte-scale archive of remote sensing data and conduct geospatial analysis on Google's infrastructure. Google currently offers support only for Python and JavaScript, and rgee fills that gap by providing support for R. It is an R binding package for calling the Earth Engine API from within R, with various functions implemented to simplify the connection with the R spatial ecosystem. That last clause is the important one. A binding is the easy part; the functions exist so that the result feels like an R package rather than a foreign function call with an R wrapper, and the sibling projects linked in the header, rgeeExtra for extra functions and an R geocomputation book, are where that ecosystem work continues.

The same three lines in three languages

The readme puts the three client libraries side by side, and the comparison is the clearest argument for the package. The JavaScript version declares a database identifier, builds an image and prints the band names, the Python version initialises the session first and then calls getInfo, and the R version uses the dollar sign for method calls.

``` r library(rgee) ee_Initialize(project = "my-project-id") db <- 'CGIAR/SRTM90_V4' image <- ee$Image(db) image$bandNames()$getInfo() #> [1] "elevation" ```

The readme's verdict on that comparison is that the syntax is quite similar, and then adds the caveat that additional more minor changes should be considered when using Earth Engine with R, pointing to a consideration section before you start coding. That is the honest framing: the shape of the code transfers, but there are specific places where it does not, and the package documents them separately rather than pretending they do not exist.

Authentication goes through the Google Cloud CLI

Setting up a session takes three steps, and the documentation recommends putting them in a .Renviron file so you do not set them every time you authenticate. You point reticulate at a Python interpreter, set the Google Cloud SDK path, then authenticate and initialise.

``` r library(rgee)

# Set your Python ENV Sys.setenv("RETICULATE_PYTHON" = "/usr/bin/python3")

# Set Google Cloud SDK. Only need it the first time you log in. Sys.setenv("EARTHENGINE_GCLOUD" = "home/csaybar/google-cloud-sdk/bin/") ee_Authenticate()

# Initialize your Earth Engine Session ee_Initialize(project = "my-project-id") ```

You need to create and register a Google Cloud project to use Earth Engine through rgee, and its ID has to be supplied to ee_Initialize each time you start a new session. The project ID is a hard requirement rather than an optional extra, which is worth knowing before you plan an analysis. The Python interpreter matters too, because the calls run through the official earthengine-api package, and reticulate is the bridge that makes that work from R.

Installing from CRAN and from GitHub

The stable install is one line.

``` r install.packages("rgee")

The development version comes from GitHub through the remotes package.

r library(remotes) install_github("r-spatial/rgee") ```

The dependencies matter more than the install command. rgee depends on numpy and the earthengine-api package, and it requires the gcloud CLI to authenticate new users. The documented walkthrough for a new Ubuntu machine goes further and installs miniconda through reticulate, and it points server users at a separate RStudio Cloud example. The R version of the Earth Engine client is therefore a package with an unusual dependency profile: a Python environment and a Google Cloud command line tool have to be in place before any of it runs, which is the main thing to sort out before you start.

An R package with the usual shape

The repository is laid out as a standard R package, with DESCRIPTION, NAMESPACE, an R directory for the code, man and man-roxygen for the generated and template documentation, tests, vignettes, inst, and a pkgdown directory for the site. There is a paper directory and a CITATION.cff file, which is why the readme has a citation section, along with a Zenodo DOI badge so the package has an archived identifier. The vignettes are where the considered usage notes live, including the consideration section the readme refers to. Development tooling is present too, with a codecov configuration, a cran-comments file and an Rbuildignore file. The project also carries a CODE_OF_CONDUCT.md and a CONTRIBUTING.md, and the badges show a JOSS paper, a CRAN listing and a lifecycle badge marking the package as maturing.

Maintenance, and the version question for CRAN users

The release record is the one thing a new user should check, and it is worth being blunt about. The most recent tagged release is v1.1.3 from 2022-03-14, preceded by v1.1.2 in September 2021 and v1.1.0 in August 2021. The repository is not archived and the last push was on 2026-10-19, so the code is being worked on, but the CRAN version is considerably older than the repository state. The distinction is the usual one for an R package with a dependency on a fast-moving upstream API. The Earth Engine Python client changes, and the CRAN copy of rgee is what a plain install.packages call gives you. If you need behaviour that matches the current repository, the GitHub install is the one that gets it, at the cost of skipping the CRAN review.

Licence, community and what the sibling packages add

The licence needs a small note. The readme carries an Apache 2.0 badge and the repository has a LICENSE.md file, while the licence entry in the repository metadata is recorded as a custom one that GitHub cannot classify, so the file itself is the reference. The project links a Buy Me a Coffee page, and the header links two related projects: rgeeExtra, which provides extra functions for working with Earth Engine in R, and an R geocomputation book at r-earthengine.com. Those two are where the answer to most practical questions sits, because a binding package cannot cover every pattern and the ecosystem around it is where the patterns get written down. For a first run, the practical sequence is: create the Cloud project, get the gcloud CLI and a Python environment in place, install rgee, and then work through the vignette on Earth Engine initialization before writing any analysis of your own.

Editorial conclusion

rgee fits a spatial analyst who already works in R and needs the Earth Engine catalogue of imagery and analysis, and who is prepared to manage a Python environment alongside it. It is the wrong choice if you want a pure R implementation, since the package routes calls through the Python client, and the wrong choice if you cannot create a Google Cloud project, since one is required for authentication. Before you build a script on it, read the consideration section, which lists the places where the R syntax departs from the other two clients.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. r-spatial/rgee on GitHub