Even Rouault

Looking at the metadata of the 1' file, I see: ``` AREA_OR_POINT=Point target_crs_epsg_code=3855 TIFFTAG_COPYRIGHT=Derived from work by USA NGA TIFFTAG_IMAGEDESCRIPTION=WGS 84 (EPSG::4979) to EGM2008 height (EPSG::3855) TYPE=VERTICAL_OFFSET_GEOGRAPHIC_TO_VERTICAL ``` compared to...

ok, we could potentially recreate the file from the data and hints at https://geographiclib.sourceforge.io/C++/doc/geoid.html#geoidinst since @cffk is a trusted source for that topic! At first glance, agisoft file seems OK:...

Procedure to generate a GeoTIFF file ranging from ~ -180 to ~ 180 deg longitude from the PGM file which ranges from ~ 0 to ~ 360: ``` gdal_translate geoids/egm2008-1.pgm...

> the file `us_nga_egm08_25.tif` (with 2.5 min step) is 80 MB! yes, because if uses Float32 encoding, whereas the PGM file used for the 1' file uses scaled UInt16 data...

https://grid-partner-share.s3.amazonaws.com/egm2008/Und_min1x1_egm2008_isw%3D82_WGS84_TideFree.gz but there's indeed a permission issue. Anyway I don't think that file is directly usable as it must contain some "harmonics coefficients" or things like that, and that's GeographicLib...

> If I understood the format correctly, this script should convert to gtx (actually the data is pretty similar) cool! I assumed it wasn't a grid... and do you get...

Is there some agreement that the 1.5 mm max difference due to quantization if using a UInt16 data type + offset/scale is acceptable ?

> do we need the version with 1' when we already have it with 2.5'? Taking a few "random" points, when doing bilinear interpolation, the difference between both versions is...

> actually, my issue was that reading a EGM08 vertical datum file via PDAL was returning this message ah, then it is something else... This error is a bit surprising...

> the geotiff keys on the file that triggers the lookup look like This should be reported as a PDAL issue with precise instructions. It might be a PROJ issue,...