[GRASSLIST:6020] Re: projection problem SPCS -> UTM

Paul Kelly paul-grass at stjohnspoint.co.uk
Fri Apr 11 07:24:28 EDT 2003


Hello

On Thu, 10 Apr 2003, David Finlayson wrote:

> 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

So you're using the latest CVS version where it gives you a choice of
units?

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

If you add the following line (marked with a + below) to the
alloc_options() function in src/libes/proj/get_proj.c and re-compile, you
can see debug output which shows exactly the options GRASS is passing to
cs2cs / PROJ.4 for the two projections you are using. Then try them with
cs2cs or compare them with what you have in the other software.

 static void alloc_options(char * buffa)
 {
     int nsize;

     nsize = strlen(buffa);
     if (!(opt_in[nopt1++] = (char *) malloc(nsize + 1)))
         G_fatal_error("cannot allocate options\n");
     sprintf(opt_in[nopt1-1], buffa);
+    printf("/%s/", buffa);
     return;
 }

If you can provide the output of 'g.projinfo' for your locations someone
may be able to see if there's anything obviously wrong. I wouldn't say
feet to metres conversions using the new proj functions in GRASS are that
well tested although they should be working; I suppose there is a faint
chance that you've found a bug but there are lots of other things that
could be wrong.

> As a final note to this long email, the way Grass handles the stateplane
> questions is a bit odd compared to other projections.

That is because State Plane isn't a projection; it's a co-ordinate system
and it is a hack the way its handled along with projections in GRASS. In
GRASS 5.1 probably there will be generalised support for co-ordinate
systems and the State Plane system can be separated out and put where it
belongs then.

> 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

There is a file called FIPS.code or something like that in $(GISBASE)/etc
that makes those determinations. You can edit it if you want GRASS to
behave differently. E.g. add two pseudo-counties called 4601 and 4602 or
something.

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

Well don't enter state plane as the projection then; put in Transverse
Mercator or Lambert Conformal Conic or whatever and put the parameters in
as you would for any conventional projection. Or see Eric Miller's
projection files if you can find them; the old link
http://pweb.jps.net/~egm2/grass/STP/index.html
doesn't seem to work any more but google may have a cache....

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

I don't think it is worth improving the state plane handling in GRASS at
this stage (until generalised co-ordinate systems are implemented) but I
suppose it would be worthwhile to fix obvious bugs. You can check the
FIPS.code file for errors.

Paul Kelly




More information about the grass-user mailing list