The gtx files for EGM2008 and EGM96 are misplaced half a pixel.
|Reported by:||mikrit||Owned by:||warmerdam|
The gtx files for EGM2008 and EGM96 at http://download.osgeo.org/proj/vdatum/ are misplaced.
The cause seems to be some typos in the python scripts that generate them. In egm96togtx.py, the line
ds_gtx.SetGeoTransform( (-180.25,0.25,0,90.125,0,-0.25) )
should have been
ds_gtx.SetGeoTransform( (-180.125,0.25,0,90.125,0,-0.25) )
As it is now, the egm96_15.gtx is georeferenced half a pixel too far west.
And in egm08togtx.py, the line
ds_gtx.SetGeoTransform( (-180 - ps_25,ps_25,0,90 + ps_25,0,-1 * ps_25) )
should have been
ds_gtx.SetGeoTransform( (-180 - 0.5*ps_25,ps_25,0,90 + 0.5*ps_25,0,-1 * ps_25) )
As it is now, the egm08_25.gtx is georeferenced half a pixel too far west and north.
I would also appreciate if the gtx files had one more column. That is, the column for 180 W should be repeated as a column for 180 E, since this would make it easier to interpolate the geoid height for a position slightly west of 180 E.
A useful test point is
since the geoid is unusually steep there (as these things go). The geoid heights at this point, according to some online geoid calculators, should be
|EGM2008||45.7529 m||(not available online)|
|EGM96||45.7806 m||45.78 m [b]|
|EGM94||45.3232 m||45.33 m [c]|
When I used the egm08_25.gtx file in Carmenta Engine, I got the geoid height 44.925678 m instead. This is 0.83 m from the correct value, but it is only 3 mm from the Karney EGM2008 value for the position
which is half a pixel farther east and south. So, this confirms the hypothesis that egm08_25.gtx is displaced half a pixel towards west and north.
I haven't tried the egm96_15.gtx file, but I predict that its value for the test point 145dE 13dN is near 43.9941 m, since this is the EGM96 geoid height that Karney's calculator gives for the position 145d07.5'E 13dN, half a pixel east of the test point.