ISCE - Mintpy Workflow Results

[Michael A]

Hello All,

I am migrating from SNAP to ISCE/MintPy and would like to get some input on results from SentinelStack that look a little off. I apologize if if I am posting this problem in the wrong section. I want to construct a time series analysis for a year of data for starters, to understand better and identify surface deformations/ subsidence. A strange line or gap is seen running through some of the images, and I'm unsure of its source. Additionally, the velocity images and the geo_velocity.kmz file appears to be all blue. I don't think this is normal either, so I would like to understand if these issues are related or if I omitted some steps by chance. 

What I've done 

• dem.py -a stitch -b 46 48 35 39 -r -s 1 -c
• stackSentinel.py -s ./slc/ -d ./DEM/demLat_N46_N48_Lon_E035_E039.dem.wgs84 -a ./aux/ -o ./orbits/ -w ./  -b'46.797096 48.807583 35.772728 39.572426'
  
• smallbaselineApp.py CoalMinesSenAT43.txt
  
• smallbaselineApp.py --plot
  

Best

Michael

System information:

• Operating system: GNU/Linux 
• Python environment: Mintpy, ISCE
• MintPy version: v1.3.1-1, release date 2021-08-03
• Used InSAR Process: ISCE 
• SAR sensor and imaging mode: Sentinel-1A IW 

[Zhang Yunjun]

Hi Michael,

You smallbaselineApp.cfg configuration looks good to me. I think issues are from the stack processing with isce.

ISCE-2/topsStack has several workflows: slc, correlation, interferogram and offset. For the interferogram workflow, as needed for mintpy. I would recommend adding `-z -r -c` options to apply some multilooking in azimuth and range direction, and generate a redundant network with >=3 connections. I think this is why the temporal coherence is all one, because there is no redundancy in the network.

Besides the horizontal lines in the geocoded temporal coherence mask, there are some boundary gaps in all acquisitions in the time series file, which seems strange. I can not guess on top of my head. If you could send the whole pic folder (maybe zipped and attached here), I could take a deeper look.

Yunjun

[Michael A]

Hello  Yunjun,

I really appreciate your response. I will take another look at stackSentinel's arguments, give your suggestion a try, and get back to you with the results. 

Do you recommend keeping azimuth and range at the default number of looks?

Also attached are the Mintpy visualizations generated. 

Thank You

Michael

[Michael A]

[Zhang Yunjun]

Hi Michael,

The whole pic folder is very helpful. 

1. Your DEM file does not cover the entire scene. You should re-run the dem.py command. I usually gives a much big SNWE for this cmd to make sure of that.

2. The multilook look number determines the output pixel size, so it depends on your purpose and the coherence level of the study area.

3. Besides the -c / --num_connections option to generate a redundant network of interferograms, you might also want to use -C / --coregistration geometry option to speedup the process, which in my experience works most of the time.

Yunjun

[Michael A]

Hello Yunjun,

Your insight was very helpful! I passed a larger DEM along with the parameter options that you suggested and that solved the issue. From what I can tell the lines in the geocoded temporal coherence mask might be a result of the failure of dem.py downloading a few SRTMG1.hgt.zip files. I don't konw how the filling/ filling.hgt is factored in during the stitching process but I am considering another attempt somewhere down the line with Copernicus GLO-30 DEM if it is supported. 

Best,

Michael

[Matt]

Hi everyone, 

I’ve got some results from isce-Mintpy analysis of Sentinel-1 data I thought I could share here and I have a couple of questions about them I was hoping to get some help with. I am using the results to help map landslides. Here are a couple of questions I have: 

1.     Does my network look ok?

2.     Should I increase the looks?

For processing the entire swath to include rural areas should I increase the looks in range and azimuth and sacrifice the resolution and  reduce the filter strength to 0.3?

But vice-versa for this, for only looking in urban areas on a smaller scale would it be suitable to decrease the number of looks and increase the filter strength? 

3.  Are at least 2 connections for each acquisition needed for the inverse of phase variance method?

4.    Would you recommend removing known consistently bad dates from the initial stack in ISCE? Such as 20190512? This way I can get more/new connections with longer temporal baselines as well.

 I have attached a zip file containing relevant figures, the input.txt file and kmz files of the study area. I hope this is ok and let me know if there are any issues accessing the files. I really appreciate anyone taking the time to have a look and a massive thank you to the developers, MintPy is fantastic!  

Thanks,

Matt

[Zhang Yunjun]

Hi Matt,

Based on the average spatial coherence and connected components, it seems like this area is challenging (due to vegetation; is there snow here?). Could you do the following for me to better evaluate?

1. share the full pic folder. There are some files missing, such as the spatial coherence for each interferogram. I recommend using the latest version of mintpy with the following setting for higher resolution figures (I just committed mintpy.plot.dpi here: https://github.com/insarlab/MintPy/pull/663).

   + mintpy.plot.dpi = 300

   + mintpy.plot.maxMemory = 6

2. the topsStack configuration

Regards,

Yunjun

[Matt]

Hi Yunjun, 

Thanks for looking into this for me. I did as you suggested, and I've attached the new pic folders, including the spatial coherence. Sorry for posting multiple times I could not compress the folder down any further so I had to upload multiple files. 

Snow is rare in most parts of the Gisborne district and is unknown near the coast. Above an altitude of 600 m, a few falls of snow may be expected in any winter. 

The topstack configuration: 

stackSentinel.py -s /..../Sentinel-1/SLC/Descending/175/ -d /.../demLat_S39_S37_Lon_E177_E179.dem.wgs84 -a /.../Sentinel-1/Aux_Cal -o /.../Sentinel-1/orbits -z 3 -r 9 -f 0.5 -n '1' -b '-38.72 -38.25 177.94 178.3' --start_date 2015-01-21 --end_date 2020-12-08 -c 5 

Kind regards,

Matt

[Matt]

Wrapped Phase

[Matt]

Unwrap phase and unwrap phase closure

[Matt]

Velocity

[Zhang Yunjun]

Hi Matt,

Thank you for the pic folder, it's very helpful. It's clear that decorrelation is the main issue here and it's strong.

> 1.     Does my network look ok?

> 4.    Would you recommend removing known consistently bad dates from the initial stack in ISCE? Such as 20190512? This way I can get more/new connections with longer temporal baselines as well.

I agree with you that removing those constantly low coherent dates in the ISCE/topsStack processing (more specifically in the interferograms generation and onward steps).

> 2.     Should I increase the looks?

Increase the num of looks and filtering strength. For InSAR, coherence is the foundation of everything, we need it moderate or high before interpreting any phase. I usually play with these parameters several times for my own dataset.

> 3.  Are at least 2 connections for each acquisition needed for the inverse of phase variance method?

The minimum redundancy in mintpy is one. However, personally, I always use more than 3.

A few more suggestions:

1. be cautious about the phase closure unwrapping error correction. It works only when 1) the error percentage is not high and 2) the network is redundant, as shown in my 2019 paper.

2. use `mintpy.load.subset.yx` to avoid loading the data on open water, to speedup [not scientifically important though]

3. Due to the challenging decorrelation in this dataset, if the above still does not work well, you might want to try the full covariance approach as implemented in FRINGE (https://github.com/isce-framework/fringe). 

I hope this helps,

Yunjun

[Matt]

Hi Yunjun, 

I really appreciate your advice it is very helpful. I will definitely look into FRINGE. 

Increase the num of looks and filtering strength. For InSAR, coherence is the foundation of everything, we need it moderate or high before interpreting any phase. I usually play with these parameters several times for my own dataset.

To find suitable options for the filter and looks, would you recommend generating smaller test stacks - of  say 10 images? Or do you think it's best to process the whole stack to see if the parameters are suitable? 

Thanks,

Matt

[Zhang Yunjun]

Hi Matt,

To test different options, you could:

Option 1: re-generate the run and config files, then re-run run_*_merge_burst_igram and run_*_filter_coherence steps to check the coherence for the entire stack. The two steps are pretty fast. This is what I do, but it requires one to be familiar with python and with topsStack code/workflow.

Option 2: choose one representative pair and test the parameters using topsApp.py.

Of course, any other way also works, it’s just a matter of efficiency.

Yunjun

-- 
You received this message because you are subscribed to a topic in the Google Groups "MintPy" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/mintpy/NBtIh3BZSGc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to mintpy+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/mintpy/5b1293a1-3280-4197-a13c-3c96c9e22d94n%40googlegroups.com.