Opened 4 years ago

Closed 15 months ago

#126 closed defect (fixed)

The gtx files for EGM2008 and EGM96 are misplaced half a pixel.

Reported by: mikrit Owned by: warmerdam
Priority: minor Milestone:
Component: default Version: Development (trunk)
Keywords: Cc:



The gtx files for EGM2008 and EGM96 at are misplaced.

The cause seems to be some typos in the python scripts that generate them. In, 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, 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

145dE 13dN

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

Karney[a] NGA
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

145d1.25'E 12d58.75'N

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.

Best regards,


Change History (3)

comment:1 Changed 3 years ago by mikrit

For the record, I'll paste Noel Zinn's comment from the mailing list:

"I can't address the registration issues with egm08_25.gtx that you raise, but egm08_25.gtx would have been derived from this file:


or its little endian equivalent.

I can confirm that the file I cite ranges from -90 to 90 in latitude (every 2.5 minutes, for 4321 "rows") and 0 to 359+57.5/60 in longitude (every 2.5 minutes, for 8640 "columns").

For what it's worth.


(cited from

And by the way, I made a typo in the table: "EGM94" should have been "EGM84" (although NGA calls it "WGS84" on their online calculator site).

comment:2 Changed 3 years ago by mikrit

See also

Charles Karney, "A couple of comments on computing geoid heights",

comment:3 Changed 15 months ago by hobu

  • Resolution set to fixed
  • Status changed from new to closed

I have updated the EGM files at and renamed the old files with a scary filename so that posterity could potentially go back and find them if they ever needed to.

Is there any possibility of writing up the methods used to generate these files so that we can replicate them when future grids are produced?

Thanks so much for digging in on this, and I'm sorry it took so long to attend to it.

Note: See TracTickets for help on using tickets.