The FRINGE 2023 conference emphasized prioritizing either statistical phase linking or PSI techniques to resolve nonclosure phase issues in deformation studies. The recommendation was to make tools like TomoSAR and StaMPS accessible in Python due to Matlab’s limited accessibility. I wholeheartedly support this proposal as it would democratize access, foster collaboration, and advance InSAR analysis for deformation applications.
-TomoSAR (GitHub - DinhHoTongMinh/TomoSAR: Open-source TomoSAR package for PSDSInSAR and ComSAR algorithms) is the first open-source package for PSDSInSAR and ComSAR algorithms.
-StaMPS (GitHub - dbekaert/StaMPS: Stanford Method for Persistent Scatterers) is the only open-source package for PSI algorithm.
Your vote is crucial for recommending to ESA: Should TomoSAR and StaMPS be available in Python?
Open source PyGMTSAR (Python InSAR) Sentinel-1 processor and time-series analyzer already has pure Python SBAS and PSI analyses, long-term and seasonal trend (STL), 3D interactive visualization and far beyond: GitHub - mobigroup/gmtsar: PyGMTSAR
@mengdahl PyGMTSAR processing interferograms stack itself using parallel Python code. It can utilize all your CPU cores even for a single interferogram computing and it requires only your available amount of RAM even for 1000+ interferogram stack calculation. As I know, SNAP, GMTSAR, etc. has no any of these features and so they are very slow comparatively to PyGMTSAR.
Perhaps you are right, but the community is asking for TomoSAR/StaMPS or equivalent in Python, and not having to change their whole InSAR software stack.
@mengdahl Please do not speak on behalf of everyone. It’s important to recognize that the Python version of the named software could be quite different from the original due to variations in developers and programming approaches. I’ve pointed out that there is already Python software available for this task. Ultimately, it’s your choice which software to use. Some might prefer this existing and modern option rather than waiting for years for Python versions, as you appear to suggest.
I’m voting yes, but with the caveat that many Matlab tools have Octave substitutes, while some systems are not easily ported to Python. The people who do the port should be allowed some flexibility if they encounter blocking issues with Python.
My former employer provided Matlab, but only a for a limited number of users, and a limited set of toolboxes, so Octave was useful when porting from Matlab was straightforward.
There is a new PS-InSAR package written in Python that works with MintPy, called MiaplPy. MintPy can ingest SNAP-processed products, so this is a way for people to run a phase-linking PS analysis on SNAP interferogram stacks in a Python environment.
Thanks, @EJFielding, for the new package MiaplPy from the F. Amelung group! It will help me a lot in redesigning TomoSAR. It is a pleasure to know that people work hard to resolve nonclosure phase issues in deformation studies.
@mengdahl, it’s a great point! Indeed, the keyword that we learned from the FRINGE 2023 is the nonclosure phase. From the statistical point of view, we want to avoid it for applications such as deformations. From the physical point of view, this is the signal we want to exploit to extract information such as moisture. To my knowledge, phase linking is the only technique for the statistical point of view. More information can be found here: https://ieeexplore.ieee.org/document/10261889
You often promote this package, but what is really new here? All the things named as ‘new’ in the publication seem already known and used in software:
The routine workflow includes three new methods to correct or exclude phase-unwrapping errors for two-dimensional algorithms: (i) the bridging method connecting reliable regions with minimum spanning tree bridges (particularly suitable for islands), (ii) the phase closure method exploiting the conservativeness of the integer ambiguity of interferogram triplets (well suited for highly redundant networks), and (iii) coherence-based network modification to identify and exclude interferograms with remaining coherent phase-unwrapping errors.
“Minimum spanning tree bridges,” which are implemented as multilooking plus nearest neighbor interpolation, have been available in GMTSAR for a long time. The field of minimum spanning tree generalization is indeed rich with mathematical investigations. Bridges, as a side-effect of this generalization, represent one aspect of these studies. There are various approaches within this field, of course. The use of nearest neighbor interpolation in processing vector networks in raster form is a common technique.
The analysis of interferogram triplets was proposed in GMTSAR authors’ publications about 10 years ago. This method is also available in PyGMTSAR codes on GitHub, with the commit dates serving as proof of its long-standing availability.
Correlation-weighted unwrapping, present in SNAPHU, and weighted interferogram filtering, available in PyGMTSAR codes on GitHub for years, can be substantiated by their respective commit dates.
Given that you recommend the publication as credible, could you please clarify the situation? As a recognized expert in InSAR, you are undoubtedly aware of the facts I’ve outlined above, so I would appreciate it if you could provide an explanation without deferring to the paper’s authors.