I want to create an interferogram from an TanDEM-X CoSSC dataset I just received. I also marked the “subtract topographic phase” and provided my laser DTM of 1m resolution for the region. The error occurring is
“The resolution of the selected DEM is too low, please select DEM with higher resolution”.
I have tried:
-to convert the DTM to lat-lon (epsg: 4326), since this has been an issue in the past.
-tried 60, 80, 100% tile extension
-SRTM 3 sec autodownload
with all of them causing the same error message.
If I simply skip the “subtract topographic phase”, the interferogram generation works just fine.
Does anyone have experience of this? Ping @ABraun @mengdahl
best regards, Henrik
Have you tried the SRTM 1ArcSec Autodownload as well? Its spatial resolution is 30m instead of 90m, still way larger than the TanDEM-X data.
One work-around is to manually download the SRTM files, create a mosaic and resample it to 5 m spatial resolution (bilinear at best). The quality of the topographic phase remains the same but at least SNAP takes it as an input.
Thanks @ABraun, it did work with the SRTM 1ArcSec. The challenge remained why this appeared with my laser DTM. However, I made progress by resampling the 1m laser DTM to 5m DTM (same projection). This DTM was now accepted by SNAP. I could even resample this 5m DTM to epsg 4326, and SNAP accept that one as well. (this improves the processing time for the interferogram generation greatly)
I don’t know why this was accepted, but the error message by SNAP probably has to be more specific in order for the user to understand what the requirements are.
In fact in the past I have found similar issue with other software (i.e. DORIS) for which high resolution DEMs which should be later interpolated to put it in radar coordinates where giving errors by the software, being just a matter or too much data to handle?
Not sure it could be the same issue here, but probably it is worth investigating as high resolution data and DEMs are more and more used nowadays…
I have an even stranger thing with this error (The resolution of the selected DEM is too low, please select DEM with higher resolution) :
I have a 90m resolution DEM in geotiff format.
When performing S1-TOPS-Coregistration then Interferogram Formation with removing of topographic fringes, everything is ok.
When writing it in a graph and using it in gpt, I have the error. The DEM is strictly identical. I really don’t understand. And the strangest thing is that for some pairs, I have no issue (for 21 pairs out of 37) but for 16 out of 37, I have this error. No comprendo
Stack_Intf.xml (5.5 KB)
My images are :
Did you find out any solution for this problem, I’m using an external DEM *geotiff with 2 m resolution,
Now the problem is, the slave is empty after corr.
From my experience, DEMs with 2m resolution brings processing issues (software related). In the past what worked for me was to undersample it to 10m resolution. This happened also in the past with DORIS software.
Not sure if things had changed since then.
Let me know if this helps
Thanks a lot Jose, actually the 10 m is also available, I’d give trial for it, But, Do you think 10 m resolution DEM could properly be used to subtract the topographic phase of an object length (1,045 m)?
Also other question please, (I didn’t try up an old version matlab with StaMPS) So does Matlab 2010b affect the processing? , Because this is the only free I could get, and now I’m in installation step!
Not sure such high-res SAR data is processable with SNAP.
TerraSAR-X or CosmoSkyMed both in stripmap mode, their resolution is 3m approx. …
SNAP is or was not ready for spotlight data explotation
I agree with you than DEM and SAR resolution should be similar, but if you get software issue you should get a good compromise. Obviously 3m SAR data with 90m DEM is not the best solution. But 3m vs 10m is not that far
I got the same error for my external DEM (geotiff). In my case, this DEM worked with the backgeocoding step but not with the interferogram step and I gave each output different names to those proposed by default (i not 100% sure if changing names can affect)
I used it in a previous processing for the same area but different dates and it worked.
This makes me think that, as “mdelgado” says, it can be a software issue, or rather, as occurred to me with other software errors, some input data were erroneous. So, as I did with other errors that Snap threw me, I repeated the previous basic steps, starting from Back Geocoding, and it didn’t work. Then I decided to start from the first step (split, then orbit…and so on) in a new and empty folder (in the previous one I had other snap outputs), and the software worked fine.