qgis-earthengine-plugin: pulling Google Earth Engine into QGIS

What the plugin is, and which QGIS versions it covers

The QGIS Earth Engine Plugin integrates Google Earth Engine with QGIS using the EE Python API, and the compatibility line at the top of the README is the most practical sentence in the document: QGIS 3.34 and later with Qt5 and PyQt5, and QGIS 4.x with Qt6 and PyQt6.

That compatibility statement covers two generations of Qt at once, which is unusual and tells you something about the effort involved. A QGIS plugin is a Python package that QGIS loads into its own process, so it inherits the interpreter and the Qt binding that QGIS was built against. Supporting both means the plugin has to work with the older PyQt5 world and the newer PyQt6 one, and the plugin author has to keep both paths working as QGIS itself moves.

The primary language is Python, the licence is MIT, the default branch is main, and the homepage is the documentation site at gee-community.github.io/qgis-earthengine-plugin. The recent releases are v0.3.3 from 2026-08-25, v0.3.2 and v0.3.1 from 2026-08-14, so the version is on 0.3 with a fairly quick release rhythm in the summer of 2026. The last push was on 2026-08-25 with the project not archived.

The 0.x version is worth noting against that cadence. It suggests the plugin is usable and maintained, and that the author is not yet prepared to call the interface stable. For a plugin that lives inside somebody's QGIS installation and is updated through the QGIS plugin manager, a 0.x version is a reasonable place to be while the API around Earth Engine itself keeps moving.

The community around it is organised in the open. There is a user guide, a troubleshooting page, a Discussions section for questions and support, and an issue tracker. The troubleshooting page as a separate document is a good sign, since most plugin documentation lumps the problems into the issue tracker and the useful answers get lost there.

The requirements file, and the Python version split

The requirements file is short and every line of it is worth reading, because the interesting decision is in the environment markers.

# Pin the Earth Engine API so vendored extlibs and runtime installs stay aligned.
# earthengine-api 1.7.x requires Python >=3.10. Older QGIS-bundled Python
# environments should stay on the newest 1.6.x release.
earthengine-api==1.6.15; python_version < "3.10"
earthengine-api==1.7.24; python_version >= "3.10"
google-auth<2.41
httplib2
requests>2.4

Two different versions of the Earth Engine API are pinned, selected by the Python version in use. The comment above them explains the reasoning: the Earth Engine API 1.7.x requires Python 3.10 or newer, and older QGIS-bundled Python environments should stay on the newest 1.6.x release.

That is a real constraint and a sensible accommodation. A QGIS plugin does not bring its own interpreter, it runs inside the one QGIS ships or that the user installed for QGIS, and a QGIS build tied to an older Python cannot install the newer Earth Engine client. So the plugin installs a different version of the client depending on what it finds.

The mechanism is the standard environment marker syntax, the python_version comparison, so pip resolves it automatically rather than the plugin inspecting the interpreter at runtime. That is the right way to do it, since the resolution happens once at install time and the requirement list stays declarative.

The pin itself is exact, 1.6.15 and 1.7.24, with no range. A QGIS plugin that installs through the plugin manager cannot rely on being able to resolve a range, because the manager hands the package to pip inside an environment it does not fully control, and a range that resolves differently on two machines is a bug report waiting to happen.

The rest of the list is the Earth Engine client's own dependency set declared explicitly: google-auth below 2.41, httplib2, and requests above 2.4. Declaring them rather than inheriting them is a little unusual, and the probable reason is that the vendored libraries shipped inside the QGIS environment, the extlibs mentioned in the comment, can otherwise cause a mismatch between what the plugin expects and what is already on the path.

The top of the file carries a single line, ratelim, which is a rate limiting library and is out of place in a requirements list without a version. Whether that is a leftover or a genuine direct dependency is not something the repository explains at this point.

The repository layout, and what the examples directory reveals

The top-level listing is that of a Python plugin with a documentation site, and several entries are more telling than the rest.

There is ee_plugin/ for the plugin source, examples/ for runnable examples, test/ for the tests, docs/ for the documentation, and help/ for the help files QGIS loads when you press the plugin's help button. There is media/ for the images the documentation uses, mkdocs.yml and a _config.yml for the site build, and separate requirements files for development and for the documentation build, alongside the runtime requirements.

The .qgis-plugin-ci directory is the interesting one. That is the configuration for the tool that automates building and publishing QGIS plugins, which handles the packaging, the metadata that the QGIS plugin repository shows, and the release upload. A plugin with that directory is set up to publish through the official plugin manager rather than being installed from a source checkout, which is what you want if you are expecting other people to use it.

There is also a .secrets.example file, which tells you the plugin talks to something that needs credentials. That is the Earth Engine service itself, and a project that ships an example secrets file is a project that expects users to supply their own Earth Engine account details rather than sharing one.

The examples directory is the clearest statement of the plugin's capabilities, and the file names are a list of things. There is basic_geometries.py, basic_image.py, and a set of QGIS project files such as Sentinel-2.qgs. There is example_sentinel2.py and landsat_median.py, which are the two classic Earth Engine use cases: a single satellite scene and a multi-scene median composite. There is hillshade.py and hillshade_and_water.py, and a srtm_hillshade model file, which is terrain analysis rather than imagery.

Then the map interaction examples, which are the ones that show the plugin working with QGIS itself: download_by_canvas.py, map_add_features.py, map_center_object.py, map_center_object_no_zoom.py, map_get_bounds.py, map_get_center.py, map_set_center.py and map_set_zoom.py. Those are a small API surface for reading and writing the QGIS map canvas, and the pair of center_object files with and without zoom is a good clue that the two behaviours are different enough to be worth separate examples.

And a palettes file, palettes_crameri_oleron_dem.py, which is about how the elevation data gets rendered. The Crameri and Oleron palettes are perceptually uniform colour ramps designed for scientific visualisation, and shipping a choice of them in a QGIS plugin is a thoughtful touch, because a hillshade that uses a perceptual ramp communicates the terrain better than a rainbow one.

There is an examples/contrib/ directory as well, which is the usual convention for examples contributed by other people rather than by the maintainers.

Contributing, and the order the README asks for

The Contributing section is short and its ordering is the useful part.

1. Check out [CONTRIBUTING.md](https://github.com/gee-community/qgis-earthengine-plugin/blob/main/CONTRIBUTING.md) for setup instructions.
2. Ensure your contribution relates to an existing [issue](https://github.com/gee-community/qgis-earthengine-plugin/issues) or discussion.
3. Open a pull request or issue before starting major changes.

For feature requests and updates, please check the [GitHub Issues](https://github.com/gee-community/qgis-earthengine-plugin/issues) and [Discussions](https://github.com/gee-community/qgis-earthengine-plugin/discussions).

Three steps, and the second one is the unusual instruction. Before you write code, ensure your contribution relates to an existing issue or discussion. And open a pull request or issue before starting major changes.

That is a request to agree on the work before doing the work, which is a common convention and an unusual one to state this plainly. For a plugin that a small number of people maintain, a large unsolicited pull request is work to review, and a change that touches the Earth Engine API usage or the QGIS integration has a good chance of conflicting with something already in flight.

The setup instructions live in a CONTRIBUTING.md in the repository, and the features and update requests are directed at the issue tracker and the Discussions section rather than to a chat channel or an email address. For a project with a small user base, keeping the discussion in public issues is what makes the answers findable later.

The .pre-commit-config.yaml at the root indicates that the hooks are handled with pre-commit, which is the standard Python approach and means formatting and lint problems are caught before review rather than during it. The .idea/ and .vscode/ directories are both present, which tells you the maintainer works in a JetBrains editor and that the project is set up for a Visual Studio Code workflow as well, and the .python.env file is a pyenv-style interpreter pin so that the local environment matches what the tests expect.

How to evaluate it, and what to check first

There are four things to consider.

First, whether the QGIS version and the Python version line up with what you have. The plugin needs QGIS 3.34 or later, or QGIS 4.x, and it needs an Earth Engine API version that matches the Python in your QGIS installation. That is the first thing to check, because it is the thing that will stop the plugin loading at all, and the answer is not obvious from the outside: it depends on the QGIS build you installed and how it was installed.

Second, what your Earth Engine access looks like. The plugin is a bridge to a cloud service, so the volume of imagery you can pull, the region you can cover and the number of concurrent requests all depend on your Earth Engine account and its quotas. The examples make this concrete, because a Sentinel-2 scene and a Landsat median composite over a long period are very different requests in cost.

Third, whether the plugin's own value is the QGIS side or the Earth Engine side. The map interaction examples, reading and writing the canvas centre, the zoom level, the bounds and the features, are what make this a QGIS plugin rather than a script that exports a GeoTIFF. If your workflow is add Earth Engine imagery to a QGIS project and work with it in the usual QGIS tools, that is the case for it. If you want a batch export of imagery, a plain Earth Engine script is simpler.

Fourth, the maturity. The version is 0.3, the release history in the repository is short and recent, and the compatibility promise covers two Qt generations at once, which is a good sign of care but also of work. The troubleshooting page is the document to read before you install, because the failure modes of a plugin that depends on a cloud client inside a desktop application are not obvious.

What you get is a focused bridge between a cloud geospatial platform and a desktop GIS, with worked examples for imagery, terrain, composites and canvas interaction, and a documented dependency resolution that accounts for the Python version your QGIS actually ships. The costs are the version compatibility to manage and the fact that the plugin inherits both the QGIS release cycle and the Earth Engine client's.

Editorial conclusion

Adopt qgis-earthengine-plugin if you want to work with Google Earth Engine imagery and terrain inside QGIS rather than exporting files between the two, since the map interaction examples cover reading and writing the canvas, and the QGIS 3.34 and 4.x support means it works across both current generations of the desktop application. Do not adopt it for batch imagery export, where a plain Earth Engine script is simpler, and do not assume the plugin brings its own Python environment, because it runs inside the interpreter QGIS provides and that is what determines which Earth Engine client version gets installed. Before you commit, check the Python version in your QGIS build against the 1.6.x and 1.7.x split in the requirements file, read the troubleshooting page before installing, and confirm your Earth Engine quotas cover the requests you intend to make, since a Landsat median composite and a single Sentinel-2 scene cost very different amounts.

Frequently asked questions

Official sources

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