Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DEM format requirements / Reproducible example #40

Open
maawoo opened this issue Aug 25, 2022 · 2 comments
Open

DEM format requirements / Reproducible example #40

maawoo opened this issue Aug 25, 2022 · 2 comments

Comments

@maawoo
Copy link

maawoo commented Aug 25, 2022

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
Copy link
Member

@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
Copy link
Author

maawoo commented Aug 29, 2022

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 OSGeo/gdal#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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants