[Gdal-dev] (no subject)

Frank Warmerdam warmerdam at pobox.com
Mon Oct 16 17:20:22 EDT 2006

Peter.Rushforth at statcan.ca wrote:
> Hello,
> I have been working with ogr2ogr and its built in projection
> facility.  I notice what I think is some slight
> coordinate drift ( less than a metre) when projecting
> from lambert to NAD83 and back again.  I wonder 
> if this is a result of single-precision coordinate 
> representation in the projection engine?  Is there a 
> way to request double precision usage in the system, or
> perhaps to build it in at compile time?


I tested a point in California using the following commands (testepsg is
a testing app that can be build by cd'ing into gdal/ogr and doing "make

warmerda at gdal2200[806]% testepsg -t '+proj=utm +zone=11 +datum=NAD27' 
'+proj=utm +zone=11 +datum=NAD83' 440720 3751320
(440720.000000,3751320.000000,0.000000) -> (440639.480881,3751516.308207,0.000033)

warmerda at gdal2200[807]% testepsg -t '+proj=utm +zone=11 +datum=NAD83' 
'+proj=utm +zone=11 +datum=NAD27' 440639.480881 3751516.308207
(440639.480881,3751516.308207,0.000000) -> 

This seems to indicate that datum shifting going through the OGR
facilities is preserving roughly six decimal places of accuracy when
going forward and back again.

Could you provide a specific example of a point and what values
you got for each step of the round trip (before, once, and then
back again).

The above example is using the "conus" files.  Perhaps you had a
problem in an area using NTv1 or NTv2 files?

I'd add that positions in OGR and PROJ.4 are carried around as
double precision.  The offsets read from the grid shift files
are likely in other formats (single precision, or some form of
integer form).

Best regards,
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGeo, http://osgeo.org

More information about the Gdal-dev mailing list