No subject

Mon Jun 6 10:06:03 EST 2011

  Origin =3D (-180.041666666666660,90.041666666666686)
  Pixel Size =3D (0.041666666666667,-0.041666666666667)

But I think the correct origin of the data is really


that is, half a pixel farther east and south.=20

I suspect this may be caused by the nasty AREA_OR_POINT issue.
The file is dated 3 Sep 2010, so I guess it was created before
GDAL 1.8, when the semantics of AREA_OR_POINT =3D POINT changed.

Or maybe the cause is something else.

Some evidence: I have used the gtx file to look up the geoid=20
height (using a Carmenta Engine version that uses GDAL 1.8.1),=20
at a position where the geoid slopes towards southeast,=20

    145dE 13dN

and I found the value 44.925678 m. =20

But according to Charles Karney's online geoid calculator=20
the value should be 45.7529 m (with a few millimeters=20
uncertainty, perhaps).  So the difference is 0.8272 m. On the=20
other hand, if I move the position half a pixel =3D 1.25 arc=20
minutes east and south, that is

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

then Charles's calculator gives me 44.9287 m, so the difference
is now just 3 mm from the gtx result for the original position.

More evidence: gdalinfo on Charles's file egm2008-2_5.pgm=20
(from says

Origin =3D (-0.020833333333333,90.020833333333329)
Pixel Size =3D (0.041666666666667,-0.041666666666667)

so its origin is, indeed, half a pixel farther east and south
(well, there is a also 180 degree longitude difference due to=20
 the longitude range being 0 to 360 in this file).=20

I guess I could file a ticket, but I am not quite convinced=20
that I am right.  Has anyone else noticed any problems with
the gtx file?=20

Another issue with the gtx file: I would have preferred if it had
one more column; that is, if the column for 180dW was repeated=20
for 180dE. That would make it simpler to interpolate results for
a position slightly west of 180dE. =20


Mikael Rittri

More information about the Proj mailing list