#######################################################
Warning
The workflow described in this post (and the ones referring to it later on) is outdated and no longer recommended, because new versions of SNAP and StaMPS have been released. Please have a look at this updated list of instructions: StaMPS - Detailled instructions
#######################################################
Hi all,
Recently SNAP6.0 has been released, and by chance @Mehdi use the “oethorectified lat/long” options to solve his problem. And now I test this method and find that this new option can solve the shift problem and can avoid Terrain Correction (TC) step in PSI. @katherine @annamaria @bayzidul @ABraun
Here is the new Interferogram Formation window in SNAP6.0:
After finish this step, elevation and lat/lon band will be generated in result product.
Start from Deburst step, we get Stack_deb, then create a subset, get Subset_Stack_deb, form interfeorgrams as the first picture showed and get Subset_Stack_deb_ifg. And then use Subset_Stack_deb and Subset_Stack_deb_ifg to export to StaMPS.
And that’s all, all the things have been done. Add Elevation band, geocoded and topo_removal are doing together in interferogram formation step, TC are avoided, lat/lon file can export correctly without saving to GAMMA format.
Here are some results:
1.use SNAP6.preview4 and without TC:
2.use SNAP6.preview4 and TC:
3.use SNAP6.0 oethorectified lat/lon and without TC:
Note: I use different parameters when export to Google Earth, and only about 20% PSs are shown in the picture, so don’t be surprised that PSs location are not exactly the same.
In SNAP6.preview4 or preview5, without TC there are exist shift problem. And use SNAP6.0, shift problem has been solved and TC are no more needed.
Have Fun!
Fei