DEA Notebooks is a working textbook for satellite data analysis, not a gallery of examples

Two things in one repository

The repository holds the DEA Notebooks and the DEA Tools, and the distinction between them is the first thing to understand.

The notebooks are for analysing DEA's satellite data products. They are designed to demonstrate how to use the DEA data and tools to conduct a broad range of geospatial analyses, and they also demonstrate how to integrate with other open-source software such as Open Data Cube and xarray.

The tools are the code those notebooks use. The DEA Tools Package is described as an open-source Python package containing functions and algorithms to assist in analysing DEA data, and it is published separately to PyPI as dea-tools, with the description open-source tools for geospatial analysis with Digital Earth Australia, Open Data Cube, and Xarray.

So the repository is a textbook and its toolkit at once. That combination is what makes it useful, because the examples are not abstract snippets but the demonstration of a package that you can also install and call yourself.

The whole thing belongs to Digital Earth Australia, which is part of Geoscience Australia, and the project publishes a DOI, 10.26186/145234, along with a full citation with a long author list and the contributors as a collective.

The licence arrangement is two-tier and worth reading. The code in the repository is licensed under the Apache License Version 2.0, and DEA data is licensed under the Creative Commons by Attribution 4.0 license. So the notebooks and tools are permissively licensed, while the data they operate on requires attribution. That distinction is the one to keep in mind if you plan to publish anything derived from the imagery.

The project is Apache-2.0 licensed, the default branch is develop, the last push was on 2026-10-14 and the releases are 0.4.10 from 2026-05-21, 0.4.9 from 2026-04-07 and 0.4.8 from 2026-02-24.

The notebook collection, organised by how much you know

The Knowledge Hub is the place the notebooks are published, and its sections are organised by what you are trying to do rather than by dataset.

The beginner's guide is introductory notebooks aimed at introducing Jupyter Notebooks and how to load, plot, and interact with DEA data. That is the on-ramp for someone who has never used a notebook, which is a real and often ignored audience for a scientific repository.

The DEA products section is notebooks introducing DEA's satellite datasets and derived products, including how to load each dataset and any special features of the data. That last clause is the valuable part. Every satellite product has quirks, a nodata value that is not zero, a band order that is not alphabetical, a resampling convention, and the product notebooks are where those are written down.

The how-to guides are a recipe book of simple code examples demonstrating how to perform common geospatial analysis tasks using DEA and open-source software. Recipes rather than narratives, which means you can find the one you need.

The interactive apps are interactive apps and widgets that require little or no coding to run, which is the entry point for people who want an answer rather than a method.

And the real-world examples are more complex case study workflows demonstrating how DEA can be used to address real-world problems.

That ordering is a genuine curriculum, and it is worth reading as one. Begin with the mechanics, then learn the data, then look up a task, then interact, and only then take on a full problem. Someone learning satellite analysis will follow that path anyway, so arranging the content this way saves them from the usual experience of a repository that assumes expertise it has not earned.

The repository layout mirrors the structure exactly, with directories named Beginners_guide/, DEA_products/, How_to_guides/, Interactive_apps/ and Real_world_examples/, plus a Tools/ directory for the package and a Supplementary_data/ directory for the assets the notebooks load.

There is also a USAGE.rst file that lists the use cases and where contributors are asked to add their own work as a citation to it, which is how you find out what people have actually built with the data.

The tools package and its dependency list

The dea-tools package metadata is in pyproject.toml, and the dependency list is the clearest statement of what the tool does.

dependencies = [
    "aiohttp>=3.5.0",
    "click>=8.0.0",
    "dask>=2023.1.0",
    "dask-ml>=2023.3.24",
    "eo-tides>=0.8.2",
    "fiona>=1.10.0",
    "folium>=0.16.0",
    "geopandas>=0.10.0",
    "geopy>=2.0.0",
    "imageio>=2.20.0",
    "joblib>=1.0.0",
    "lxml>=5.0.0",
    "matplotlib>=3.8.0",
    "numba>=0.57.0",
    "numpy>=1.26.0",
    "odc-algo>=1.1.1",

The Python requirement is stated just above:

requires-python = ">=3.10,<4.0"

The dependencies fall into recognisable groups and the grouping is the clearest description of the tool's scope.

The geospatial core is rasterio, pyproj, fiona, geopandas, rioxarray and rasterstats. That is the standard stack for reading and writing geospatial raster and vector data in Python, and the presence of rioxarray is the important one, since it is the bridge between the raster world and the labelled-array world that xarray provides.

The array and computing core is numpy, pandas, dask, dask-ml, joblib and numba. Dask is doing the heavy lifting, since satellite data at full resolution is far larger than memory and the lazy array model is what makes it tractable.

The catalogue and cloud access is where the modern geospatial infrastructure shows. There is pystac-client for searching a SpatioTemporal Asset Catalogue, odc-stac for reading STAC data through the Open Data Cube conventions, odc-geo, odc-io and odc-algo, planetary_computer for the Microsoft Planetary Computer, s3fs for object storage, and OWSLib for the OGC web services. aiohttp and requests handle the network side.

The analysis and presentation layer is matplotlib, seaborn, scikit-image, imageio, folium for interactive maps and eo-tides for tide-related coastal analysis.

The project is marked as Development Status 3 - Alpha in its classifiers, and the version is dynamic, which means it is derived rather than written by hand in the manifest.

One detail worth noticing: the classifiers list Python 3.10 through 3.13 and the requirement is 3.10 or newer below 4.0. Given the age of some of these dependencies, that is a deliberate and current choice rather than a default.

Three ways to run the notebooks

The repository offers three ways to work with the notebooks, and they exist for different audiences.

The DEA Knowledge Hub is where you can easily view the notebooks and read DEA Tools documentation. That is the read-it-in-a-browser option, and it renders the notebooks for reading rather than execution.

The DEA Sandbox is a free virtual environment for interacting with the notebooks and tools from your web browser. You can use the Sandbox to conduct geospatial analysis without installing anything on your computer.

That distinction is the important one. A sandbox is not just a hosted notebook viewer, it is a full environment with the dependencies already resolved and the data access already configured, which is what makes it possible to do real analysis from a browser tab.

The third option is the National Computational Infrastructure, which is a supercomputer environment available to Australian researchers, academics, and other users by negotiation. The NCI can be used for high-performance geospatial analysis.

The phrase by negotiation is worth pausing on. This is not an open sign-up, it is an allocation of compute time through an application process, and it exists because the analysis these notebooks describe is genuinely large. Running a time series across a decade of Landsat or Sentinel-2 data over a region is the kind of workload that needs a cluster, and the NCI is where Australian researchers get one.

So the three options map onto three levels of ambition: read the notebook, run the notebook, or run the notebook at a scale that needs a supercomputer. A repository that supports all three is unusual, and it is a deliberate piece of infrastructure rather than an accident of the tooling.

The setup guides for the Sandbox and the NCI are both in the Knowledge Hub, under the guides section.

Notebooks as tested software

The badge row includes one that changes how you should read the notebooks, and it is the notebook testing workflow for the entire repository.

That is an integration test workflow that runs the notebooks, and its presence tells you that the examples are executed as part of the project's continuous integration rather than only being documentation.

This matters more in this kind of repository than in most. A notebook that is written but never run rots in a specific way: the data product changes, the API changes, a dependency changes its behaviour, and the notebook still displays its old output. The reader copies it, gets different numbers, and has no way to know whether the difference is a bug in their code or a stale example.

Running the notebooks in CI catches that, at the cost of the CI job being slow and the maintainers having to keep the examples working against the live data products. That is a real ongoing cost, and it is why a great many example repositories do not do it.

The other badges are the usual ones for a science repository: a DOI badge for the citation, the Apache licence badge, a PyPI badge for the dea-tools package version, and a Discord badge for the Open Data Cube chat.

The repository also has a .pre-commit-config.yaml, a Tests/ directory, a CITATION.cff file, which is the newer standard for machine-readable citation metadata, a DEA_notebooks_template.ipynb that is the starting point for a new notebook, and a DEA_Sandbox.ipynb at the root.

The .githooks/ directory at the root is unusual and worth noting. Git hooks are not cloned by default, so a project that keeps its hooks in the repository and installs them separately is doing something deliberate, and in a repository where a pre-commit config also exists the combination suggests both a server-side and a local enforcement path.

The Tools/ directory carries its own README, which is the readme the package metadata points at, so the package documentation lives with the package rather than in a separate documentation site.

Contributing, and where this fits

The contribution path is documented in the wiki rather than in the README, and it is a series of short articles.

There is an article on getting started with Git, one on creating a DEA notebook, one on editing a DEA notebook, one on contributing and reviewing DEA Notebooks, and one on editing the DEA Tools documentation.

Having separate articles for creating and editing a notebook rather than a single contributing guide is a sign of how the project thinks about contributions. Notebooks are a distinct kind of artefact, and the rules for adding one are not the rules for adding a function to the package.

For help, the project asks you to use the Open Data Cube Discord chat or the GIS Stack Exchange with the open-data-cube tag, and to report an issue on the repository. That is a sensible routing, since a question about Open Data Cube belongs with the Open Data Cube community and a question about the notebooks belongs with the notebooks maintainers.

The comparison with other earth observation learning resources is worth making. Most satellite imagery documentation is per-dataset: a page per product explaining the bands and the metadata. That is necessary and it is not sufficient, because it does not teach you how to work with the data once you have it.

This repository is the second half. It assumes you have the data and it teaches the analysis, and the how-to guides and the real-world examples are the part that would otherwise take you a year of working it out.

The other comparison is with the Open Data Cube documentation itself, which is the underlying platform. DEA Notebooks sits on top of it and demonstrates the integration with xarray, which is how a lot of people first meet that combination.

The limits are worth stating. The data is Australian, the products are DEA's own, and the notebooks will use dataset conventions that do not generalise. The tools package is marked alpha and its version is dynamic, so pinning it in a production pipeline is a decision you would make deliberately rather than by default. And the CI that runs the notebooks depends on the upstream services staying stable, which is a dependency a self-contained tutorial would not have.

Editorial conclusion

Adopt DEA Notebooks if you work with satellite data and want worked, tested examples that go beyond a single plot, since the notebooks are organised by skill level and backed by an integration test workflow. Skip it if you need a general-purpose geospatial library rather than notebooks aimed at Australian earth observation data, and if you need a stable release, since the package version is dynamic and the project is marked alpha. Verify first which DEA products you need, since the product notebooks cover dataset-specific loading quirks, and that the data licence terms are compatible with what you intend to publish.

Frequently asked questions

Official sources

1. GeoscienceAustralia/dea-notebooks on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases