[GRASSLIST:277] Re: r.proj

[Paul Kelly]

Hello there

On Sun, 1 Jun 2003, Sean Fulton wrote:

> On Sunday 01 June 2003 06:26 am, you wrote:
> > On Sun, 1 Jun 2003, Sean Fulton wrote:
> > > Hello,
> > >
> > > I'm trying to project some raster data from Lat/Lon/GRS80/NAD83 to
> > > Albers/Clark66/NAD27. The data was downloaded from USGS NED site as
> > > GeoTIFFs and imported using r.in.gdal without problems.
> > >
> > > When trying project the data, r.proj does its thing and appears to work,
> > > however the range of data as shown by r.info for the newly projected
> > > rasters show a min and max that are the same. On successive attempts the
> > > vaules for min and max were 0, nan or -2147483648.
> >
...
>
> I've include the g.projinfo for both Lat/Lon locations in case this is useful
> to anyone (or anyone can explain what I did wrong).
>

It may be a bug. You didn't say which GRASS version you were using, but
5.0.0pre4 to 5.0.2 included somewhat basic support for NAD27 to/from NAD83
datum transformations, and just looking at the old code this morning I can
see a bug in the handling of lat/long locations (it worked OK for
projected locations). At first glance it seems to be only when the output
location is in lat/long, but I think r.proj projects both ways during the
course of its operation, so if either location was lat/long the bug would
appear.

If the datum name was in capitals then the buggy section of code would
have been skipped and you wouldn't have got any datum transformation; the
results may be roughly correct. I haven't tested this so it is just a
guess at what might have been happening. BTW apart from the datum in
capitals the two PROJ_INFO files you provided are exactly equivalent. Also
the function that had the bug in it has not been part of the GRASS CVS
version for about 4 months now.

In short: you may upgrade to the latest CVS version, which supports all
datum transformations that are supported by the PROJ.4 library, and has
more reliable and robust projection handling.

Paul Kelly