search

bopen / sarsen

Algorithms and utilities for Synthetic Aperture Radar (SAR) sensors
Apache License 2.0
271 stars 26 forks source link

DEM format requirements / Reproducible example #40

Open maawoo opened 2 years ago

maawoo commented 2 years ago

Hi all, I'm running into issues processing an SLC scene. Both GTC and RTC results are not really usable. I suspect my DEM is the problem and I'm wondering why, because I'm using the same DEM to successfully create an RTC product with SNAP. Here is the gdalinfo output if you're interested.

Can you provide some guidelines on format requirements for the DEM? Or at least a reproducible example in the notebook section. download_data.sh could, for example, be extended by a section that downloads DEM tiles from an open source (e.g., here) and prepares it with GDAL in the way sarsen expects.

Cheers, Marco

alexamici commented 2 years ago

@maawoo any DEM supported by GDAL / Proj is supposed to work, as long both horizontal and vertical reference systems are specified.

As you don't provide details on what unexpected behaviour you see, I'll guess you are hitting the most common problem, that is: the DEM height has a different reference than the ellipsoid in the horizontal CRS.

As an example, you can see in line 8 of download_data.sh how I override the CRS specification of the SRTM DEM -s_srs EPSG:4326+5773 where the +5773 instructs Proj that the reference height is the EGM96 geoid.

maawoo commented 2 years ago

Thanks for your help @alexamici! I'm using the Copernicus 30m DEM (EGM2008 reference height), which has been converted to WGS84 ellipsoid heights in a very similar way that you pointed out (-s_srs EPSG:4326+3855 -t_srs EPSG:32632), so I think my DEM should be fine.

[...] I override the CRS specification of the SRTM DEM [...] where the +5773 instructs Proj that the reference height is the EGM96 geoid

From your description it sounds like the vertical heights of the DEM are supposed to stay the same and that only information about the reference height is added. Just to be clear (also for anyone stumbling over this issue), gdalwarp -s_srs EPSG:4326+5773 -t_srs EPSG:32616 is transforming/correcting the DEM to WGS84 ellipsoidal heights. See also https://github.com/OSGeo/gdal/issues/4566 for a good visualization of the difference between EGM96 and WGS84. But I guess that's what you meant?

Regarding my problem, which I'm happy to move to another issue if you want: An output raster is created (gdalinfo) but it completely breaks my QGIS if I want to take a quick look at it. The Computed Min/Max=0.000,inf might be related? There are some warnings during processing (see here). Maybe you can take a look and see if anything is unusual? I can also provide the DEM and SLC I'm using.