Bug: InSAR deformation changed from SNAP 6 to 7?

The direction of interferomic displacement reversed between Snap versions 6 and 7. What was up in 6 is now down in 7. Ran same processes on same images to get the opposite results.

To determine which is correct, I went to external, authoritative analyses, found version 7 to be correct. Apparently a bug in v6, fixed in v7.

Any comments to confirm that inSAR deformation in v7 is fixed?

1 Like

What products are you looking at? I remember that SNAP v6 would change the sign when doing last step of converting phase to displacement map in meters.

I’m looking at S1 SLC IW for Ridgecrest earthquake. Was v6 changing sign in error? I decided v7 was good based on sense of deformation from:

My process chain is here:

Thank you for pointing this out!
Is there any chance this is due to the flipping of the master / slave order during co-registration ?
Right now on SNAP 6 (using snappy) I choose the first image to be the master and the second one to be the slave as input but it then reverses this in the output product and the second image becomes the master. So then I have to flip the inputs the get the expected order.
Do you think this change was during co-registration or did you use the same co-registered products and then only ran the phase to displacement step and compared snap 6 /7 ? Or was the entire workflow including co-registration ran with snap 6 / snap 7 ?

I made the InSAR deformation map that the NASA Earth Observatory used for their visualization (from ALOS-2 ascending path 65 data). I converted it to the convention where positive ground motion is towards the satellite. Some people, especially radar engineers, prefer to plot range change so positive means the range increased or the surface moved away from the satellite. This is largely a matter of preference, so you need to say which convention you are using.

And thanks for considering this issue!
I have a habit of making the earlier image the master, just to be consistent.
You might be on to the cause, but I have not been watching the master/slave relationship through the process. I was using SNAP v6 until a few days ago, when v7 became available, replaced v6 at installation. Using the process steps linked above.

Eric, yer the man! Being a dumb geologist, positive closer to the radar platform makes sense to me, but I don’t know how to achieve that, other than by flipping the pallet. Is there a parameter in the SNAP process chain that allows selection of the sign of sense of deformation?

Last night I ran the inSAR displacement process chain on descending (relative orbit 71, July 4-16) track over Ridgecrest in SNAP v7, darn, the west side of the main fault is down again. So I am currently confused. Valley side up seems counterintuitive, but it is strike-slip. Have to drive 700 miles to see for myself.

Master: S1A_IW_SLC__1SDV_20190704T135158
Slave: S1A_IW_SLC__1SDV_20190716T135159

I have been using the processing chain described here,
http://eoscience.esa.int/landtraining2017/files/materials/D4P1a2P.pdf
up to terrain correction (slide 61). Seems I need to go into the post processing sequence to determine sense of motion?

I have seen a legend in KMZ output, but my machine is not properly generating KMZ files.

The SNAP color pallet that I made for deformation is described here

Update, see the difference between displacement on ascending and descending tracks of Sentinel-1 images here: https://topex.ucsd.edu/SV_7.1/index.html
The radar sweeps to the right of the ground track, descending images look west, ascending tracks look east. Deformation is along the line of sight of the radar. Which convention for sense of displacement and which way the radar is looking…

Solved via email from EJFielding: “Yes, the ascending and descending tracks have almost opposite signals in the radar lines of sight as most of the motion is horizontal. Eastward motion on the east side of the fault is towards the satellite on the descending track and away from the satellite on the ascending track.”