Orthorectfication using WorldDEM Neo's DEM GeoTIFF fails

OTB Usage
1

Hallo,

I have been trying to use OTB’s Orthorectification to create an ortho product for a Pléiades image.I am using as DEM a WorldDEM Neo data set delivered as a GeoTIFF using the EGM2008 datum.

Here is the otbcli_OrthoRectification output:

2023-02-01 13:13:45 (INFO) OrthoRectification: Elevation management: setting default height above ellipsoid to 0 meters
2023-02-01 13:13:45 (INFO): Loading metadata from official product
2023-02-01 13:13:45 (INFO) OrthoRectification: Elevation management: setting default height above ellipsoid to 0 meters
2023-02-01 13:13:45 (INFO) OrthoRectification: Elevation management: setting default height above ellipsoid to 0 meters
2023-02-01 13:13:45 (INFO): 1 DEM found in ../../airbus-elevation_a013f62e-5123-42a7-9591-7ef852892a31.tiff
2023-02-01 13:13:46 (INFO) OrthoRectification: Elevation management: using DEM directory (../../airbus-elevation_a013f62e-5123-42a7-9591-7ef852892a31.tiff)
2023-02-01 13:13:46 (FATAL) OrthoRectification: Caught std::exception during application execution: GDALRPCTransform was not able to process the ForwardTransform.

Now, I am able to do it using gdalwarp with this DEM, but I would like to see if there are any differences using OTB instead of gdalwarp.

I am using OTB 8.1.1 on an Intel based Mac. The MacOS version is Monterey 12.5,

Here is the gdalinfo output for the DEM file:

Driver: GTiff/GeoTIFF
Files: ../../airbus-elevation_a013f62e-5123-42a7-9591-7ef852892a31.tiff
Size is 1970, 1516
Coordinate System is:
COMPOUNDCRS["WGS 84 + EGM2008 height",
   GEOGCRS["WGS 84",
       DATUM["World Geodetic System 1984",
           ELLIPSOID["WGS 84",6378137,298.257223563,
               LENGTHUNIT["metre",1]]],
       PRIMEM["Greenwich",0,
           ANGLEUNIT["degree",0.0174532925199433]],
       CS[ellipsoidal,2],
           AXIS["geodetic latitude (Lat)",north,
               ORDER[1],
               ANGLEUNIT["degree",0.0174532925199433]],
           AXIS["geodetic longitude (Lon)",east,
               ORDER[2],
               ANGLEUNIT["degree",0.0174532925199433]],
       ID["EPSG",4326]],
   VERTCRS["EGM2008 height",
       VDATUM["EGM2008 geoid"],
       CS[vertical,1],
           AXIS["gravity-related height",up,
               LENGTHUNIT["metre",1]],
       ID["EPSG",3855]]]
Data axis to CRS axis mapping: 2,1,3
Origin = (-104.928479166666676,39.837395833333332)
Pixel Size = (0.000041666666667,-0.000041666666667)
Metadata:
 AREA_OR_POINT=Area
Image Structure Metadata:
 COMPRESSION=LZW
 INTERLEAVE=BAND
 PREDICTOR=3
Corner Coordinates:
Upper Left  (-104.9284792,  39.8373958) (104d55'42.53"W, 39d50'14.63"N)
Lower Left  (-104.9284792,  39.7742292) (104d55'42.53"W, 39d46'27.23"N)
Upper Right (-104.8463958,  39.8373958) (104d50'47.03"W, 39d50'14.63"N)
Lower Right (-104.8463958,  39.7742292) (104d50'47.03"W, 39d46'27.23"N)
Center      (-104.8874375,  39.8058125) (104d53'14.78"W, 39d48'20.93"N)
Band 1 Block=256x256 Type=Float32, ColorInterp=Gray
 Unit Type: metre

I would appreciate if you could help me sort out the issue with this.
Merci d’avance.

2

Hi,

As of OTB 8, GDAL handles the DEM internally so OTB should act equally with gdal, as it uses it to open the DEM. I don’t know about this DEM, is it downloadable with a free account somewhere ? In order to test it, I already have pleaides images that we use for validating OTB

Best regards

3

Salut Thibaut,

I uploaded the DEM file referenced to the ellipsoid here: Wormhole - Simple, private file sharing

The image I am using for this comes from the Airbus demo datasets: Sample Imagery Detail

Please let me know if you need anything else.

Thank you.

PS: According to Arbus the DEM is too fine but that isn’t the issue here. It works with gdalwarp, albeit with some small distortions relative to the ortho product from Airbus.