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.
Any suggestions?
Thanks in advance.
Sean
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.
What GRASS version are you using and what information does r.proj output
to the screen? What is in the PROJ_INFO files (output of g.projinfo
command). For projection information created by r.in.gdal the datum name
may be in capitals and may need to be changed to small letters (e.g. NAD83
to nad83) by manually editing the PROJ_INFO file, depending on which GRASS
version you are using.
Not really suggestions for solving the problem but the extra information
might shed more light on it...
Thanks, Paul, that information pushed me in the right direction. I had set up
the Lat/Lon location manually and imported the maps. I tried importing them
to a new location using gdal (r.in.gdal in=file out=map location=latlon2) to
set up the location. Projection from this new location worked! And the datum
is in upper case. The projected maps look fine (except for color tables but I
could manually copy those).
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).
Regards
Sean
From the first latlon location (manually set up):
-----------------------------------------------------------
PROJ_INFO file:
name: Latitude-Longitude
datum: nad83
dx: 0.000000
dy: 0.000000
dz: 0.000000
proj: ll
ellps: grs80
-----------------------------------------------------------
PROJ_UNITS file:
unit: degree
units: degrees
meters: 1.0
-----------------------------------------------------------
From the latlon location (set up by r.in.gdal):
-----------------------------------------------------------
PROJ_INFO file:
proj: ll
ellps: grs80
datum: NAD83
name: Lat/Lon
a: 6378137
es: 0.0066943800
-----------------------------------------------------------
PROJ_UNITS file:
unit: degree
units: degrees
meter: 1.0
-----------------------------------------------------------
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