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

[David Finlayson]

Paul thanks for you help.  It sounds like I may have a version of grass
that isn't compiled for unit conversions (g.version reports: 5.0.1).

How is Grass going to handle coordinate systems in the future?

David

On Fri, 11 Apr 2003, Paul Kelly wrote:

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