Skip to Content
MDPIMDPI

Advanced

by
  • Sagar Rawal *,
  • Guoquan Wang and
  • Muhammad Asif
  • et al.

Reviewer 1: Anonymous Reviewer 2: Caleb Iddissah Kelly Reviewer 3: Anonymous

Round 1

Reviewer 1 Report

Comments and Suggestions for Authors

Rawal et al. (2026) develops a Python workflow, SNAPxtra, to generate Sentinel-1 PS and SBAS interferograms, and prepares them for StaMPS and LiCSBAS time-series analysis. However, this manuscript does not describe the SNAPxtra software in detail. Some issues or points must be clarified before possible publication.

The overall InSAR processing is described extensively in this work. However, much of description regarding the standard operations is already available in other software. Technical details that should show the advancement of SNAPxtra is only briefly described. I suggest the authors to substantially expand the Methods section to describe the software architecture, algorithms and parameters in detail.

Can you compare the SNAPxtra with the conventional SNAP processing or existing workflows in terms of runtime.

Author Response

Dear Reviewer,

Thank you for reviewing our manuscript, “SNAPxtra: An open-source Python workflow for automated multi-temporal InSAR deformation monitoring with SNAP.” We appreciate your constructive suggestions. Our point-by-point responses follow.

Comments 1: Rawal et al. (2026) develops a Python workflow, SNAPxtra, to generate Sentinel-1 PS and SBAS interferograms, and prepares them for StaMPS and LiCSBAS time-series analysis. However, this manuscript does not describe the SNAPxtra software in detail. Some issues or points must be clarified before possible publication.

Response 1: Thank you for your assessment. We have expanded the description of SNAPxtra as a Python workflow that uses SNAP GPT as its main processing engine. The Methods now describe the processing stages and explain the main workflow choices, interferometric-pair generation, masking, and export to downstream time-series software. It explicitly describes the SNAP Multireference operator role to build interferograms for PS and SBAS separately. The three sub section of 2.1 Data Preparation Section now includes the appropriate DEM, parallelism to use multithreading and pairs selection before proceeding to start coregistration and other process.

Location: The appropriate changes can be found in Section 2 and Sections 2.1–2.3;

 

Comments 2: The overall InSAR processing is described extensively in this work. However, much of description regarding the standard operations is already available in other software. Technical details that should show the advancement of SNAPxtra is only briefly described. I suggest the authors to substantially expand the Methods section to describe the software architecture, algorithms and parameters in detail.

Response 2: Thank you for this suggestion. We have reorganized the Methods into data preparation, interferometric-stack formation, and export. The revised text describes the configuration-driven execution and numbered steps; automatic burst selection and reference selection; baseline-constrained SBAS networks and single-master PS pairs; three-image batching and PAIRS selection; DEM requirements; polygon masking; and the products required by StaMPS and LiCSBAS. These details distinguish workflow orchestration in SNAPxtra from processing performed by SNAP operators.

Location: Section 2, Figure 3, and Sections 2.1–2.3;

 

Comments 3: Can you compare the SNAPxtra with the conventional SNAP processing or existing workflows in terms of runtime.

Response 3: Thank you for requesting a runtime comparison. We have revised the opening paragraph of the Discussion to clarify that SNAPxtra is a Python workflow and SNAP GPT is its main processing engine. The revised text explains configurable Java virtual-machine memory, cache, and thread settings, together with selected bursts, spatial subsets, and small-batch interferogram generation as workload- and memory-management strategies. We agree that these design choices do not, by themselves, establish a computational speedup. A controlled runtime comparison has not been performed for this revision; we therefore cannot report a quantitative speedup over equivalent SNAP workflows or other InSAR software. The Discussion now explicitly acknowledges this limitation.

 

Revised manuscript text: SNAPxtra is a lightweight, cross–platform Python workflow designed to automate generation of interferometric stacks for two widely used InSAR time series analysis methods: PS and SBAS. SNAPxtra integrates ESA SNAP processing tools, predefined XML graphs, and Python scripts to automate Sentinel-1 SLC processing and interferometric stack generation. SNAP's Graph Processing Tool (GPT) executes the predefined processing graphs using configurable Java virtual machine memory, cache, and thread settings. SNAPxtra processes selected bursts and spatial subsets and generates interferometric pairs in small batches to manage computational workload and memory usage. Further benchmarking is required to quantify its computational performance relative to equivalent SNAP workflows and other InSAR processing software.

Location: Section 4 (Discussion), opening paragraph; supporting details in Sections 2.1–2.3;

Reviewer 2 Report

Comments and Suggestions for Authors

General

The workflow has genuine utility (automated burst/swath detection, multi-swath and multi-frame batch processing, and dual export to StaMPS and LiCSBAS from a single stack) and is publicly available. However, the manuscript currently overstates its novelty and contains incorrect characterizations of existing software, and the case-study results are not quantitatively validated against independent measurements. I recommend major revision: (1) reframe the novelty claims to accurately reflect the contributions listed above and correcting all inaccurate statements about existing InSAR software, and (2) add a quantitative comparison of at least one case study against independently published deformation rates or GNSS observations. Without these, the contribution does not meet publication standards.

Installation

  1. For MacOS, gpt path is Applications/esa-snap/bin/gpt
  2. Under “2. Install SNAPHU”, I suggest to hyperlink SNAPHU so that users do not have to go back to the start of README.md to click on the hyperlink

 

Abstract

  1. Lines 25—26: Almost all InSAR software (at least open-source) that work on Linux also work on macOS: GMTSAR, ISCE, MintPy, MiaplPy, SNAP, StaMPS. So, the phrase “only supported in Linux” is untrue. Please fix the statement to correctly represent the ecosystems that typically support different InSAR software.
  2. Lines 26—27: “… perform PS or SBAS only.” is imprecise. There are open-source workflows that support PS, SBAS, and a combination of the two. StaMPS/MTI is one; MiaplPy is another. StaMPS performs both PSI and SBAS analyses and enables integration of the PSI and SBAS results to increase measurement point density. MiaplPy is an open-source Python package that performs non-linear phase inversion at full resolution and supports sequential inversion. SNAPxtra itself does not perform time-series analysis (SBAS, PSInSAR, or SBAS+PSInSAR); it is a preprocessor. The argument on Lines 26–27 therefore misrepresents what is presently available and what SNAPxtra can and cannot do. In addition, both SNAP (+SNAP2STAMPS) and ISCE already do what SNAPxtra does as a preprocessor.
  3. Line 27: “require extensive knowledge of InSAR theory.” Knowing some InSAR theory is necessary if one uses InSAR, but that is true in any field. No software can remove that requirement, so it is not a limitation of current workflows. In fact, current workflows already make InSAR processing accessible. For example, with basic programming skills, a user can create an ASF account, use HyP3 with its default settings, download the data, install MintPy, and follow a tutorial notebook to produce initial time-series results with little InSAR processing experience. But InSAR analysis is not just processing. It still requires enough understanding to do the right thing and correctly interpret the results. For example, MintPy will process over water unless a water mask is supplied, and over decorrelated areas unless a coherence threshold is set. SNAP, ISCE, GMTSAR, etc. do not remove the need to understand InSAR theory. I recommend rephrasing to distinguish processing accessibility from the expertise needed for correct analysis and interpretation.

Introduction

  1. Line 62: Please check “Multi InSAR (MT)”. Is this supposed to be “Multi-temporal InSAR”? Is “MT” meant to be “(MT-InSAR)”?
  2. Line 62: “Successor” is inaccurate. MT-InSAR extends DInSAR for time-series analysis but does not replace it. For single-event deformation such as an earthquake, DInSAR remains the more practical choice. Please replace “successor” with an appropriate word, e.g., “extension.”
  3. Line 69: Kindly change “scatters” to “scatterers”. Please ensure all instances of “scatter” or “scatterers” are update if they refer to scatterers (e.g., Line 74, 247)
  4. Line 75: “and low signal to noise ratio” should be something like “and HAVE low signal …”
  5. Line 76: “PS only supports linear model” is overly generalized, and misleading. This is well supported for the conventional PSI formulation, but “several PSI approaches do not use a linear deformation model, see Table 1” (Crosetto et al. 2016: Persistent Scatterer Interferometry: A review; http://dx.doi.org/10.1016/j.isprsjprs.2015.10.011).
  6. Line 82: “exist to process SAR image for TS analysis” is quite an understatement, which forces all of the listed software as preprocessors. Some of them are complete packages, which can take the raw radar data and process all the way to TS outputs (velocity and displacement).
  7. Line 83: “are compatible with Linux only and have minimum community support for continuous updates” is untrue! SNAP, ISCE, MintPy, GMTSAR are some of the best known open-source tools out there and they have very strong and very active community engagement and support. They are also compatible with macOS. If you use PyGMTSAR, you could even process your data in Google Collab.
  8. Lines 84—86: The argument here affects SNAPxtra since its installation requires Terminal commands (e.g., `cp insar_proj_sample.config param_proj.config`, `python check_install.py param_project.config`). For users with no Terminal experience/expertise, the instruction to copy the sample config is simply not enough. It assumes the user knows that the command must be executed in Terminal. It assumes the user knows what the working directory should be for the `cp` command to work as intended. It assumes the user knows Python and how to set it up. Here are the contents of SNAPxtra-main directory as of October 1, 2026 at 14:53 (GMT+8). Although I have experience with Terminal, even for me, the `cp` command will fail inside SNAPxtra-main directory because there is no insar_proj_sample.config. Yes, GMTSAR and ISCE are command line based. But they have comparatively detailed instructions on installation and usage. They have a substantial community for support. The argument on Lines 84—86 therefore is not a strong justification for SNAPxtra.
  9. Line 88: The statement "SNAP...supports generation of interferogram for PS applications only" is incorrect. SNAP's Multi-Reference InSAR operator (MultiMasterInSAR) generates multi-master interferometric stacks for SBAS, with arbitrary pairs specified through the PAIRS parameter. This functionality has been available since SNAP 9, and ESA's own PyRate tutorial demonstrates its use for SBAS stack generation. The claim is also internally contradictory: Section 2.2 of this manuscript states that SNAPxtra generates SBAS interferograms using SNAP's Multi-Reference InSAR Operator. If SNAP generated only PS interferograms, SNAPxtra could not use SNAP to produce SBAS stacks. Furthermore, the SNAPWF paper cited by the authors as [26] builds SBAS stacks using the same SNAP operators. Please correct this sentence.
  10. Lines 109—110: Remove GMTSAR from the list. GMTSAR does not require a “dedicated time series software” for TS analysis.
  11. Line 111: Remove ISCE from this line. ISCE does not have an integrated TS analysis function. For TS, users may use other software like MintPy, MiaplPy, StaMPS, …
  12. Line 112: “with limited options to change parameters for improvement of result” is a false statement. ISCE2 and GMTSAR for instance are highly configurable.
  13. Lines 98—108: This paragraph seems misplaced. The point of this is unclear. I suggest to remove the paragraph
  14. Lines 109—112: The two statements repeat points already mentioned in the Line 81 paragraph.
  15. Line 136—140: Most of the general claims here simply miss the mark. As stated before, ISCE can be used as a preprocessor for StaMPS/MTI, with options to process PSs and DSs jointly. ISCE can also be combined with MiaplPy. Indeed, specialized InSAR software focus on SBAS or PSI, but this does not mean there aren’t already packages out there for joint processing. I believe PyGMTSAR is capable of PS processing in addition to SBAS. These arguments are unfortunately not a good representation of existing software.
  16. Line 147: Can you provide poll results to support the claim that StaMPS/MTI and LiCSBAS are “widely used time-series processing software” or citations to support the claim?
  17. Line 149—150: Please delete “both”. Change “MAC” to “macOS”.

 

Data and Methods

  1. In Figure 2, you have “Automatic Download”, “DEM SRMT/Copernicus”. Should be SRTM.
  2. Line 209: Should be “by setting burst_check=true” or “enabled when burst_check=true”.
  3. Lines 226—228: The manuscript does not specify whether SNAPxtra handles datum conversion for user-provided custom DEMs. Based on the underlying SNAP processor behavior, it appears it does not. This is a critical detail for reproducibility. And since SNAPxtra allows the use of custom DEMs, I recommend that the README, configuration files, and the manuscript itself clearly warn users that any custom DEM must be pre-converted to WGS84 before use. Without this explicit warning, users may encounter processing failures or produce inaccurate results without understanding the cause.
  4. Line 229: Please state what the “Multi-Reference InSAR Operator” is. Is it a module of SNAPxtra or SNAP? State this clearly.
  5. Please use either “co-register*” or “coregister*”. Both are used presently.

 

Discussion

  1. Line 432: It is unclear from the manuscript at what stage subsetting happens if requested. Please clarify this.
  2. Lines 433—435: SNAPxtra does not really offer a complete single solution. It is a preprocessor built on SNAP and supports two existing time series software, one of which requires MATLAB licensing. The manuscript makes an argument for SNAPxtra by referencing impoverished regions/users. I wonder how many of these impoverished regions/users have access to StaMPS/MTI (MATLAB licensing). So despite the claims of the manuscript, SNAPxtra does not take away several of the arguments against existing software (e.g., complete solution; ease of use – while this may be true for SNAPxtra itself, the final output is displacement time series and velocity files, which require expertise in MATLAB or Python or both). While I agree that SNAPxtra is a wonderful resource that StaMPS and LiCSBAS users may find helpful, the manuscript misrepresents what it is.
  3. Lines 436—437: Please see previous comments on this claim. ISCE2 (+StaMPS) already does SNAPxtra (+StaMPS); ISCE2 (+MiaplPy) already does something similar to SNAPxtra (+StaMPS). These are much older, actively maintained, have an active user community on GitHub, have official trainings, and are entirely free to use (no license required). The authors must correctly represent the InSAR landscape. Nothing wrong with contributing an additional software. But the broad claim that SNAPxtra addresses major challenges facing existing software creates the impression there are software that do not do what SNAPxtra does.
  4. Lines 437—440: I strongly encourage the authors to use more neutral language. Contributing to knowledge does not mean you must necessarily denigrate existing research. The impressive point in that list is that you can use the same pipeline for both StaMPS and LiCSBAS. But this is not unique. You can use GMTSAR for SBAS and you can also export its outputs for use in MintPy for SBAS. You can use ISCE2 for StaMPS/MTI. And you do not need to reprocess from scratch to get outputs for MintPy.
  5. Lines 442—445: OK. But it does not constitute an advantage over other software that have subsetting or even more advanced algorithms for correcting unwrapping errors. The comparison with SNAPWF creates the impression this software is the gold standard in InSAR. Rather than treat other packages as rivals that must be put down, why not try treating them as complementary?

 

Additional Points

  1. Lines 336—337: Quetta deformation rate is given as 12 cm/yr to 16.6 cm/yr after 2016 but previous research reported “up to 16 mm per year”. That’s a 10x discrepancy that needs to be addressed.
  2. Line 456: Quetta velocity range for both LiCSBAS and StaMPS/MTI are different from Line 456. Please reconcile them.
  3. Line 255: It seems you have used a superscripted 0 instead of the symbol for degree. Please correct this.
  4. Lines 252 and 295: You have both equations labeled as (2)
  5. Reference 3 and 5 are the same.
  6. Same citation for SNAP2StaMPS and SNAPWF on Lines 91 and 94. Kindly fix.
  7. Lines 124—125 mention “nine primary noise indicators” while Line 461 has six. Double-check.
  8. Some typos: “GitHub respiratory”, “wedding parameters”, “Feburary”, ‘PS Scatteres”, “Persistent Scatters”. Please look through the manuscript to fix grammar and typos.

Author Response

Dear Reviewer,
Thank you for reviewing our manuscript, "SNAPxtra: An open-source Python workflow for automated multi-temporal InSAR deformation monitoring with SNAP." We sincerely appreciate your constructive suggestions, careful attention to detail, and thorough review. Your comments on typographical errors and specific sections have been valuable in improving the manuscript. Our point-by-point responses to each comment and for each section is provide below. 

Comments 1: The workflow has genuine utility (automated burst/swath detection, multi-swath and multi-frame batch processing, and dual export to StaMPS and LiCSBAS from a single stack) and is publicly available. However, the manuscript currently overstates its novelty and contains incorrect characterizations of existing software, and the case-study results are not quantitatively validated against independent measurements. I recommend major revision: (1) reframe the novelty claims to accurately reflect the contributions listed above and correcting all inaccurate statements about existing InSAR software, and (2) add a quantitative comparison of at least one case study against independently published deformation rates or GNSS observations. Without these, the contribution does not meet publication standards.

Response 1: Thank you for emphasizing the importance of independent quantitative validation. The primary objective of the case studies is to demonstrate SNAPxtra’s functionality and adaptability in generating interferometric stacks for subsequent PS and SBAS analysis using established time-series packages. Although the processing includes the noise-mitigation procedures described in the Methods, comprehensive site-specific optimization and independent geodetic validation were not performed. We acknowledge that this limits the quantitative interpretation of the deformation estimates. Detailed investigation of the underlying deformation mechanisms is beyond the scope of this study. We have added an explicit statement in the Results section to clarify these limitations. 

Revised Manuscripts
Result Section (paragraph 1): 
The resulting deformation maps and time series illustrate the workflow application. Although noise-mitigation procedures were applied, comprehensive site-specific opti-mization and independent geodetic validation were not performed. The results primar-ily demonstrate workflow functionality, while detailed geophysical interpretation and investigation of deformation mechanisms remain beyond the scope of this study.

Discussion Section (paragraph 4): 
Differences in the processing methods used by LiCSBAS and StaMPS may contribute to variations in their deformation estimates. Residual atmospheric noise, decorrelation, and phase-unwrapping errors may also affect the results, particularly near processing boundaries. 


Installation

Comments 2: For MacOS, gpt path is Applications/esa-snap/bin/gpt

Response 2: Thank you for identifying this omission. This has been updated in GitHub repository (https://github.com/faraksoch1881/SNAPxtra)

Comments 3: Under “2. Install SNAPHU”, I suggest to hyperlink SNAPHU so that users do not have to go back to the start of README.md to click on the hyperlink


Response 3: Thank you for this practical suggestion. A direct link in the SNAPHU installation step will make the instructions easier to follow. The changes has been made in GitHub repository.

Abstract


Comments 4: Lines 25—26: Almost all InSAR software (at least open-source) that work on Linux also work on macOS: GMTSAR, ISCE, MintPy, MiaplPy, SNAP, StaMPS. So, the phrase “only supported in Linux” is untrue. Please fix the statement to correctly represent the ecosystems that typically support different InSAR software.

Response 4: Thank you for this correction. We removed the Linux-only statement. The abstract no longer limits existing InSAR software to Linux, and the Introduction describes SNAP as available on Windows, macOS, and Linux.
Location: Abstract and Introduction; Discussion section. 

Comments 5: Lines 26—27: “… perform PS or SBAS only.” is imprecise. There are open-source workflows that support PS, SBAS, and a combination of the two. StaMPS/MTI is one; MiaplPy is another. StaMPS performs both PSI and SBAS analyses and enables integration of the PSI and SBAS results to increase measurement point density. MiaplPy is an open-source Python package that performs non-linear phase inversion at full resolution and supports sequential inversion. SNAPxtra itself does not perform time-series analysis (SBAS, PSInSAR, or SBAS+PSInSAR); it is a preprocessor. The argument on Lines 26–27 therefore misrepresents what is presently available and what SNAPxtra can and cannot do. In addition, both SNAP (+SNAP2STAMPS) and ISCE already do what SNAPxtra does as a preprocessor.

Response 5: Thank you for clarifying these distinctions. We revised the abstract to acknowledge that existing packages may support PS, SBAS, or both. SNAPxtra is described as generating interferometric stacks for export; the subsequent time-series analyses are performed in StaMPS and LiCSBAS. Our own StaMPS procedure also describes merging PS and SDFP candidates, rather than treating joint analysis as a new capability introduced by SNAPxtra.
Location: Abstract and Section 3;


Comments 6: Line 27: “require extensive knowledge of InSAR theory.” Knowing some InSAR theory is necessary if one uses InSAR, but that is true in any field. No software can remove that requirement, so it is not a limitation of current workflows. In fact, current workflows already make InSAR processing accessible. For example, with basic programming skills, a user can create an ASF account, use HyP3 with its default settings, download the data, install MintPy, and follow a tutorial notebook to produce initial time-series results with little InSAR processing experience. But InSAR analysis is not just processing. It still requires enough understanding to do the right thing and correctly interpret the results. For example, MintPy will process over water unless a water mask is supplied, and over decorrelated areas unless a coherence threshold is set. SNAP, ISCE, GMTSAR, etc. do not remove the need to understand InSAR theory. I recommend rephrasing to distinguish processing accessibility from the expertise needed for correct analysis and interpretation.

Response 6: Thank you. We agree that processing accessibility and the expertise required for scientific interpretation are separate issues. The original abstract statement about requiring extensive InSAR theory has been removed. The revised text focuses on the sequence of processing operations and the generation of stacks for downstream analysis. Automation does not remove the need to assess coherence, masking, unwrapping quality, reference selection, and interpretation.
Location: Abstract and Conclusion;


Introduction


Comments 7: Line 62: Please check “Multi InSAR (MT)”. Is this supposed to be “Multi-temporal InSAR”? Is “MT” meant to be “(MT-InSAR)”?

Response 7: Thank you. The Introduction now uses Multi-temporal InSAR (MT-InSAR).
Location: Introduction;
Revised manuscript text: Multi–temporal InSAR (MT–InSAR) extends conventional DInSAR by analyzing multiple SAR acquisitions to reduce noise, improve deformation estimates, and investigate long–term ground deformation.

Comments 8: Line 62: “Successor” is inaccurate. MT-InSAR extends DInSAR for time-series analysis but does not replace it. For single-event deformation such as an earthquake, DInSAR remains the more practical choice. Please replace “successor” with an appropriate word, e.g., “extension.”

Response 8: Thank you. We replaced the successor description with a statement that MT-InSAR extends conventional DInSAR. The preceding sentence also retains DInSAR's role in rapid deformation associated with earthquakes and fault movements.
Location: Introduction;
Revised manuscript text: Multi–temporal InSAR (MT–InSAR) extends conventional DInSAR by analyzing multiple SAR acquisitions to reduce noise, improve deformation estimates, and investigate long–term ground deformation.

Comments 9: Line 69: Kindly change “scatters” to “scatterers”. Please ensure all instances of “scatter” or “scatterers” are update if they refer to scatterers (e.g., Line 74, 247)

Response 9: Thank you. The relevant running text now describes radar targets as scatterers, including the Introduction and the Surat case study.
Location: Introduction and Section 3.3; 
Revised manuscript text: PS is recommended to use in urban built up areas where artificial structures act as distinctive scatterers .

Comments 10: Line 75: “and low signal to noise ratio” should be something like “and HAVE low signal …”

Response 10: Thank you. We rewrote the sentence to explain the effect of multilooking on phase noise and signal-to-noise ratio, removing the original grammatical construction.
Location: Introduction; 

Revised manuscript text: SBAS interferograms are generally multilooked to reduce random phase noise and improve the signal–to–noise ratio (SNR) through spatial averaging of neighboring pixels, making the technique suitable for areas with limited persistent scatterers and slow linear and nonlinear deformation over time in low coherence areas.

Comments 11: Line 76: “PS only supports linear model” is overly generalized, and misleading. This is well supported for the conventional PSI formulation, but “several PSI approaches do not use a linear deformation model, see Table 1” (Crosetto et al. 2016: Persistent Scatterer Interferometry: A review; http://dx.doi.org/10.1016/j.isprsjprs.2015.10.011).

Response 11: Thank you for identifying this overgeneralization. We removed the statement that PS methods support only a linear deformation model. The revised introductory comparison no longer places this restriction on PSI.
Location: Introduction;

 

Comments 12: Line 82: “exist to process SAR image for TS analysis” is quite an understatement, which forces all of the listed software as preprocessors. Some of them are complete packages, which can take the raw radar data and process all the way to TS outputs (velocity and displacement).

Response 12: Thank you. We revised the software overview to distinguish packages providing integrated interferometric and time-series processing from packages requiring externally generated interferograms.
Location: Introduction; 


Revised manuscript text: Many of these packages provide comprehensive workflows covering interferogram generation and time–series analysis as an end–to–end processing solution.

Comments 13: Line 83: “are compatible with Linux only and have minimum community support for continuous updates” is untrue! SNAP, ISCE, MintPy, GMTSAR are some of the best known open-source tools out there and they have very strong and very active community engagement and support. They are also compatible with macOS. If you use PyGMTSAR, you could even process your data in Google Collab.

Response 13: Thank you for correcting this inaccurate characterization. The Linux-only and minimal-community-support assertions have been removed. The revised overview acknowledges established documentation and active communities and discusses installation requirements as dependent on the package and operating system.
Location: Introduction; 


Comments 14: Lines 84—86: The argument here affects SNAPxtra since its installation requires Terminal commands (e.g., `cp insar_proj_sample.config param_proj.config`, `python check_install.py param_project.config`). For users with no Terminal experience/expertise, the instruction to copy the sample config is simply not enough. It assumes the user knows that the command must be executed in Terminal. It assumes the user knows what the working directory should be for the `cp` command to work as intended. It assumes the user knows Python and how to set it up. Here are the contents of SNAPxtra-main directory as of October 1, 2026 at 14:53 (GMT+8). Although I have experience with Terminal, even for me, the `cp` command will fail inside SNAPxtra-main directory because there is no insar_proj_sample.config. Yes, GMTSAR and ISCE are command line based. But they have comparatively detailed instructions on installation and usage. They have a substantial community for support. The argument on Lines 84—86 therefore is not a strong justification for SNAPxtra.

Response 14: Thank you for identifying the mismatch between the documented commands and the available files. We agree that command-line usage alone is not a limitation of existing workflows. The revised Introduction acknowledges their established documentation and user communities. The Discussion describes the user manual and video tutorials developed for SNAPxtra. We have also clarified SNAPxtra's simplified command-line execution, which requires only the main script and configuration file for batch processing, with an optional step number to execute a specific processing step.

Location: Section 4: Discussion

Revised manuscript text: "The command-line interface for SNAPxtra only requires specifying the main execution python file and configuration file. The step number is optional; if omitted, the entire processing workflow is executed. The InSAR method and export target can be controlled using the optional -m and -t parameters, respectively. Deploying SNAPxtra for InSAR processing in cluster computing environments is relatively straightforward due to its simplified installation and consistent command-line interface. Users do not need to remember multiple commands for different processing operations, as individual steps can be executed by specifying the corresponding step number, while omitting the step number executes the entire processing pipeline. "

 

Comments 15: Line 88: The statement "SNAP...supports generation of interferogram for PS applications only" is incorrect. SNAP's Multi-Reference InSAR operator (MultiMasterInSAR) generates multi-master interferometric stacks for SBAS, with arbitrary pairs specified through the PAIRS parameter. This functionality has been available since SNAP 9, and ESA's own PyRate tutorial demonstrates its use for SBAS stack generation. The claim is also internally contradictory: Section 2.2 of this manuscript states that SNAPxtra generates SBAS interferograms using SNAP's Multi-Reference InSAR Operator. If SNAP generated only PS interferograms, SNAPxtra could not use SNAP to produce SBAS stacks. Furthermore, the SNAPWF paper cited by the authors as [26] builds SBAS stacks using the same SNAP operators. Please correct this sentence.

Response 15: Thank you for pointing out this error. The revised Introduction acknowledges SNAP's MultiReference InSAR operator for SBAS stack generation. Section 2.2 explicitly identifies it as a SNAP operator and explains the PAIRS combinations used to retain single-master PS pairs and baseline-qualified SBAS pairs. SNAPxtra automates these operations; it does not introduce SBAS processing to SNAP.
Location: Introduction and Section 2.2;
Revised manuscript text: Interferograms are generated using SNAP MultiReference InSAR Operator by reading the pair information from the text file created in the first step.

Comments 16: Lines 109—110: Remove GMTSAR from the list. GMTSAR does not require a “dedicated time series software” for TS analysis.

Response 16: Thank you. We removed the assertion that GMTSAR requires a separate dedicated time-series package. The revised overview distinguishes integrated workflows from packages using externally prepared interferograms.
Location: Introduction; 


Comments 17: Line 111: Remove ISCE from this line. ISCE does not have an integrated TS analysis function. For TS, users may use other software like MintPy, MiaplPy, StaMPS, …

Response 17: Thank you. We removed the original statement assigning an integrated time-series function to ISCE. We agree that ISCE interferometric products can be processed with external time-series packages.
Location: Introduction;

Comments 18: Line 112: “with limited options to change parameters for improvement of result” is a false statement. ISCE2 and GMTSAR for instance are highly configurable.

Response 18: Thank you. We removed the claim that ISCE and GMTSAR offer limited options for parameter adjustment. The revised overview recognizes differences in package design, algorithms, and computational capabilities without the original restriction.
Location: Introduction; 
Revised manuscript text: These software packages offer various processing algorithms, noise mitigation techniques, and computational capabilities depending on their design and intended applications.

Comments 19: Lines 98—108: This paragraph seems misplaced. The point of this is unclear. I suggest to remove the paragraph

Response 19: Thank you. We removed the misplaced background paragraph from the Introduction and consolidated the discussion of interferometric preprocessing and downstream time-series software.
Location: Introduction;

Comments 20: Lines 109—112: The two statements repeat points already mentioned in the Line 81 paragraph.
Response 20: Thank you. The repeated statements have been removed and the software overview consolidated, reducing duplication in the Introduction.
Location: Introduction;

Comments 21: Line 136—140: Most of the general claims here simply miss the mark. As stated before, ISCE can be used as a preprocessor for StaMPS/MTI, with options to process PSs and DSs jointly. ISCE can also be combined with MiaplPy. Indeed, specialized InSAR software focus on SBAS or PSI, but this does not mean there aren’t already packages out there for joint processing. I believe PyGMTSAR is capable of PS processing in addition to SBAS. These arguments are unfortunately not a good representation of existing software.

Response 21: Thank you. We agree that joint PS/SBAS analysis and interoperability already exist. The abstract now acknowledges packages supporting both methods, and the Results explain our use of StaMPS to merge PS and SDFP candidates. SNAPxtra's contribution is the integration of automated preprocessing and export choices using SNAP, rather than the invention of joint time-series analysis.
Location: Abstract and Section 3; 

Comments 22: Line 147: Can you provide poll results to support the claim that StaMPS/MTI and LiCSBAS are “widely used time-series processing software” or citations to support the claim?

Response 22: Thank you. We added Figure 2 to present annual citations to selected StaMPS and LiCSBAS publications. The caption identifies Google Scholar as the source, provides the retrieval date, and states that 2026 is a partial year. Citation counts indicate scholarly attention rather than the number of users; no poll of users was performed.
Location: Introduction and Figure 2; 
Revised manuscript text: Figure 2: Annual citations to the selected StaMPS and LiCSBAS publications, retrieved from Google Scholar [accessed on 20 Oct 2026]. The 2026 values cover only the period up to that date.

Comments 23: Line 149—150: Please delete “both”. Change “MAC” to “macOS”.

Response 23: Thank you. The operating-system wording has been revised and macOS is now written in the correct form. The operating-system lists no longer use both for three platforms.
Location: Introduction and Discussion; 


Data and Methods

Comments 24: In Figure 2, you have “Automatic Download”, “DEM SRMT/Copernicus”. Should be SRTM.

Response 24: Thank you for identifying the transposed letters. The figure has been updated with correct DEM name. 
 
Location: Section 2.2 and Figure 3; 

Comments 25: Line 209: Should be “by setting burst_check=true” or “enabled when burst_check=true”.

Response 25: Thank you. The revised sentence now specifies the configuration setting and how it is enabled.
Location: Section 2.1; 
Revised manuscript text: Users can also enable optional burst verification step in SNAPxtra by setting 'burst_check=true' in the configuration file.

Comments 26: Lines 226—228: The manuscript does not specify whether SNAPxtra handles datum conversion for user-provided custom DEMs. Based on the underlying SNAP processor behavior, it appears it does not. This is a critical detail for reproducibility. And since SNAPxtra allows the use of custom DEMs, I recommend that the README, configuration files, and the manuscript itself clearly warn users that any custom DEM must be pre-converted to WGS84 before use. Without this explicit warning, users may encounter processing failures or produce inaccurate results without understanding the cause.

Response 26: Thank you for highlighting this reproducibility issue. Section 2.2 now specifies the geographic coordinate system for an external DEM and explicitly distinguishes the horizontal coordinates from the height reference. The text warns that assigning EPSG:4326 alone does not convert elevations.
Location: Section 2.2; 
Revised manuscript text: A custom DEM can be supplied as a GeoTIFF in WGS84 geographic coordinates (EPSG:4326) by specifying its path in the configuration file. Its vertical reference and any required conversion to WGS84 ellipsoidal heights must be checked separately; assigning EPSG:4326 alone does not convert elevations.

Comments 27: Line 229: Please state what the “Multi-Reference InSAR Operator” is. Is it a module of SNAPxtra or SNAP? State this clearly.

Response 27: Thank you. Section 2.2 explicitly identifies the operator as belonging to SNAP and describes how SNAPxtra supplies the pair information.
Location: Section 2.2; 
Revised manuscript text: Interferograms are generated using SNAP MultiReference InSAR Operator by reading the pair information from the text file created in the first step.

Comments 28: Please use either “co-register*” or “coregister*”. Both are used presently.

Response 28: Thank you. We standardized the running-text terminology to coregistration and coregistered, including the Methods descriptions of stack formation and matching exported products.
Location: Sections 2.1–2.3; 


Discussion


Comments 29: Line 432: It is unclear from the manuscript at what stage subsetting happens if requested. Please clarify this.
Response 29: Thank you. We now distinguish burst selection during data preparation from subsequent spatial cropping. Section 2.1 describes selecting relevant subswaths and bursts before further processing. Section 2.3 specifies cropping with SNAP Subset at Step 9, controlled by clip_roi, before phase unwrapping, and explains that corresponding operations are applied to the coregistered SLC stacks.
Location: Sections 2.1 and 2.3;
Revised manuscript text: Therefore, the generated interferograms are further cropped using SNAP Subset operator in Step 9, with the extent specified by clip_roi in configuration file before phase unwrapping.

Comments 30: Lines 433—435: SNAPxtra does not really offer a complete single solution. It is a preprocessor built on SNAP and supports two existing time series software, one of which requires MATLAB licensing. The manuscript makes an argument for SNAPxtra by referencing impoverished regions/users. I wonder how many of these impoverished regions/users have access to StaMPS/MTI (MATLAB licensing). So despite the claims of the manuscript, SNAPxtra does not take away several of the arguments against existing software (e.g., complete solution; ease of use – while this may be true for SNAPxtra itself, the final output is displacement time series and velocity files, which require expertise in MATLAB or Python or both). While I agree that SNAPxtra is a wonderful resource that StaMPS and LiCSBAS users may find helpful, the manuscript misrepresents what it is.

Response 30: Thank you. We clarified that SNAPxtra generates interferometric stacks and exports them for time-series analysis in StaMPS or LiCSBAS. The Discussion acknowledges the MATLAB licensing requirement for StaMPS and explains that LiCSBAS provides an open-source SBAS route. The combined processing chain involves these separate packages and their dependencies.
Location: Abstract and Discussion;
Revised manuscript text: In the absence of a MATLAB license required to run StaMPS, users can still complete SBAS-based InSAR analysis using LiCSBAS, a free and open-source time-series analysis package.

Comments 31: Lines 436—437: Please see previous comments on this claim. ISCE2 (+StaMPS) already does SNAPxtra (+StaMPS); ISCE2 (+MiaplPy) already does something similar to SNAPxtra (+StaMPS). These are much older, actively maintained, have an active user community on GitHub, have official trainings, and are entirely free to use (no license required). The authors must correctly represent the InSAR landscape. Nothing wrong with contributing an additional software. But the broad claim that SNAPxtra addresses major challenges facing existing software creates the impression there are software that do not do what SNAPxtra does.

Response 31: Thank you. We agree that SNAPxtra should be positioned as an additional workflow in the established InSAR ecosystem. The revised Discussion describes its dependence on SNAP and its role in preparing inputs for existing time-series packages. Its practical contribution is the integrated automation of the listed preprocessing tasks and export paths.
Location: Discussion; 
Revised manuscript text: These integrated features simplify InSAR preprocessing, improve workflow flexibility, and provide researchers with an additional accessible option among existing InSAR software packages.

Comments 32: Lines 437—440: I strongly encourage the authors to use more neutral language. Contributing to knowledge does not mean you must necessarily denigrate existing research. The impressive point in that list is that you can use the same pipeline for both StaMPS and LiCSBAS. But this is not unique. You can use GMTSAR for SBAS and you can also export its outputs for use in MintPy for SBAS. You can use ISCE2 for StaMPS/MTI. And you do not need to reprocess from scratch to get outputs for MintPy.

Response 32: Thank you. We revised the Discussion to emphasize the implemented preprocessing features and their integration with StaMPS and LiCSBAS. We agree that interoperability and reuse of processed products are not unique to SNAPxtra and that other workflows provide established alternatives.
Location: Discussion; 
Revised manuscript text: These integrated features simplify InSAR preprocessing, improve workflow flexibility, and provide researchers with an additional accessible option among existing InSAR software packages.

Comments 33: Lines 442—445: OK. But it does not constitute an advantage over other software that have subsetting or even more advanced algorithms for correcting unwrapping errors. The comparison with SNAPWF creates the impression this software is the gold standard in InSAR. Rather than treat other packages as rivals that must be put down, why not try treating them as complementary?

Response 33: Thank you. We agree that spatial subsetting and masking should be described as workflow functions rather than evidence of general superiority. The Discussion presents SNAPxtra as an additional processing option, and the Introduction acknowledges the public SNAPWF notebook. The Methods describe exactly where SNAPxtra applies subsetting and masking.
Location: Introduction, Section 2.3,.

Additional Points


Comments 34: Lines 336—337: Quetta deformation rate is given as 12 cm/yr to 16.6 cm/yr after 2016 but previous research reported “up to 16 mm per year”. That’s a 10x discrepancy that needs to be addressed.

Response 34: Thank you for asking us to check the units. Section 3.1 now explicitly attributes the historical rates to the cited study and gives their periods: approximately 12 cm/yr from GNSS during 2008–2016, 16.6 cm/yr during 2016–2022, and approximately 16 cm/yr from its December 2015–December 2022 InSAR analysis. These historical vertical rates are distinct from our later LOS velocities and should not be equated directly.
Location: Section 3.1; 
Revised manuscript text: Previous studies reported GNSS subsidence magnitudes at Quetta of approximately 12 cm/yr during 2008–2016 and 16.6 cm/yr during 2016–2022. Their InSAR analysis for December 2015–December 2022 indicated vertical subsidence of approximately 16 cm/yr .

Comments 35: Line 456: Quetta velocity range for both LiCSBAS and StaMPS/MTI are different from Line 456. Please reconcile them.


Response 35: Thank you. The Quetta velocity ranges are consistent between the Results and Discussion: −110 to 33.1 mm/yr for LiCSBAS and −112 to 34.7 mm/yr for StaMPS. These are LOS velocity ranges.
Location: Section 3.1 and Discussion;

Comments 36: Line 255: It seems you have used a superscripted 0 instead of the symbol for degree. Please correct this.

Response 36: Thank you. The heading-angle values in the export description now use the degree symbol, rather than a superscript zero.
Location: Section 2.3;

Comments 37: Lines 252 and 295: You have both equations labeled as (2)

Response 37: Thank you. The current manuscript uses Equation (1) for reference selection, Equation (2) for amplitude dispersion, and Equation (3) for the ENU expressions. Their textual references in Sections 2.1, 2.3 and 3 are consistent with these assignments.
Location: Sections 2.1, 2.3, and 3; .

Comments 38: Reference 3 and 5 are the same.


Response 38: Thank you for identifying the duplicate. We have updated our References removing the duplicate citations. 


Comments 39: Same citation for SNAP2StaMPS and SNAPWF on Lines 91 and 94. Kindly fix.

Response 39: Thank you. The Introduction now identifies SNAP2StaMPS using its own repository link and cites SNAPWF separately as reference.
Location: Introduction; 
Revised manuscript text: SNAP2StaMPS is a Python–based workflow that automates the preparation of interferometric stacks for subsequent PS time–series analysis using StaMPS (https://github.com/mdelgadoblasco/snap2stamps).

Comments 40: Lines 124—125 mention “nine primary noise indicators” while Line 461 has six. Double-check.


Response 40: Thank you. The revised running text consistently uses nine noise indices in the software overview, the LiCSBAS Methods, and the Discussion, resolving the earlier nine-versus-six discrepancy.
Location: Introduction, Section 3, and Discussion; 
Revised manuscript text: LiCSBAS only perform SBAS analysis and bad pixels are masked using nine major noise indicators after checking quality of interferogram in step 11 and step 12.

Comments 41: Some typos: “GitHub respiratory”, “wedding parameters”, “Feburary”, ‘PS Scatteres”, “Persistent Scatters”. Please look through the manuscript to fix grammar and typos.

Response 41: Thank you. We have revised the language and terminology in the manuscript, including the scatterer terminology in the running text and the description of the GitHub repository. A final proofreading pass is still needed to remove residual typographical and grammatical errors.
Location: Throughout; especially Abstract, Results, Discussion, and captions; 

 

Reviewer 3 Report

Comments and Suggestions for Authors

This paper presents SNAPxtra, an open‑source automated Python‑based workflow that addresses key practical pain‑points in current MT‑InSAR processing, including tool fragmentation, poor cross‑platform compatibility, steep learning curves, and separated processing pipelines for PS and SBAS techniques. The tool exhibits good potential for broader community adoption. Nevertheless, several questions remain and need to be adequately addressed by the authors:

  1. Beyond the theoretical descriptions provided in the manuscript, are comprehensive user documentation, installation instructions, example datasets, and step‑by‑step operation guidelines publicly available to facilitate rapid onboarding for novice users?
  2. How is consistency correction implemented for interferometric phase and coherence within overlapping zones between adjacent frames during multi‑frame processing?
  3. Only mean deformation velocity maps are presented in this work, whereas time‑series displacement curves for typical subsidence sites are missing. Do the authors plan to supplement time‑series results to illustrate the temporal evolution of surface deformation?
  4. Does the SNAPxtra workflow support GPU acceleration? Are there targeted performance‑optimization strategies for processing large‑scale study areas and large‑volume SAR datasets?

Author Response

Dear Reviewer,

Thank you for reviewing our manuscript, "SNAPxtra: An open-source Python workflow for automated multi-temporal InSAR deformation monitoring with SNAP." We appreciate your constructive suggestions. Our point-by-point responses follow.

Comments 1: This paper presents SNAPxtra, an open‑source automated Python‑based workflow that addresses key practical pain‑points in current MT‑InSAR processing, including tool fragmentation, poor cross‑platform compatibility, steep learning curves, and separated processing pipelines for PS and SBAS techniques. The tool exhibits good potential for broader community adoption. Nevertheless, several questions remain and need to be adequately addressed by the authors:

Thank you for your constructive assessment and for recognizing the practical potential of SNAPxtra. We have carefully considered your suggestions and addressed the questions regarding user guidance, adjacent-frame processing, displacement time series, and computational resources in the responses below. We have also clarified SNAPxtra's role in automating interferometric preprocessing through SNAP and exporting interferometric stacks for subsequent time-series analysis.


Comments 2: Beyond the theoretical descriptions provided in the manuscript, are comprehensive user documentation, installation instructions, example datasets, and step‑by‑step operation guidelines publicly available to facilitate rapid onboarding for novice users?

Thank you for emphasizing reproducibility and onboarding. We have prepared a step-by-step handbook explaining installation, configuration parameters, and workflow execution, together with practical video tutorials.


Link to Manual:https://github.com/faraksoch1881/SNAPxtra/blob/main/snapxtra_guide_manual.pdf
Link to Youtube: https://www.youtube.com/watch?v=o_g6JAF6VlM&list=PLQcP7pPK-FLs

These resources are now described in the Discussion section of the revised manuscript. Sentinel-1 SLC data can be downloaded through ASF Vertex, and the GitHub repository provides configuration guidance for processing these datasets. Direct links to the manual and video tutorials have also been included in the manuscript to facilitate access and help new users get started with SNAPxtra.

Comments 3: How is consistency correction implemented for interferometric phase and coherence within overlapping zones between adjacent frames during multi‑frame processing?

Thank you for this question. Section 2.1 explains that SNAPxtra uses SNAP's Slice Assembly operator when the ROI overlaps adjacent acquisition frames along the same track. Assembly takes place during data preparation, before subsequent interferometric processing. SNAPxtra does not add a separate empirical overlap phase-offset correction in the described workflow. This explanation concerns compatible adjacent slices of one acquisition; it should not be read as a guarantee of perfect coherence or as independent mosaicking of arbitrary frames.
Location: Section 2.1; 

Revised manuscript text: The Slice Assembly operator is applied when the study area overlaps two adjacent frames along the same track, merging them into a single continuous dataset.

Comments 4: Only mean deformation velocity maps are presented in this work, whereas time‑series displacement curves for typical subsidence sites are missing. Do the authors plan to supplement time‑series results to illustrate the temporal evolution of surface deformation?

 Thank you for this suggestion. The revised results now include displacement time-series panels for two selected locations in each case study. The sites are identified by X and Y in the velocity maps and corresponding time-series panels of Figures 4, 5 and 6. Section 3.1 also discusses the temporal evolution at the selected Quetta locations. These additions show temporal behavior alongside the mean LOS velocity maps.
Location: Sections 3.1–3.3 and Figures 4–6;

Revised manuscript text: The time series evolution of two selected sites is also shown in the Figure 4.

Comments 5: Does the SNAPxtra workflow support GPU acceleration? Are there targeted performance‑optimization strategies for processing large‑scale study areas and large‑volume SAR datasets?

Thank you. SNAPxtra uses SNAP GPT as its main processing engine; no GPU-accelerated processing path is implemented in the described workflow. Section 2.3 explains configurable GPT CPU threading through parallel=true and a thread count. For larger datasets, the Methods describe selecting relevant bursts before coregistration, generating interferograms in three-image batches, and cropping to the ROI before unwrapping. These are workload and resource-management strategies, rather than a measured guarantee of faster processing or full CPU utilization.
Location: Sections 2.1–2.3;

 

Round 2

Reviewer 1 Report

Comments and Suggestions for Authors

I recommend that the manuscript be accepted for publication in its current form.