[GRASS-user] Determining Datum From Projection Coordinates

GRASS GRASS user
1

   Context: I have a postgres table with > 110K rows of permitted wells.
Among the columns are lat, lon, utm_easting, and utm_northing; for example:

  latitude | longitude | utm_easting | utm_northing -----------+------------+---------------+----------------
  41.040000 | 117.310000 | 473829.030000 | 4543648.900000
  40.980000 | 117.410000 | 465323.370000 | 4537116.040000
  40.930000 | 117.450000 | 462092.370000 | 4531365.620000
  40.890000 | 117.080000 | 492442.050000 | 4526893.330000
  40.910000 | 117.160000 | 485988.390000 | 4529277.070000
  40.920000 | 117.150000 | 487182.810000 | 4530107.450000
  40.920000 | 117.160000 | 485989.150000 | 4529677.930000
  40.970000 | 117.140000 | 488103.560000 | 4535409.570000
  41.650000 | 118.520000 | 373435.960000 | 4612467.900000

   Because these data come from a Nevada state agency I can safely assume UTM
Zone 11, but I'd like to determine if the datum is NAD83 (in meters) which I
suspect it is, or NAD27 (in feet). What is the most simple way of determing
the datum and units.

   Once I know the datum and units I'll learn how to associate these data
with GRASS. My purpose is to produce maps of the depth to bedrock and static
water level depth by county and basin. Since this is all new to me I need to
learn it one step at a time.

   All pointers, suggestions, recommendations, and other advice is welcomed.

Rich

2

On Wed, 2011-03-02 at 15:50 -0800, Rich Shepard wrote:

Look at
http://en.wikipedia.org/wiki/Universal_Transverse_Mercator_coordinate_system

Some calculations should show you if it is meters ot not.

tomdean

3

On Wed, 2 Mar 2011, Thomas D. Dean wrote:

Look at
http://en.wikipedia.org/wiki/Universal_Transverse_Mercator_coordinate_system

Some calculations should show you if it is meters ot not.

tom,

   The magnitude of the values is also indicative; for the NAD27 values in
feet they'd be much larger.

   Interesting article that confirms what I thought was the case.

Thanks,

Rich

4

Hate to be a wet blanket, but both NAD27 and NAD83 UTM coordinates are supposed to be in meters. The False Easting for the UTM zones are defined to be 500000m regardless of datum. So, the presence of meters in your DB is not a solid indication that it is in NAD83. As the lat/long in you're file appears to be rounded to 2 decimal places (about a km) and is undefined with regards to datum, it will be difficult (if not impossible) to determine whether the data is NAD83 or NAD27. If you can live with the ~150-300m error then it shouldn't be a problem, otherwise ...

Bummer

On 2011-03-02, at 5:43 PM, Rich Shepard wrote:

On Wed, 2 Mar 2011, Thomas D. Dean wrote:

Look at
http://en.wikipedia.org/wiki/Universal_Transverse_Mercator_coordinate_system

Some calculations should show you if it is meters ot not.

tom,

The magnitude of the values is also indicative; for the NAD27 values in
feet they'd be much larger.

Interesting article that confirms what I thought was the case.

Thanks,

Rich
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

5

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.
Regardless, ...

   Since the data have both lat/lon and some version of UTM, I think the best
approach is to use the lat/lon columns to import the data, then v.proj to
the common Albers Equal Area location.

Rich

6

On Thu, Mar 03, 2011 at 06:15:39AM -0800, we recorded a bogon-computron collision of the <rshepard@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.

Of course, the *best* way to determine the datum would be to query the agency
that produced the data...

--
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."

7

Unfortunately, there are all too many government contractors, who because there are
still maps out there in NAD 27 use that as the datum and then give UTM coordinates.
It can be done with many GPS units…

Best, Mark Hall
BLM

From: Rich Shepard rshepard@appl-ecosys.com
To: grass-users@lists.osgeo.org
Sent: Thu, March 3, 2011 6:15:39 AM
Subject: Re: [GRASS-user] Determining Datum From Projection Coordinates [SOLVED]

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.
Regardless, …

Since the data have both lat/lon and some version of UTM, I think the best
approach is to use the lat/lon columns to import the data, then v.proj to
the common Albers Equal Area location.

Rich

grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

8

On Thu, Mar 03, 2011 at 12:53:04PM -0700, we recorded a bogon-computron collision of the <russo@bogodyn.org> flavor, containing:

On Thu, Mar 03, 2011 at 06:15:39AM -0800, we recorded a bogon-computron collision of the <rshepard@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."

9

On Thu, Mar 03, 2011 at 06:15:39AM -0800, we recorded a bogon-computron collision of the <rshepard@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.

[SNIP]

   Since the data have both lat/lon and some version of UTM, I think the best
approach is to use the lat/lon columns to import the data, then v.proj to
the common Albers Equal Area location.

Except that your data columns for lat/lon have far less precision than UTM,
and as I pointed out in another mail, the lat/lon values at low precision
convert to different UTM coordinates than the columns in the table (regardless
of datum) -- hundreds of meters different, in fact. On the other hand, the
much more precisely-specified UTM coordinates (expressed at centimeter
precision) do in fact convert to the given lat/lon coordinates if one assumes
proper rounding and NAD83 datum. It looks like the lat/lons are not the ones
to trust. If you were to use the lat/lon pairs to import and convert to AEA,
you're likely to have some pretty significant errors (hundreds of meters).

If I were in your shoes, I'd run a test: assume NAD83 datum and use proj.4
to convert each pair of UTMs in your table to lat/lon, then round to two
decimal places and compare to your lat/lon columns. If they all agree then
it's a safe conclusion that the UTM coordinates are the reliable, precise ones
and the datum is NAD83. Then your best bet would be to use the UTM columns to
import the data into a UTM Zone 11, NAD83 location, and v.proj *those*.

--
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."

10

On Thu, 3 Mar 2011, Tom Russo wrote:

This is true of State Plane Coordinate Systems in NAD27, but not UTM.

Tom,

   That looks famililar.

FWIW, it looks like since your lat/lons are specified at such low
precision, the NAD27/NAD83 datum shift might be irrelevant.

   I decided to use the lat/lon because no datum is applicable until it's
projected.

Of course, the *best* way to determine the datum would be to query the
agency that produced the data...

   Er, ... I don't think they'd know. Considering the state of the flat file
(an Access table), and the lack of completeness of some attributes (such as
depth to bedrock), I'll go with what I have. And, these data originated with
the folks who dug the wells so ...

Thanks,

Rich

11

On Thu, 3 Mar 2011, Tom Russo wrote:

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:

   Interesting, Tom. Thanks for exploring as you did.

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.

   Works for me.

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

   These data do not need to be so precise that I'll worry about it. I'll go
back and recreate the table using the UTM values rather than lon/lat values,
feed them through the awk script to remove missing values and the sed script
to format them correctly, and try again to import them into grass.

Much appreciated,

Rich