Copernicus DEM: built-in path applies EGM96, while the data is EGM2008

The built-in Copernicus 30m / 90m DEM is converted from orthometric to ellipsoidal heights
with EGM96, but Copernicus heights are referenced to EGM2008. This leaves a systematic bias of 2.02 m over the burst evaluated here (1.82 to 2.25 m).

Cause

CopernicusElevationTile initializes EarthGravitationalModel96 and adds its undulation to
every line unless snap.useDEMGravitationalModel is disabled:

egm = EarthGravitationalModel96.instance();
...
line[i] += egm.getEGM(geoPos.lat, geoPos.lon, v);

There is no EGM2008 implementation or selection in snap-engine. Using EGM96 is appropriate for DEMs such as SRTM, but not for Copernicus GLO-30/90, whose Product Handbook specifies EGM2008.

Reproduction

  • Environment: SNAP 13.0.0
  • Burst SLC: 015-030346-IW1, VV, 2022-08-01
  • DEM: Copernicus GLO-30, tiles N46_00_E007_00 and N46_00_E008_00

I processed the SLC to RTC backscatter with Apply-Orbit-FileThermalNoiseRemovalCalibrationTOPSAR-DeburstMultilookTerrain-FlatteningTerrain-Correction, and set saveDEM=true so the product also contains the elevation SNAP sampled.

I ran three experiments, which differ only in the DEM given to Terrain-Flattening and
Terrain-Correction:

  1. demName=Copernicus 30m Global DEM
  2. demName=External DEM, externalDEMApplyEGM=false, converted to ellipsoidal heights with EGM96 (wrong on purpose)
  3. demName=External DEM, externalDEMApplyEGM=false, converted to ellipsoidal heights with EGM2008 (correct)

Both external files are the same two GLO-30 tiles SNAP had downloaded itself, from
~/.snap/auxdata/dem/Copernicus 30m Global DEM/, so all three runs start from the same inputs. Both also have their geotransform origin shifted half a pixel, to work around a separate issue affecting every externally supplied DEM, so the geoid is the only difference left.

Results

The elevation SNAP sampled in run 1, minus the two external runs, on the same scale:

difference mean std
built-in − EGM2008 file −2.02 m 0.12 m
built-in − EGM96 file −0.0007 mm 0.0201 mm
EGM2008 file − EGM96 file +2.02 m 0.12 m

The built-in DEM and the EGM96 conversion agree to a hundredth of a millimetre. The remaining bias is exactly the (EGM2008 − EGM96) difference, identifying the geoid as the cause.

On the backscatter, the correct and the wrong geoid differ by 0.67 dB standard deviation, with
15% of pixels beyond 0.5 dB:

Fix

Include EGM2008 in SNAP and select it for the Copernicus DEMs, keeping EGM96 for the DEMs that are referenced to it. At a minimum, document the assumed vertical datum of every built-in DEM.

Workaround

Provide the Copernicus DEM as externalDEMFile instead, converted to ellipsoidal heights with
EGM2008 and with externalDEMApplyEGM=false. However, the external DEM needs separate compensation for the half-pixel-shift issue.

1 Like

@lveci could you please take a look? Thanks!