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!
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.
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.
Hello. I am a new SNAP user. I am attempting to calibrate my SLC products and then co-register them. Unfortunately I am getting an error which indicates I cannot calibrate the products before the co-registration, but calibration also does not work after co-registration. Is there a way around this issue? Thanks.
Please have a look at the tutorials for example ESA InSAR S1 IW to understand how to approach SLC products and which processing steps need to be performed before calibration.
If you are interested there are also a lot of materials from Copernicus Research and User Support (RUS) service that may help you how to process Sentinel-1 data for various applications
