[Proj] Is egm08_25.gtx misplaced half a pixel?

[Mikael Rittri]

Thanks, Noel. That's what I thought. 

I am still not sure what's going on, but I have opened a ticket:

http://trac.osgeo.org/proj/ticket/126

Mikael Rittri
Carmenta
Sweden
http://www.carmenta.com

14 okt 2011 kl. 21:28 skrev "Noel Zinn (cc)" <ndzinn at comcast.net>:

> Mikael,
> 
> 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:
> 
> Und_min2.5x2.5_egm2008_isw=82_WGS84_TideFree
> 
> 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.
> 
> Noel
> 
> Noel Zinn, Principal, Hydrometronics LLC
> +1-832-539-1472 (office), +1-281-221-0051 (cell)
> noel.zinn at hydrometronics.com (email)
> http://www.hydrometronics.com (website)
> 
> -----Original Message----- 
> From: Mikael Rittri
> Sent: Wednesday, October 05, 2011 8:23 AM
> To: proj at lists.maptools.org
> Subject: [Proj] Is egm08_25.gtx misplaced half a pixel?
> 
> 
> Hello,
> 
> I have tried to use the geoid height file
> 
>   http://download.osgeo.org/proj/vdatum/egm08_25/egm08_25.gtx,
> 
> which is discussed here:
> 
>   http://trac.osgeo.org/proj/wiki/VerticalDatums
> 
> But I am beginning to think that the file is misaligned
> (well, at least if ones uses GDAL 1.8 or later to read it).
> 
> From gdalinfo (version 1.8.1), I get
> 
>  Origin = (-180.041666666666660,90.041666666666686)
>  Pixel Size = (0.041666666666667,-0.041666666666667)
> 
> But I think the correct origin of the data is really
> 
>           (-180.020833333333333,90.020833333333333)
> 
> that is, half a pixel farther east and south.
> 
> 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 = POINT changed.
> 
> http://trac.osgeo.org/gdal/wiki/rfc33_gtiff_pixelispoint
> 
> Or maybe the cause is something else.
> 
> Some evidence: I have used the gtx file to look up the geoid
> height (using a Carmenta Engine version that uses GDAL 1.8.1),
> at a position where the geoid slopes towards southeast,
> 
>    145dE 13dN
> 
> and I found the value 44.925678 m.
> 
> But according to Charles Karney's online geoid calculator
> http://geographiclib.sourceforge.net/cgi-bin/GeoidEval
> the value should be 45.7529 m (with a few millimeters
> uncertainty, perhaps).  So the difference is 0.8272 m. On the
> other hand, if I move the position half a pixel = 1.25 arc
> 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
> (from http://geographiclib.sourceforge.net/html/geoid.html) says
> 
> Origin = (-0.020833333333333,90.020833333333329)
> Pixel Size = (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
> the longitude range being 0 to 360 in this file).
> 
> I guess I could file a ticket, but I am not quite convinced
> that I am right.  Has anyone else noticed any problems with
> the gtx file?
> 
> 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
> for 180dE. That would make it simpler to interpolate results for
> a position slightly west of 180dE.
> 
> Regards,
> 
> Mikael Rittri
> Carmenta
> Sweden
> http://www.carmenta.com
> 
> _______________________________________________
> Proj mailing list
> Proj at lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/proj 
> 
> 
> _______________________________________________
> Proj mailing list
> Proj at lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/proj