Errors in datum shift?
Gerald I. Evenden
gie at charon.er.usgs.gov
Wed Aug 18 12:35:31 EDT 1993
>From: courtney at agcrr.bio.ns.ca (Bob Courtney)
>Subject: Errors in datum shift?
>To: grassu-list at max.cecer.army.mil
>Date: Tue, 17 Aug 93 18:16:01 ADT
>I seem to be getting an error when trying to shift UTM data in zone 8
>from GRS80 to CLARK66. I convert the points using the command :
>m.u2ll spheroid=grs80 zone=8 <in.txt | m.ll2u spheroid=clark66 zone=8 >
The first problem with the above statement is that there is no indication
of datum shift. We cannot simply convert UTM to lat-lon in one ellipsoid
and lat-lon to UTM in another. There should be at least a Molodensky
conversion (a coarse method with accuracy not much better than +-25m) or
the equivalent of NADCON tabular conversion. But since the example
under discussion lays outside the US, NADCON usage is not advised even
though the Alaska zone may cover this point.
>The results do not agree with shifts given by an internal calculator on
>our GPS receiver (Magellan Pro 5000 ) and a PC based program called
>"Geographic Calculator" ( which agree with each other). For example, an
>input coordinate : 529006 E 7729798 N
>shifts to the output position : 529124.6E 7729614.7 N
>using the GPS and Calculator method.
Assuming the input coordinate is in NAD83, then:
proj +proj=utm +ellps=GRS80 +zone=8 -I -o <<EOF | \
proj -i +proj=utm +ellps=clrk66 +zone=8
will yield the non-datum corrected value of:
with a delta northing/easting of 1.27 and -176.68 m respectively.
Again, this is NOT the correct value, but illustrative of the effects
of the different ellipsoid factors on the projection computations.
Using the NADCON Alaskan table, again this is not kosher, the datum
correction is: 0.16569" and -9.32302" for respective latitude and
longitude or -100.431 and 5.134 m for respective easting and northing.
To compress the above operations:
nad2nad -i 83,utm=8 -o 27,utm=8 -r alaska <<EOF
which results in:
A fully corrected delta of 101.59 and -170.31 m for respective
easting and northing.
Using the Molodensky method (DMA's madtran), the following NAD27 values
529109 7729626 with repective error estimates of +- 7 and 6 m.
These numbers agree pretty will with the Alaskan table.
>The GRASS command returns 529007.2E 7729621.3N for the same input
>( difference of ~120m in easting and ~7 m in northing )
>The alpha command "m.proj" gives yet another result for the same input
> in : 529006.0 E 7729798.0 N out: 529006.4 E 7729934.0 N
> ( difference of ~120 in easting and a whopping 320 m in northing )
>Has anyone noted these type of errors before? Are there any answers
>that explain these discrepancies?
>Atlantic Geoscience Centre
>Bedford Institute of Oceanography
>courtney at agcrr.bio.ns.ca
I can't speak for your DOS program nor the GPS unit, although they seem
to be in the ballpark. But I do not think you have correctly applied
the GRASS software because I believe they *do not* include datum
correction software. I have repeatatively tried to warn people that
simply changing ellipsoid parameters DOES NOT change datum. This
is a good example.
The issue of correctly converting data between datums is recurrent and
there are no global solutions. Nad2nad will be able to handle US
data reasonably well, but many areas do not have anything better than
Program nad2nad is not vaporware, as you can see, and will be available
shortly one reasonable documentation is available.
Gerald (Jerry) I. Evenden Internet: gie at charon.er.usgs.gov
voice: (508)563-6766 Postal: P.O. Box 1027
fax: (508)457-2310 N.Falmouth, MA 02556-1027
More information about the grass-user