Hi, EPSG:4326 is a 2D system. I do not know if the result from the following using WGS84 3D CRS as input is right, but at least is does change the heigth.
gdaltransform -s_srs EPSG:4979 -t_srs EPSG:4326+5773 20 60 20 60 -18.6147727966309 -Jukka Rahkonen- ________________________________________ Lähettäjä: gdal-dev käyttäjän Starms, William (MU-Student) via gdal-dev puolesta Lähetetty: Maanantai 31. maaliskuuta 2025 3.57 Vastaanottaja: gdal-dev@lists.osgeo.org Aihe: [gdal-dev] Ellipsoid-geoid offsetting and compound SRS Hello all, I’ve recently learned I’ve been using my elevation dataset wrong and could use some expert tips. I’m using ASTERv3 as my DEM source and that’s defined relative to EGM96. I’ve been using OSSIM for orthorectification and it turns out I configured that correctly by accident. I tried building a VRT that summed my ASTER and EGM96 VRTs but it seems that the only way to do this was using embedded python which feels like overkill (not to mention my python version selection issues). I’d like to avoid this method. I found a few references to EPSG:4326+5773 but couldn’t get it working in any of the combinations I tried. I set the SRS during VRT build and it produces a VRT with three axes which seemed off; gdallocationinfo on the VRT returns the ASTER height uncorrected. Looks like this was the wrong way to do it. Neither “gdaltransform -s_srs EPSG:4326 -t_srs EPSG:4326+5773” nor the reverse gave the EGM96 offset. gdalsrsinfo gives this proj string: “+proj=longlat +datum=WGS84 +geoidgrids=us_nga_egm96_15.tif +geoid_crs=WGS84 +vunits=m +no_defs” so I tried that (with the full path to the EGM file) as well and didn’t get anywhere. I found an old ticket comment of Even’s (hi 😊) that seems to suggest what I’m trying should work https://trac.osgeo.org/gdal/ticket/5648#comment:1 but I couldn’t get debug logging working with CPL_DEBUG to see if anything was failing in the backend. I’m using the 3.10.2 ubuntu full container, so there shouldn’t be any proj file lookup issues and none were printed. Alternatively, offsetting the ASTER tiles manually includes an int16->float32 conversion so the dataset doubles in size which I don’t love, but disk is cheap. I could truncate for +-0.5m error, but I’d rather have a larger dataset than a less correct one. I’m curious if anyone has thoughts on supersmapling EGM96 the ~900 times to match ASTER’s resolution as it feels like such a jump would have important nuances. In my tests so far I’ve just used bilinear interpolation. Eager to hear what others think! Will _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
