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 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.
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!
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.