On Thu, Mar 03, 2011 at 12:53:04PM -0700, we recorded a bogon-computron collision of the <ru...@bogodyn.org> flavor, containing: > On Thu, Mar 03, 2011 at 06:15:39AM -0800, we recorded a bogon-computron > collision of the <rshep...@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, though. HTH, T. -- 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." _______________________________________________ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user