[gdal-dev] Extracting MODIS bands from MODIS HDF grid file using gdalwarp fails on 64-bit system (?)

[Nikos Alexandris]

Dear gdal-list,

in the past I successfully used the following lines from
Markus' (Neteler) script to extract MODIS bands from MOD09 products
(surface reflectance).


FILE=$1
HDFlayerNAMES="`gdalinfo $FILE | grep SUBDATASET_ | grep _NAME | cut
-d'=' -f2`"

for i in ${HDFlayerNAMES} ; do
	INPUT="`echo ${i}`"
        NEWNAME="`echo ${i} | cut -d':' -f4,5 | tr ':' '_' | tr -s '|'
'_'`"
        # apply GCPs and convert to GTiFF using -rcs
        gdalwarp -s_srs '+proj=sinu +R=6371007.181 +nadgrids=@null
+wktext' -t_srs '+init=epsg:2100' -tr 500 500 -rcs "${INPUT}"
$NEWNAME.HGRS87.tif


Since I switched to (Ubuntu 7.10) 64-bit I have problems reading /
writing HDF grid files.


The result, when running the above lines in a script with a
MOD09????.HDF file, is:

Creating output file that is 2772P x 2333L.
Processing input file
HDF4_EOS:EOS_GRID:"MOD09GHK.A2006239.h19v05.004.2006241155729.hdf":MOD_Grid_L2g_2d:sur_refl_b01_1.
Using internal nodata values (eg. 144) for image
HDF4_EOS:EOS_GRID:"MOD09GHK.A2006239.h19v05.004.2006241155729.hdf":MOD_Grid_L2g_2d:sur_refl_b01_1.
ERROR 1: GDreadfield() failed for block.
ERROR 1: IReadBlock failed at X offset 0, Y offset 1
ERROR 1: GetBlockRef failed at X block offset 0, Y block offset 1
Creating output file that is 2772P x 2333L.
Processing input file
HDF4_EOS:EOS_GRID:"MOD09GHK.A2006239.h19v05.004.2006241155729.hdf":MOD_Grid_L2g_2d:sur_refl_b02_1.
Using internal nodata values (eg. 144) for image
HDF4_EOS:EOS_GRID:"MOD09GHK.A2006239.h19v05.004.2006241155729.hdf":MOD_Grid_L2g_2d:sur_refl_b02_1.
ERROR 1: GDreadfield() failed for block.
ERROR 1: IReadBlock failed at X offset 0, Y offset 1
ERROR 1: GetBlockRef failed at X block offset 0, Y block offset 1
Creating output file that is 2772P x 2333L.
[...]

Is it really a  64-bit problem or is something in my systems
configuration? I've had problems understanding and applying variables,
shared libraries. But I think I've corrected this.


Thank you,

Nikos