[GRASSLIST:6012] projection problem SPCS -> UTM

[David Finlayson]

Hello,

I am trying to project sites and raster data from a location in Washington
Stateplane North (FIPS 4601) to UTM zone 10.

The sites data is in Washington Stateplane North (FIPS 4601), NAD83,
meters

I created a location in this projection answering the series of questions
for Washington, Island Co. and setting the units to meters

The raster data is in Washington Stateplane North (FIPS 4601), NAD83, feet

I created a second location in this projection setting the units to feet

Finally, I set up a third location in UTM zone 10 North, NAD83.  I used
r.proj and s.proj to load the two datasets into the UTM location.

The sites and raster data projected into the UTM location successfully,
only they were shifted nearly 50 km to the west of the proper UTM
coordinates.

To verify that the problem is in GRASS I independently projected the sites
data from WA SPCS 4601 to UTM83 zone 10 using CORPSCON and also NAD2NAD in
the Proj4 package.  They produced identical results in the correct
location.  It appears that GRASS is making a simple systematic error that
is resulting in the ~50 km westward shift.

Unfortunately I am not familiar with cs2cs to check if the problem is in
that program (I think grass uses cs2cs internally, no?).  If someone could
help me with cs2cs I can check that as well.

As a final note to this long email, the way Grass handles the stateplane
questions is a bit odd compared to other projections.  Washington has only
2 stateplane projections: North (FIPS 4601) and South (FIPS 4602).
However, Grass never gives me the chance to select 4601 or 4602.  Instead
it asks me for the county of my data and somehow determines which
projection to use.  This would be the equivalent of asking you if you are
mapping something in Canada and then having grass select an Albers
projection without telling you what it is doing.  Many Washington State
agencies have standardized on either 4601 or 4602 for the whole state.  It
seems to me that in the long run, it would be better for Grass to get out
of the way and just let the user figure out which projection to use.

I am willing to help trouble shoot this some more if there are programmers
who have access to the projection features of GRASS (I am not a C
programmer).  Please let me know how I can help with this.  I have plenty
of verified test data.

Thanks.

David Finlayson
dfinlays at u.washington.edu
Department of Earth and Space Sciences
University of Washington, Box 351310
Seattle, WA 98195-1310
(206) 685-7981 or (206) 543-1975