I am currently working on time series data of ERS 1/2, Envisat and Sentinel 1. I am working on glaciers so I need to use offset tracking and convert the phase to height and displacement. I have processed correctly and got desired results in case of ERS1/2 and Envisat data. The problem came when I used Sentinel 1 data. The co registered slave image is always a blank black image with no value. I thought the problem is with the datasets, I changed the products with different baselines but also same happened. Further I tried to use the tutorial to use the sample data.
I believe that there should not be any error for this data-sets, as the experiment is verified. Is there any problem with the version of SNAP, I am using 6.0. See the images, I used the same dataset as given in tutorial.
please update your SNAP installation:
I tried but results are same. I tried both from Macbook and Windows.
The granules for my study are as follows, I tried all.
Can you check what is the problem.
I have chosen small perpendicular baseline for converting phase to displacement.
i have the same problem.
it appears when the master follows the slave.
in my case the master is 20190220 and the slave 20190208. If i invert the pair all works.
i use the latest version of SNAP and all my plugins are upgraded on Ubuntu 18.04.
also @maxdragonheart has a similar problem.
You can try using :
let me know.
is there a reason why you don’t work with the inverted pair then?
Generally, I would recommend the SRTM 1Sec DEM in the BackGeocoding step (instead of the predefined 3Sec) and use the TOPS coregistration with ESD.
you might use one or the other, according to your needs and software must work always, without problems. in this case, i used these images only for tests.
indeed, if i use srtm1m back geocoding works, but doesn’t mask sea area.
There’s something wrong. In SNAP 6.0 beta version there aren’t problem.
Thank you, it worked well. I tried SRTM 1sec DEM.
A very low resolution DEM like GETASSE30 is perfectly fine for TOPS coregistration and saves download time. Going to higher resolution gives no benefit.
I agree, but it reportedly solved problems with the download of SRTM90 in several cases.
My point was that changing the DEM source can narrow down the problem.