Can I use isce2 to make a DEM from a pair of Palsar-2 images?

[afpoley]

Hi everyone,

I am working on processing some Palsar-2 images to create a DEM and I want to utilize ISCE's ionospheric phase corrections to help reduce noise. I've ran through the Alos2App.py processing but now I'm looking to change some of the setting during the unwrapping to use shaphu topography modes. I think I found where these are set in runUnwrapSnaphu.py but I wanted to see if anyone had any experience in doing this. Would it be better to run snaphu independently using the outputs from Alos2App up to the unwrapping step?
Are there other options within Isce that I should be using instead of Alos2App?

Any information is appreciated. Thank You!
Andrew

[EJFielding]

Hello Andrew,

You can find all of the parameters that you can change with the alos2App.py input xml file by looking at the applications/alos2App.py code. If you want to change other parameters, you would have to run the lower level ISCE modules from your own Python code. It is probably much easier to run SNAPHU as an external program if you want to use all the SNAPHU features.

By the way, the ISCE package does not include any support for making a DEM out of an InSAR pair.

++Eric

[afpoley]

Thank you Eric. Do you know if the topographic phase is subtracted during the interferogram formation? If not, do you think I could modify the SNAPHU settings to use topo and then use SNAP to convert the unwrapped phase to elevation to get a DEM that has the ionospheric corrections?

Thank you,
Andrew

[EJFielding]

The first step of forming the interferogram in alos2App.py does not have the topographic phase removed. The file name is something like 150727-191209_1rlks_14alks.int (this example is for ScanSAR data so there are many azimuth looks, the number of looks at this step are the "looks1" values). Then the next step subtracts the topographic phase to make a file with a name like diff_150727-191209_1rlks_14alks.int where the "diff" means it is a differential interferogram. After that, the app takes more looks (based on the "looks2" parameters) to make a file like diff_150727-191209_5rlks_28alks.int before doing the ionospheric correction, filtering, and phase unwrapping. The ionospheric correction is only calculated at the second number of looks and subtracted from the diff_150727-191209_5rlks_28alks.int. When you apply the ionospheric correction, this is the file with the correction and the original differential interferogram without the ionospheric correction is diff_150727-191209_5rlks_28alks_ori.int. You would need to modify the alos2App.py program to get a version of the interferogram with the ionospheric correction applied but without the topographic phase removed.

[afpoley]

Thank you! That all makes sense. I'll report back if I follow through and get everything working.

Just curious, is there a reason DEM generation isn't a part of ISCE beside time-constraints on coding? Like is there a practical reason people do not use ISCE for this application? Just wondering if it's worth the time investment in trying to come up with a solution for this or sticking with SNAP.

Thank you,
Andrew

[EJFielding]

Repeat-pass interferometry is not an accurate method for making DEMs, because of the changes in the atmosphere between the two acquisitions. I made a number of repeat-pass DEMs back before we had the SRTM data from ERS-1/ERS-2 Tandem (1-day separation) and SIR-C 1-day repeat pairs, and all of them had errors due to tropospheric water vapor variations. There was support for making DEMs in the old ROI_pac software package. With ALOS-2 (or ALOS-1) data, you will also have the ionospheric effects that can be partially but not completely removed. The end result will always be inaccurate.
JPL software developers wrote the code for processing the SRTM single-pass interferometry data, and they are now working on the software for the Surface Water and Ocean Topography single-pass interferometry data.
I am not one of the ISCE developers, but I think they never intended to support repeat-pass DEM generation because it is a lot of work for not very accurate results. I worked with them a year or so to see if they could develop the code to make DEMs from the TerraSAR-X/TanDEM-X bistatic pairs that avoid the atmospheric changes, but the way that the DLR processes their Coregistered SLC (CoSSC) products makes the geometry quite complicated, and they were busy with other tasks so they could not devote much time to it.

[EJFielding]

I think I used ERS Tandem DEMs for all these papers:
Fielding, E. J., T. J. Wright, B. E. Parsons, P. C. England, P. A. Rosen, S. Hensley, and R. Bilham (1999), Topography of northwest Turkey from SAR interferometry: applications to the 1999 Izmit earthquake geomorphology and co-seismic strain, Eos, Transactions, American Geophysical Union, 80(46), F672.
Berberian, M., J. A. Jackson, E. Fielding, B. E. Parsons, K. Priestley, M. Qorashi, M. Talebian, R. Walker, T. J. Wright, and C. Baker (2001), The 1998 March 14 Fandoqa earthquake (Mw 6.6) in Kerman province, Southeast Iran: Re-rupture of the 1981 Sirch earthquake fault, triggering of slip on adjacent thrusts and the active tectonics of the Gowk fault zone, Geophys. J. Int., 146(2), 371-398, doi:10.1046/j.1365-246x.2001.01459.x.
Wright, T., E. Fielding, and B. Parsons (2001), Triggered slip: Observations of the 17 August 1999 Izmit (Turkey) earthquake using radar interferometry, Geophysical Research Letters, 28(6), 1079-1082, doi:10.1029/2000GL011776.
Fielding, E. J., B. Parsons, T. Wright, and R. Walker (2002), Aseismic slip on a shallow thrust imaged by SAR interferometry: the Shahdad thrust, SE Iran, Eos, Transactions, American Geophysical Union, 83(47), Fall Meet. Suppl., Abstract G62A-07.