[GRASS-user] Determining Datum From Projection Coordinates [SOLVED]

Tom Russo russo at bogodyn.org
Thu Mar 3 15:06:55 EST 2011

On Thu, Mar 03, 2011 at 12:53:04PM -0700, we recorded a bogon-computron collision of the <russo at bogodyn.org> flavor, containing:
> On Thu, Mar 03, 2011 at 06:15:39AM -0800, we recorded a bogon-computron collision of the <rshepard at appl-ecosys.com> flavor, containing:
> > On Wed, 2 Mar 2011, Michael Perdue wrote:
> > 
> > > Hate to be a wet blanket, but both NAD27 and NAD83 UTM coordinates are
> > > supposed to be in meters.
> > 
> > Michael,
> > 
> >    It's been quite a while but I recall data in NAD27 having units of feet.
> This is true of State Plane Coordinate Systems in NAD27, but not UTM.
> FWIW, it looks like since your lat/lons are specified at such low precision,
> the NAD27/NAD83 datum shift might be irrelevant.

Well, maybe I'm wrong about that.  I used the "cs2cs" utility from the proj.4
system to convert the first line of your lat/lons to UTM in both NAD83 and 
NAD27, and in neither case did I get what is in the table for UTM:

> cs2cs +proj=latlong +datum=NAD27 +to +proj=utm +datum=NAD27 +zone=11
-117.31 41.04
473943.57       4543031.77 0.00
> cs2cs +proj=latlong +datum=NAD83 +to +proj=utm +datum=NAD83 +zone=11
-117.31 41.04
473944.28       4543243.74 0.00

But given the extremely coarse precision of the lat/lon columns, that's not
too surprising.

On the other hand, since UTMs are specified to the nearest centimeter, the
reverse computation gives closer results:

bogodyn: 12:59:32 25> cs2cs -f '%.4f'  +proj=utm +datum=NAD27 +zone=11  +to +proj=latlong +datum=NAD27 
473829.030000 4543648.900000
-117.3114       41.0456 0.0000
bogodyn: 12:59:36 26> cs2cs -f '%.4f'  +proj=utm +datum=NAD83 +zone=11  +to +proj=latlong +datum=NAD83
473829.030000 4543648.900000
-117.3114       41.0436 0.0000

In both cases, the lat/lon computed from UTM rounds (using normal rounding
rules) to what you have in the table.  

In the second line of the table, the UTM->lat/lon conversion is more telling:

> cs2cs -f '%.4f'  +proj=utm +datum=NAD27 +zone=11  +to +proj=latlong +datum=NAD27 
465323.370000 4537116.040000
-117.4122       40.9864 0.0000
> cs2cs -f '%.4f'  +proj=utm +datum=NAD83 +zone=11  +to +proj=latlong +datum=NAD83
465323.370000 4537116.040000
-117.4122       40.9845 0.0000

In the NAD27 case, proper rounding of the latitude would be 40.99, disagreeing
with your table.  Proper rounding of the NAD83 latitude gives the result in
your table.

So my guess based on two data points is that if you assume the more precise of
your columns are the ones to take to the bank, and that the less precise was
a correct rounding-off of a computation, that the UTMs are in NAD83.
Of course, if the lat/lon columns are just *truncated* rather than rounded,
all bets are off.

You'd have to do the same computation on more lines of the table to be sure,

Tom Russo    KM5VY   SAR502   DM64ux          http://www.swcp.com/~russo/
Tijeras, NM  QRPL#1592 K2#398  SOC#236        http://kevan.org/brain.cgi?DDTNM
 "The truth will set you free, but first it will piss you off."

More information about the grass-user mailing list