[Gdal-dev] Re: [GRASS5] gdal 1.3.1 and Terra ASTER hdf files

[Michael Barton]

Thanks for the information Carl.

> From: Carl Anderson <carl.anderson at vadose.org>
> Date: Thu, 03 Nov 2005 21:43:11 -0500
> To: Michael Barton <michael.barton at asu.edu>
> Cc: <gdal-dev at lists.maptools.org>, Hamish <hamish_nospam at yahoo.com>, GRASS
> Developer's List <grass5 at grass.itc.it>
> Subject: Re: [GRASS5] gdal 1.3.1 and Terra ASTER hdf files
> 
> I'll try to relate what I understand. The GDAL 1.2.6 driver was limited
> and did not do a very good job with all of the information in HDF files.
> The old HDF sub driver was changed to newer driver to improve the
> overall quality. In 1.2.9? (certainly by 1.3.0) the driver was working
> well. The downside is that you cannot directly "read" projected data
> from a HDF and must gdalwarp L1A and L2A HDF files to a specific
> projection to get access to projected data.

Snip snip
 
> 
> You will need to warp each band from the HDF file before importing.
> 

So how do I do this? The r.in.aster script that I wrote for GRASS awhile
back essentially runs gdalwarp on each image band (one at a time) as
follows...

gdalwarp -t_srs "`g.proj -jf`" $srcfile $tempfile

It gets the target projection data from GRASS and doesn't specify the source
(i.e., ASTER) projection data. This seems to be what you are recommending.
However, gdalwarp still chokes on the ASTER source projection information.

Any suggestions? Running gdalinfo on an ASTER reveals projection
information. Is there some way to grep that info into a format that gdalwarp
would accept? Or is it a larger problem (i.e., that it ignores GCP's or
something).

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
Arizona State University
Tempe, AZ 85287-2402

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton