William,
You were right. Once I prefixed gdalwarp with "arch -i386", it worked.
But it still seems squirrelly--or perhaps it's my data. I pulled up 2
Terra/ASTER files--one from 3-4 years ago and one from 1-2 years ago.
The older one (#1 below) comes in fine, but gdalwarp puts it in
latlon. The newer one (#2 below) also comes in fine, but gdalwarp puts
it (properly) into UTM zone 30. Below are the commands and output. If
I had known that r.in.aster had gdal problems, I probably wouldn't
have used it for a test of porting from bash to Python. I thought my
porting was the problem and it turns out it's gdal.
Gdal reads and translates each file fine. It also writes out geotiffs
just fine. However, the reprojection is unreliable in this context.
Note that I'm getting the projection parameters by running "g.proj -
jf". Both files are being imported into the same UTM zone 30 location.
Michael
============== r_in_aster.py test output ====================
(1) r_in_aster.py input=/Users/cmbarton/
AST_L1B_003_06012001110409_01192003120227.hdf proctype=L1B band=1
output=aster2
Georeferencing aster image ...
Processing input file HDF4_EOS:EOS_SWATH:/Users/cmbarton/
AST_L1B_003_06012001110409_01192003120227.hdf:VNIR_Swath:ImageData1.
0...10...20...30...40
...50...60...70...80...90...
100 - done.
Importing into GRASS ...
WARNING: Over-riding projection check
<aster2.1> created
Copying 121 GCPS in points file for <aster2>
GCPs have the following OpenGIS WKT Coordinate System::
PROJCS["UTM Zone 30, Northern Hemisphere",GEOGCS["Unknown
datum based upon the GRS 1980
ellipsoid",DATUM["unknown",SPHEROID["GRS 1980",6378137,298.2
572221010002,AUTHORITY["EPSG","7019"]]],PRIMEM["Greenwich",0
],UNIT["degree",0.0174532925199433]],PROJECTION["Transverse_
Mercator"],PARAMETER["latitude_of_origin",0],PARAMETER["cent
ral_meridian",-3],PARAMETER["scale_factor",0.9996],PARAMETER
["false_easting",500000],PARAMETER["false_northing",0],UNIT[
"metre",1,AUTHORITY["EPSG","9001"]]]
r.in.gdal complete.
Cleaning up ...
source file= HDF4_EOS:EOS_SWATH:/Users/cmbarton/
AST_L1B_003_06012001110409_01192003120227.hdf:VNIR_Swath:ImageData1
tempfile= myfile.tif
proj = +proj=utm +zone=30 +a=6378137 +rf=298.257223563 +no_defs
+towgs84=0.000,0.000,0.000 +to_meter=1.0
p = 0
Done.
(1) Command finished (6 sec)
(2) r_in_aster.py input=/Users/cmbarton/
AST_L1B_003_06012001110409_01192003120227.hdf proctype=L1B band=1
output=aster3
Georeferencing aster image ...
Creating output file that is 5542P x 4884L.
Processing input file HDF4_EOS:EOS_SWATH:/Users/cmbarton/
AST_L1B_003_06012001110409_01192003120227.hdf:VNIR_Swath:ImageData1.
0.
..10...20...30...40
...50...60...70..
.80...90...
100 - done.
Importing into GRASS ...
WARNING: Datum <unknown> not recognised by GRASS and no
parameters found
WARNING: Over-riding projection check
<aster3> created
r.in.gdal complete.
Cleaning up ...
Done.
source file= HDF4_EOS:EOS_SWATH:/Users/cmbarton/
AST_L1B_003_06012001110409_01192003120227.hdf:VNIR_Swath:ImageData1
tempfile= myfile.tif
proj = +proj=utm +zone=30 +a=6378137 +rf=298.257223563 +no_defs
+towgs84=0.000,0.000,0.000 +to_meter=1.0
p = 0
(2) Command finished (4 sec)
On Jul 18, 2008, at 8:29 PM, William Kyngesburye wrote:
I just realized that you said it worked with gdal_translate, just
not gdalwarp. I refreshed my memory from my notes, and what I find
is that the GDAL autotests fail on the HDF4 read in 64bits for all
data types except byte. Write is OK.
It's not that it crashes, it just reads the data wrong. Indeed,
gdal_translate verifies that the data is read wrong. ie a 16bit int
value of 189 comes out as -17152. It makes it seem like there is an
endian problem in 64bits, but I haven't found anything yet.
Maybe gdalwarp is crashing because the data is wildly wrong. Have
you actually checked the data on the gdal_translated HDF files?
On Jul 18, 2008, at 6:01 PM, Michael Barton wrote:
My GRASS is in 32 bit mode. Does gdal default to 64 bit anyway?
Michael
______________________________
Michael Barton, Professor
Professor of Anthropology
Director of Graduate Studies
School of Human Diversity & Social Change
Center for Social Dynamics & Complexity
Arizona State University
Tempe, AZ 85287-2402
USA
voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton
On Jul 18, 2008, at 3:56 PM, William Kyngesburye wrote:
Ah, HDF - is that HDF4? There is a problem with HDF4 in 64bit
mode that I haven't been able to figure out. Run gdalwarp in
32bit mode by prefixing it with "arch -i386" (or ppc if on a PPC
Mac):
arch -i386 gdalwarp ...
-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/
"Time is an illusion - lunchtime doubly so."
- Ford Prefect
_______________________________________________
grass-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-dev
