geetools: method chaining for the Google Earth Engine Python API

The design is a namespace on the Earth Engine objects themselves

Google Earth Engine is a cloud-based service for geospatial processing of vector and raster data, and its platform has a JavaScript and a Python API with different methods for processing geospatial objects. The geetools package extends the Python API with pre-processing and processing tools for the most used satellite platforms, adding utility methods to different Earth Engine objects in a way that is friendly with Python method chaining using the geetools namespace. That last phrase is the whole idea. Rather than a separate helper library that takes an ImageCollection and returns something else, the methods are attached to the objects, so an ee.ImageCollection carries .geetools.closest and .geetools.maskClouds. The goal, as stated, is to make the code more fluid and easy to read for researchers, students and analysts, and new utility methods and constructors are added to most of the GEE classes, sometimes as a simple wrapper for a repetitive task, sometimes as a complex algorithm and sometimes as a mandatory preprocessing step. There is a separate JavaScript module with similar but not exactly the same functions, hosted in the geetools-code-editor repository, so the two ecosystems are related but not interchangeable. The install itself is a single pip command, and the package is also on conda-forge.

    pip install geetools

The documentation site is geetools.readthedocs.io.

Five lines instead of a preprocessing script

The readme gives a concrete example, wrapping the functionalities of the ee_extra package to preprocess Sentinel 2 data in five lines of code. The chain is the interesting part, because each step is labelled as either extended pre-processing or extended processing.

   import ee
   import geetools #noqa: F401
   import pygaul # another gee-community package to access FAO GAUl 2015 dataset

   # we assume you are already authenticated to GEE
   ee.Initialize.geetools.from_user() # yes we also support multi users

   amazonas = pygaul.Items(name="Amazonas").centroid()

   S2 = (
      ee.ImageCollection('COPERNICUS/S2_SR')
      .filterBounds(point)
      .geetools.closest('2020-10-15') # Extended (pre-processing)
      .geetools.maskClouds(prob = 70) # Extended (pre-processing)
      .geetools.scaleAndOffset() # Extended (pre-processing)
      .geetools.spectralIndices(['NDVI','NDWI','BAIS2'])) # Extended (processing)

Two details are worth pulling out. The import of geetools is marked as not needed with a noqa comment, which tells you the library installs itself onto the Earth Engine classes when imported, so the import is a side effect rather than a namespace you use directly. And ee.Initialize.geetools.from_user() is the authentication entry point, with a comment pointing out that multi-user setups are supported, so the library is not limited to a single hardcoded account.

Server-side computation is what makes it usable commercially

The package design is mostly performing server-side computation, and the readme says that makes it also very friendly with commercial users of Earth Engine. That is a meaningful constraint rather than a marketing line. A method like maskClouds with a probability threshold of 70 has to run somewhere, and running it on Earth Engine means the pixels never leave the platform and the cost lands on the account that owns the collection. A local implementation of the same steps would need the data downloaded, and for a Sentinel 2 time series over a region that is a very different cost profile. It also means the methods are not usable outside Earth Engine, since a geetools method that returns an ee object is only meaningful in that context. The dependency list shows the local side of the library, with pandas, geopandas and matplotlib for anything that does need to run on your machine, and the xee package at 0.1.0 or newer described in a comment as a change API prototype for geometry setting.

A conventional package with a wide test and docs toolchain

The badges at the top of the readme describe a well-equipped project. The licence is MIT, the commits follow Conventional Commits 1.0.0, the code style is Black with Prettier also in the loop, and there is a pre-commit setup. It is published on PyPI and on conda-forge, with a separate conda-forge feedstock repository, and the build and coverage badges point at a GitHub Actions unit workflow and a Codecov report. The documentation is on readthedocs with a Sphinx stack that includes pydata-sphinx-theme, sphinx-design, sphinx-autoapi, myst-nb and jupyter-sphinx, and the manifest lists optional dependency groups for dev, test and doc. The test group is the most interesting one, because it includes pytest-gee at 0.6.0 or newer to get the serialized regressions, plus pytest-regressions and pytest-deadfixtures, which tells you the project tests against recorded Earth Engine outputs rather than only unit-level mocks. The dev group is pre-commit, nox and commitizen, and the repository has a noxfile.py, a notebooks directory, a .devcontainer directory and an AUTHORS.rst.

The dependency analysis script points at a wider ecosystem

Two files at the top of the tree are unusual enough to be worth a mention. There is analyze_ee_extra_dependencies.py and, next to it, ee_extra_dependencies.txt, and together they say that the project tracks and analyses the dependencies of the ee_extra package rather than treating it as an opaque black box. The readme presents geetools as wrapping the excellent ee_extra package functionalities, and having a script that analyses those dependencies in the repository suggests the relationship is actively maintained rather than assumed. The docs directory, the geetools package directory and the tests directory complete the picture of a package that is small in concept and wide in surface area, because the surface area comes from the number of Earth Engine classes the methods attach to. The project is MIT licensed with the licence text in a LICENSE file, the primary language is Python, and the recent releases are v1.18.2 from 2026-07-16, v1.18.1 from 2026-01-30 and v1.18.0 from 2026-01-28, with the last push to the repository on 2026-10-21.

Editorial conclusion

geetools fits a remote sensing researcher, student or analyst who already uses the Earth Engine Python API and wants the repetitive preprocessing steps expressed as one readable chain, since the methods attach to the Earth Engine objects themselves rather than to a separate helper layer. It does not fit a JavaScript user, because the equivalent module has similar but not identical functions and lives in a different repository, and it does not fit someone who needs the same processing in a local environment, because the design is mostly server-side computation on Earth Engine infrastructure. Before you adopt it, check the supported Python versions, which the manifest lists as 3.10 through 3.13, and read the documentation for the specific satellite you are working with, because the extended methods are platform specific and the multi-user authentication path through from_user is a different setup from a single-account script.

Frequently asked questions

Official sources

1. gee-community/geetools on GitHub
2. License: MIT
3. Project website
4. README
5. Releases