[GRASS-user] cs2cs Command Syntax Check

GRASS GRASS user
1

   I have many lon-lat coordinates in decimal degree format that are to be
converted to spcs Nevada East Zone (FIPS: 2701, ADS: 4601, UTM Zone 11),
NAD83, US survey feet or, as the PROJ_INFO in that location has it:

name: Transverse Mercator
proj: tmerc
datum: nad83
ellps: grs80
lat_0: 34.75
lon_0: -115.5833333333333
k: 0.9999
x_0: 200000.00001016
y_0: 8000000.000010163
no_defs: defined

   The command I propose to use is:

cs2cs +proj=latlong +datum=NAD83 +to +proj=utm +zone=11 +datum=NAD83

   Is this correct?

Rich

2

That'll work. You just need the file name at the end of the command.
The lon-lat coords should be in a text file, one on a line, separated
by a space.

Check against some known conversions just to be sure. For instance,
you can check with Ruby Dome coords at the wikipedia page.
http://en.wikipedia.org/wiki/Ruby_Dome
Click on the coordinates which will give decimal, dms, utm coords.
(The datum is wgs84, but at least you can check the syntax against
some known conversions.)

Note that you don't need to be in a grass session to run cs2cs.

It's great. Check the man page for the other command line switches.

hth

L. Prevett

On 2/27/12, Rich Shepard <rshepard@appl-ecosys.com> wrote:

   I have many lon-lat coordinates in decimal degree format that are to be
converted to spcs Nevada East Zone (FIPS: 2701, ADS: 4601, UTM Zone 11),
NAD83, US survey feet or, as the PROJ_INFO in that location has it:

name: Transverse Mercator
proj: tmerc
datum: nad83
ellps: grs80
lat_0: 34.75
lon_0: -115.5833333333333
k: 0.9999
x_0: 200000.00001016
y_0: 8000000.000010163
no_defs: defined

   The command I propose to use is:

cs2cs +proj=latlong +datum=NAD83 +to +proj=utm +zone=11 +datum=NAD83

   Is this correct?

Rich

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

3

On Mon, Feb 27, 2012 at 03:23:55PM -0800, we recorded a bogon-computron collision of the <rshepard@appl-ecosys.com> flavor, containing:

   I have many lon-lat coordinates in decimal degree format that are to be
converted to spcs Nevada East Zone (FIPS: 2701, ADS: 4601, UTM Zone 11),
NAD83, US survey feet or, as the PROJ_INFO in that location has it:

name: Transverse Mercator
proj: tmerc
datum: nad83
ellps: grs80
lat_0: 34.75
lon_0: -115.5833333333333
k: 0.9999
x_0: 200000.00001016
y_0: 8000000.000010163
no_defs: defined

   The command I propose to use is:

cs2cs +proj=latlong +datum=NAD83 +to +proj=utm +zone=11 +datum=NAD83

   Is this correct?

No. Nevada East Zone State Plane Coordinate System is not the same as
UTM, Zone 11 (even though it may lie in UTM zone 11). Your command line will
return UTM coordinates in meters easting and northing, not SPCS coordinates in
US survey feet.

What you want is to tell cs2cs to use the EPSG number 3421
as the target coordinate system. From the PROJ.4 epsg file, that means:

# NAD83 / Nevada East (ft US)
<3421> +proj=tmerc +lat_0=34.75 +lon_0=-115.5833333333333 +k=0.9999 +x_0=200000.00001016 +y_0=8000000.000010163 +ellps=GRS80 +datum=NAD83 +units=us-ft +no_defs <>

which you can see matches your PROJ_INFO information.

(On my system, the EPSG database for PROJ.4 is in /usr/local/share/proj/epsg)

You should use this command line instead:

cs2cs +proj=latlong +datum=NAD83 +to +init=epsg:3421

--
Tom Russo KM5VY SAR502 DM64ux http://www.swcp.com/~russo/
Tijeras, NM QRPL#1592 K2#398 SOC#236 http://kevan.org/brain.cgi?DDTNM
"And, isn't sanity really just a one-trick pony anyway? I mean all you get is
one trick, rational thinking, but when you're good and crazy, oooh, oooh,
oooh, the sky is the limit!" --- The Tick

4

On Tue, 28 Feb 2012, Tom Russo wrote:

No. Nevada East Zone State Plane Coordinate System is not the same as
UTM, Zone 11 (even though it may lie in UTM zone 11).

   Thanks, Tom. It's been long enough since I last needed to do this type of
conversion that I forgot to use the EPSG numer.

What you want is to tell cs2cs to use the EPSG number 3421 as the target
coordinate system. From the PROJ.4 epsg file, that means:

# NAD83 / Nevada East (ft US)
<3421> +proj=tmerc +lat_0=34.75 +lon_0=-115.5833333333333 +k=0.9999 +x_0=200000.00001016 +y_0=8000000.000010163 +ellps=GRS80 +datum=NAD83 +units=us-ft +no_defs <>

which you can see matches your PROJ_INFO information.

(On my system, the EPSG database for PROJ.4 is in
/usr/local/share/proj/epsg)

   On my Slackware systems it's /usr/share/proj/epsg.

You should use this command line instead:
cs2cs +proj=latlong +datum=NAD83 +to +init=epsg:3421

   Good. I don't need to separately specify each parameter, then.

   Glad I asked for the reality check. :slight_smile:

Much appreciated,

Rich

5

On Tue, Feb 28, 2012 at 10:05:46AM -0700, we recorded a bogon-computron collision of the <russo@bogodyn.org> flavor, containing:

On Mon, Feb 27, 2012 at 03:23:55PM -0800, we recorded a bogon-computron collision of the <rshepard@appl-ecosys.com> flavor, containing:
> I have many lon-lat coordinates in decimal degree format that are to be
> converted to spcs Nevada East Zone (FIPS: 2701, ADS: 4601, UTM Zone 11),
> NAD83, US survey feet or, as the PROJ_INFO in that location has it:
>
> name: Transverse Mercator
> proj: tmerc
> datum: nad83
> ellps: grs80
> lat_0: 34.75
> lon_0: -115.5833333333333
> k: 0.9999
> x_0: 200000.00001016
> y_0: 8000000.000010163
> no_defs: defined
>
> The command I propose to use is:
>
> cs2cs +proj=latlong +datum=NAD83 +to +proj=utm +zone=11 +datum=NAD83
>
> Is this correct?

No. Nevada East Zone State Plane Coordinate System is not the same as
UTM, Zone 11 (even though it may lie in UTM zone 11). Your command line will
return UTM coordinates in meters easting and northing, not SPCS coordinates in
US survey feet.

What you want is to tell cs2cs to use the EPSG number 3421
as the target coordinate system. From the PROJ.4 epsg file, that means:

# NAD83 / Nevada East (ft US)
<3421> +proj=tmerc +lat_0=34.75 +lon_0=-115.5833333333333 +k=0.9999 +x_0=200000.00001016 +y_0=8000000.000010163 +ellps=GRS80 +datum=NAD83 +units=us-ft +no_defs <>

which you can see matches your PROJ_INFO information.

(On my system, the EPSG database for PROJ.4 is in /usr/local/share/proj/epsg)

You should use this command line instead:

cs2cs +proj=latlong +datum=NAD83 +to +init=epsg:3421

For what it's worth, if you are already in a GRASS session in the target
location, you can always use the following command line to get lat/lon
converted to the location's coordinate system:

  cs2cs +proj=latlong +datum=NAD83 +to `g.proj -f -j`

g.proj -j prints out the correct PROJ.4 format coordinate system specification
for the current location.

You'll find that g.proj -j in your location will print out the same data as the
epsg:3421 entry.

--
Tom Russo KM5VY SAR502 DM64ux http://www.swcp.com/~russo/
Tijeras, NM QRPL#1592 K2#398 SOC#236 http://kevan.org/brain.cgi?DDTNM
"And, isn't sanity really just a one-trick pony anyway? I mean all you get is
one trick, rational thinking, but when you're good and crazy, oooh, oooh,
oooh, the sky is the limit!" --- The Tick

6

On Tue, 28 Feb 2012, Tom Russo wrote:

For what it's worth, if you are already in a GRASS session in the target
location, you can always use the following command line to get lat/lon
converted to the location's coordinate system:

cs2cs +proj=latlong +datum=NAD83 +to `g.proj -f -j`

g.proj -j prints out the correct PROJ.4 format coordinate system
specification for the current location. You'll find that g.proj -j in your
location will print out the same data as the epsg:3421 entry.

   I have several lists of sampling locations in various flavors of lat-long.
I'll do the conversions first, then insert them in a separate postgres table
so they're available for all sampling data. Given the history of this
operation there are frequently slight differences between the geographic
coordinates recorded for water and biotic samples for the same station ID.
Shrug.

Thanks again,

Rich