0

After having some trouble understanding the height reference in SRTM data cropped by elevation Python package, I checked the SRTM guide which states the following:

The unit of elevation is meters as referenced to the WGS84/EGM96 geoid I am having difficulties with this sentence:

  1. Assuming I read it as "WGS84 geoid OR EGM96 geoid", then why is WGS84 called a "geoid"? AFAIK is NOT a geoid but rather an ellipsoid that approximates a geoid.

  2. If the data actually contains two sets of data - one referencing WGS84 and the other referencing EGM96, then why does the elevation library only produce tiff files with reference EPSG4236 (WGS84)? How do I create a tif with the EGM96 reference frame?

How do I understand this sentence?

  1. SRTM provides data in BOTH references: WGS
Sagi Mann
  • 2,967
  • 6
  • 39
  • 72

1 Answers1

0

So after a lot of hair-pulling, I can only come to the conclusion that elevation writes the wrong CRS inside the file.. We've checked the ellipsoid height at that location with two other systems and confirmed that while the .tiff file CRS is labeledd EPSG 4326 with no transformations/translations, it is in fact EGM96 elevations.

So the first thing to get a "real" EPSG 4326 tiff file, I had to force it to believe its current CRS is EGM96 (s_srs arg) and convert it to real EPSG 4326 (t_srs arg) using gdalwrap:

gdalwarp my.tiff my.wgs84.tif -s_srs EPSG:4326+5773 -t_srs EPSG:4326

After that, the CRS of the new tif remains the same as before, but querying for altitudes yields the right WGS84 values.

Sagi Mann
  • 2,967
  • 6
  • 39
  • 72