Is pyroSAR a good substitute for python based SNAP toolbox solution?


I recently came across pyroSAR and starting to setup it up. I am trying to create a python based preprocessing workflow.

  1. Does pyroSAR provide same time efficiency as SNAP toolbox?

  2. On comparing the snappy and pyroSAR, is there a major difference between the two in terms of time efficiency for preprocessing a Sentinel-1 product?

  3. Does pyroSAR support batch processing?

I am using Sentinel-1 GRD product with IW and EW swath in HH polarization.


glad you asked, I am the main author. In its core, pyroSAR is just a thin wrapper around the SNAP toolbox. It creates XML workflow files and executes them using SNAP’s GPT command line tool. In my experience this is a lot faster than using snappy. Snappy directly interfaces with Java using the jpy package. This only works for a few Python versions and slows down processing.
Furthermore, pyroSAR can split workflows into smaller steps to execute them in sequence. This way more data is written to temporary files but memory usage and execution time are reduced.

Currently pyroSAR’s SNAP API is limited to backscatter processing because not all workflow nodes are accessible. This is going to change in the next version which I will release in the coming days. This is also going to be the first version available via conda-forge.
The function snap.geocode was made for S1 GRD processing so this might be a good starting point for you. Also, there is some documentation on how to batch process lots of images here.



Hi John,

Thanks for the prompt response. Yeah, I am trying to create a fully python based workflow for my project which has the Sentinel-1 pre-processing part at the moment in SNAP toolbox. Moving it out and working with pyroSAR would definitely help to create a consistent solution.

I however, did not find the batch processing part in the pyroSAR documentation. Can you point it out specifically where it is or the class name I need to look at?


Hi Sid,
to my understanding batch processing is basically just processing a list of scenes with a single workflow. So in SNAP’s graph builder one would create a workflow XML file and load it into the batch processing module together with the list of scenes to then process them in sequence.
pyroSAR has a little different approach in that it creates an individual workflow file for each scene, processes the scene and then moves to the next one. The idea is to treat these XML files as additional metadata attached to the processing result so that in the future it is always clear how, i.e. with which nodes and their parameters, a particular scene was processed.
So basically this is just a loop iterating over a list of scenes, which is this part in the docs:

for scene in selection_proc:
    geocode(infile=scene, outdir=outdir, tr=resolution, scaling='db', shapefile=site)

The function geocode first writes an XML file individual to the scene, i.e. same naming convention as the output GeoTiffs and the input and output products hard-coded in the file, and then passes the file to the GPT command line tool. The output might look something like this:


The naming scheme is consistent for all sensors and products containing some basic scene metadata and the processing steps.
In its basic configuration, only the workflow and one GeoTiff for each polarization are saved. Ancillary products, like the local incident angle map, can be exported with parameter export_extra.



Hi John,

Thanks for the update on batch processing. This clears the batch process with pyroSAR. I am currently writing the code for enabling the batch script, will update you once its done.


1 Like