[GRASS-dev] problems with gdalwarp

[Michael Barton]

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