pyroSAR: batching SAR satellite data through SNAP and GAMMA

The batch layer between raw scenes and the processing toolboxes

pyroSAR presents itself as a complete solution for the scalable organisation and processing of SAR satellite data. The word that carries the weight is scalable. Working with Synthetic Aperture Radar data is not hard for one acquisition. It is hard for a thousand, because each one carries metadata that has to be tracked, and because the processing itself is a chain of external commands.

The scope the README lays out has five parts. Reading of data from various past and present satellite missions. Handling of acquisition metadata. User-friendly access to processing utilities in SNAP, the ESA toolbox, and in GAMMA Remote Sensing software. Formatting of the preprocessed data for further analysis. And export to Data Cube solutions.

So this is a framework, not a processor. It does not implement InSAR or polarimetry. It makes the existing processors usable in bulk, and it keeps the record of what was done to which scene with which parameters.

That shape suits a particular user: a remote sensing group or an Earth observation service that ingests a catalogue of acquisitions from several missions, needs consistent metadata, and wants the result laid out in a form that a data cube or an analysis database can consume. The maintainer is listed as John Truckenbrodt of DLR, which matches the kind of operational, mission-scale use the design assumes.

The project is MIT licensed with the licence text in LICENSE.txt, and the package metadata marks it for Windows and Linux with Python 3.

Metadata is the asset, not the pixels

Look at what the dependency list is made of and the design becomes clear. The requirements include shapely for geometry, geoalchemy2 and psycopg2 for spatial data in a PostgreSQL database through SQLAlchemy, and spatialist, the companion package, at 0.20.2 or newer.

Those are database and geometry libraries. A framework whose centre of gravity is metadata is a framework built around the idea that the description of an acquisition is as valuable as the radar image, and that the description should be queryable.

The `datacube_prepare.ipynb` notebook at the top of the repository is the visible hint of that intent. Preparing a data cube means deciding what a cube is made of, which means deciding on a spatial and temporal reference, and then writing the metadata of every acquisition into a form the cube can index. The export to Data Cube solutions that the README lists is the last step of that chain, and it needs the metadata to be right.

This also explains the choice to depend on spatialist rather than implement the geometry handling. The framework is not trying to be a spatial library; it is trying to make a spatial catalogue that can live in a PostGIS database and be queried by time, footprint and acquisition parameters.

For a user, the practical effect is that after a processing run you should be able to ask the database which scenes cover a given area in a given date range and what was done to them, rather than reading filenames. If that is not a requirement, the metadata machinery is overhead rather than value.

SNAP and GAMMA are the engines, pyroSAR is the driver

The README describes user-friendly access to processing utilities in SNAP and in GAMMA Remote Sensing software. Both are external, commercial or license-managed products, and pyroSAR's job is to call them properly.

That distinction decides the whole adoption question. A framework that wraps a licensed toolbox is not a replacement for it; it is the layer that turns a sequence of manual command lines into a repeatable batch. If your organisation already owns SNAP licences, or GAMMA, then pyroSAR is where the automation goes. If you do not, installing pyroSAR gets you nothing on its own, because the processing steps it drives are not included.

The Python dependencies reflect the same boundary. The list is not a scientific computing stack: there is numpy, pillow for images, lxml for XML handling which is how SNAP's metadata files are commonly read, pyyaml, requests for talking to catalogues, progressbar2 for long running jobs, psutil for system resources, and packaging. The heavy numerical work happens in the external binaries.

The consequence for a pipeline is that you end up with two dependency stacks to maintain, the Python environment of pyroSAR and the software installation of SNAP or GAMMA, and they have to agree about file formats and metadata conventions. The README's own structure reflects this, with the package sitting under `pyroSAR/` in the repository root and the notebooks and environment files for the various setups alongside it, including environment.yml, environment-dev.yml and environment-doc.yml for conda based installations.

Version control of the framework is a separate matter from the toolboxes, and it is handled sensibly. The build uses setuptools with setuptools_scm, so the version and the dependencies are read dynamically from the repository and from requirements.txt rather than being duplicated in the manifest.

Getting set up: read the docs, then satisfy the dependency list

The README does not carry an install command. It points you to readthedocs for installation instructions, examples and the API reference, and the project publishes its documentation there with a status badge in the README.

What the repository does give you is the environment definition. The requirements file is short enough to read in full, and it is the list you have to satisfy before anything else works:

geoalchemy2>=0.14.0
lxml
numpy
packaging
pillow
progressbar2
psutil
psycopg2
pyyaml
requests
shapely
spatialist>=0.20.2
sqlalchemy-utils>=0.37,<0.42
sqlalchemy>=1.4,<2.1

Two of those deserve a note. `psycopg2` is the PostgreSQL adapter, which confirms that the metadata store is expected to be a real database server rather than a file, and `spatialist>=0.20.2` is a hard floor on the companion package, so a version mismatch there is a realistic first failure. The `sqlalchemy>=1.4,<2.1` pin and the `sqlalchemy-utils` range are similarly narrow, which suggests the code paths are sensitive to the SQLAlchemy major version.

The project targets Python 3.11 and newer, per the `requires-python` field. There is no Python 2 or early Python 3 story here, and the OS classifiers cover Windows and Linux only, which matches the platforms the underlying toolboxes are used on.

Where pyroSAR is the wrong investment

The clearest wrong-tool case is a small archive. The whole value proposition is amortising effort over many scenes. If you have a handful of acquisitions and a well-known processing recipe, calling SNAP or GAMMA directly is less work than learning a framework, standing up a metadata database, and debugging the two environments.

The second limit is the external dependency chain, which I have already partly described but is worth stating as a risk. Your pipeline's success then depends on three things you do not control: the licence and availability of SNAP or GAMMA, the behaviour of those tools across their own versions, and the compatibility between their metadata output and the conventions pyroSAR expects. When a scene fails to process, the diagnostic work is often in the boundary between the layers rather than inside pyroSAR.

The third is that the data cube export is a specific target. The README lists export to Data Cube solutions as one of the five capabilities, and the notebook in the repository is a preparation example. If your organisation stores its acquisitions in a different catalogue, or in files on a cluster with a bespoke index, you are using the metadata and batch parts of pyroSAR and ignoring the cube part, and the value you get is narrower than the README's five bullets suggest.

A fourth, smaller point: the repository's own release history shows work through v0.39.1 on 2026-10-01 and a last push on 2026-10-07, so the project is not dormant. But at version 0.x, with a changelog-driven development style, the API can still move, and a production pipeline should pin its version rather than track the branch.

Alternatives and how the work gets done differently

The realistic alternative is to drive SNAP or GAMMA yourself. The difference in approach is that a hand-rolled script calls the external tool for each scene and writes whatever logs and outputs you want, while pyroSAR standardises the metadata handling, the archive layout, the batch iteration and the export step across a whole catalogue.

Concretely, a direct approach means you write the command construction, the output parsing and the record keeping yourself, probably in a shell script or a thin Python loop. That is fine for ten scenes and unmanageable for ten thousand, because the metadata handling is what scales badly. The direct route also leaves you free to use whichever processor suits each job, and free to change the processing chain at any time, since nothing in the framework is enforcing a structure.

The other alternative is to skip the external toolboxes and process the data with open source code of your own, for example a focused implementation for one sensor or one product type. That approach gives full control over the algorithm and removes the licence dependency, at the cost of implementing and validating the radiometric and geometric processing yourself, which is a research project in itself.

A third option is to outsource the whole thing to a hosted Earth observation platform that returns processed products. That trades the entire processing stack for a service contract and per-scene cost.

pyroSAR sits in the middle of that range, and its distinctive contribution is the metadata and organisation layer, which is exactly the part that every one of the alternatives has to solve and which is least likely to be interesting to reinvent.

Editorial conclusion

Adopt pyroSAR when you have hundreds or thousands of SAR scenes to process consistently and want the metadata handling, the batch orchestration and the archive layout taken off your hands, and when you are prepared to license and operate SNAP or GAMMA alongside it. Do not adopt it for a handful of scenes you can process by hand, or as a substitute for those toolboxes, since it calls into them rather than replacing them. Before you start, read the installation instructions on readthedocs, check which of SNAP and GAMMA you will drive, and plan for the external dependencies in requirements.txt such as psycopg2, shapely and spatialist, since the package is at least as much about its environment as about its own code.

Frequently asked questions

Official sources

1. Issues
2. johntruckenbrodt/pyroSAR on GitHub
3. License: MIT
4. README
5. Releases