Using External DEM 10x10m

Dear all.

I have used external DEM 10x10m in the SNAP S1 Toolbox for InSAR processing, but it always failed.
The data that I use (Sentinel-1A images and external DEM 10x10m) already same coordinate system.
Is anyone know why I always failed to process it?
Is it because the data that I use have different spatial resolution?

Thanks!
Ramadhanis, Zainab.

Could you describe the steps on how to reproduce the problem? Thanks

steps that I followed:
open product (master and slaves), split, deburst, subset area, coregistration, interferogram formation and topographic phase removal. In topographic phase removal, I choose external DEM. Then, the process was error.

as far as I understood it the DEM should be projected in WGS84 (geographic coordinates) only.

Dear colleagues, I face the same problem with external DEM. Working with external pieces from SRTM and ASTER the results is fine, but with the external one I have the result is black images in all bands. Before start I followed the recommendations to use WGS84 - no luck. Any comment/experience is welcome.

Thank you.
Hristo

How did you reproject to WGS84?

As I mentioned I reprojected into WGS84 before start the processing.

yes, I meant using which tool, which resampling, which other parameters?

Dear Andreas,
Thank you for reply. For the case I report here I’d like to use DEM having 10x10m spatial resolution. The file was reprojected in QGIS and works fine there and with other software too.
One possibility for this issue could be the small area covered by this DEM. Could you advise please.

Best regards.
Hristo

this still doesn’t answer my question :slight_smile:

How did you do it in QGIS? This is essential because there are some error sources I could think of.

Dear ABraun, sorry for the delayed reply. In QGIS I used Raster->Projections->Warp dialog and setting appropriate parameters -tr switch. After processing I got 30x30m file and worked fine with SNAP.
Actually the problem was the size of DEM tiles (4x4 km). I started with only two tiles (32 sq.km) and it didn’t work, but getting more (12 - 192 sq.km) it worked fine even without reprojection.

I have similar problem, I also mentioned it in here, Source of the post

The tiles cover the AOI have been downloaded from here source :https://tiedostopalvelu.maanmittauslaitos.fi/tp/kartta?lang=en

Both are opened in QGIS and then exported as geotiff WGS84 (geographic coordinates) and mosaic both tiles, Would you please to bring my attention to any not correct step!

The problem is, the slave is empty aftermath corr.

I tested the workflow for your data and it seems to work:

My guess is that the reprojection of the 2m DEM data to WGS84 has not been correct and now SNAP treats it somehow wrong.
As the elevation data is a asc file with no metadata you have to make sure that you select assign the correct coordinate reference system (UTM 35 N) before you reproject.

Edit: It took 135 minutes (16 GB RAM) but it worked. The upper image is with topographic phase removal based on the 2m DEM, the second is without.

2 Likes

Thanks a lot, but it seems for me stacked in QGIS, I did two times, but same results. Would you please to clarify the steps of QGIS, because I reproject it in both cases but slave is still empty.

no matter what QGIS thinks about the projection of the data (it assumes WGS84 after loading, but it is not), you have to select the correct UTM zone in the reprojection module (here it is 35N) as the source CRS and WGS84 as the target reference system.

1 Like

I did exactly same before and now , but still the slave is empty, I’ll send you the DEM, and both S1 identifier, as private message, hope you have time, many thanks in advance. I also tried up 10 m *asc,. but still similar empty slave. But using GETASS30 autodownload, there is no problem.

just for clarification: After which step is the slave empty?
First I thought you wanted to use the 2m DEM for the topographic phase removal (because this was the problem in the topic you linked).
I don’t think it makes sense to use a 2m DEM for the back-geocoding of S1 SLC data. Especially if the covered area is much smaller than the S1 data. Use GETASSE30 and it works.

1 Like

Both tiles of the DEM covers the only first burst, which covers the AOI, The slave is empty after TOPSAR corr. GETASSE30 works, but doesn’t implement the demand, I explained to you, the goal only to test the DEM for the further processes.

if the coregistration was completed, you could still use the 2m DEM in later steps. Or do I miss your point?

Do you think preparing data to StaMPs, the tested DEM - 2 m, could be use, though the slave image is empty, throughout the single corr. (only two images)?

The corr. , is completed perfectly, but getting an empty slave, points out to problem, even the DEM covers the one burst of AOI.