S1A_IW_SLC__1SDV_20191202T172140_20191202T172209_030172_0372A8_12F7 IW1 VV Burst 7
S1A_IW_SLC__1SDV_20191214T172139_20191214T172209_030347_0378B5_B5C1 IW1 VV Burst 7
S1A_IW_SLC__1SDV_20191207T172936_20191207T173005_030245_037531_8DEC IW3 VV Burst 3
S1A_IW_SLC__1SDV_20191219T172935_20191219T173005_030420_037B3F_0FB0 IW3 VV Burst 3
There’s White Island, New Zealand and a lot of sea in those. It’s always the slave causing the problem, no matter which of them I use.
I have downloaded the first pair, applied Split (IW1, burst 7), Orbit file, BackGeocoding (SRTM 1Sec), intererogram generation, debursting and multi-looking / filtering (just for visualization purposes) and this is the result:
I wonder what is different in your case.
You said you had done the BackGeocoding manually and in batch - what do you mean with it?
Thanks for your reply!
I found a post somewhere that some people could not get the function to work if they used it from the menu, as a single function, but that it worked as part of a processing tree in batch processing. I don’t know how it would make a difference, but tried it anyway to no avail.
I used some scenes nearby from a different date a week ago and that worked perfectly, the results were just very boring. So I wanted to try the eruption of White Island in December. I can see the island in the bursts from my last posts, so it’s not empty, and the SRTM is available for that place. But somehow the slave is never written properly.
I understand, there is the “S1 TOPS Coregistration” module which combines all necessary steps. But it is very memory consuming, so I prefer to execute the single steps.
It could be that if the slave largely differs from the master because of the eruption, the standard BackGeocoding fails. But I have never seen it. Are you using the latest version of SNAP with all updates installed?
There’s no visible change in the volcano in Sentinel-2 images at least. I know it doesn’t mean much just seen from above, but at least there’s no major change, no missing flank or anything. The local GNSS site doesn’t show anything out of the ordinary, either, so the island hasn’t suddenly moved a couple meters. There is a visible difference in intensity between the individual scenes but nothing drastic. It shouldn’t matter that most of it is sea, should it? There’s a tutorial using some larger islands so I didn’t expect this to matter.
I reinstalled SNAP over this yesterday and updated it and it says it’s up to date. So are my drivers and operating system.
I cannot reproduce this error, sorry.
Thanks for trying 
In another topic we found out that the orbit file which was downloaded decreased the quality of the data.
Comparing the baselines before and after application of the orbit files could be worth a try: Coregisteration is not correct!
I had installed the latest version of SNAP but S1 TOPS Coregistration, doesn’t seem to work can anyone help me how to rectify this issue
we need more information
I had kept for coregistration process 2 days ago of pre and post images but in the process bar it is showing only 1%, there is no further movement in process.
please select SRTM 1Sec HGT instead of SRTM 3Sec in the BackGeocoding step because the source of the latter has changed and SNAP is currently not able to access it.
More on this here: SRTM ZIP-files are corrupted or not found
Thank you very much it is working
What operator are you referring to?
After terrain correction with 1Sec DEM, the displacement will still have values in the sea area.
I used the raster>masks to mask out the sea before, but now it doesn’t work due to the 3Sec.
So I am wondering if there is an alternative.
actually, the terrain correction operator should be able to remove the sea areas as well (this is set by default).
As an alternative yeu can select DEM as an additional output and then use the valid pixel expression to remove pixels below a certain elevation of the SRTM 1Sec manually.
But I remembered that the sea areas cannot be masked out when using 1sec in terrain correction?
And I did try many times and never succeed before.
maybe these sea areas are not 0 in the SRTM 1Sec
So please set it as an output and check the elevation values at this area. You can then use this for masking.
Oh! Thank you!
I will try it later!
