HDF4 EOS case EOS GRID memory error.

[denis.nadeau@…]

hdf4imagedataset.cpp line 2221
poDS->iBandDim = i;

When Dimension List does not have the word "Band", this variable never get set and it is initialized to -1 in the constructor.  This cause a memory error in IReadBlock method.

hdf4imagedataset.cpp line 429
aiStart[poGDS->iBandDim] = nBand - 1;
aiEdges[poGDS->iBandDim] = 1;

aiEdges[-1]=1  on my machine cause eERR variable to be set to CPL_DEBUG and causing a faulty GDAL Read error, for eERR should be CPL_None when IReadBlock returns.

I guess in the 3D array case this should be set to 0.

Denis

[denis.nadeau@…]

This condition works for me.  I assume that X and Y dimension will
have X or Y in there name. 

line 2221
                    for ( i = 0; i < nDimCount; i++ )
                    {
                        if ( !(strstr( papszDimList[i], "X" )) &&
			     !(strstr( papszDimList[i], "Y" )) )
                        {

[warmerdam]

Denis,

I ran into this today, and put a bunch of fixes in related to this area of code.

Can you verify that the trunk version of GDAL fixes the problem you were seeing?

[warmerdam]

Deferring to 1.4.2 pending feedback from Denis.

[warmerdam]

Bump ... when you get a chance I'd appreciate your checking this Denis.

[dnadeau]

Frank,

I was revising this bug, the code runs, but there is an aiStart[-1] on line 350.

                    aiStart[poGDS->iBandDim] = nBand - 1;
                    aiEdges[poGDS->iBandDim] = 1;

gdal_translate always produce the same results using different bands using this file: AIRS.2002.09.17.L3.RetStd?008.v4.0.9.0.G06086155227.hdf

I also used subdataset: HDF4_EOS:EOS_GRID:"AIRS.2002.09.17.L3.RetStd008.v4.0.9.0.G06086155227.hdf":descending_MW_only:GPHeight_MW_D_ct

poGDS->iBandDim should be initialized to "the 3rd dimension" for 3D case

Ex:

If
YDim=1
XDim=2

then,
iBandDim=0

Here is the location of the file I used.  ftp://g0dup05u.ecs.nasa.gov//datapool/OPS/user/services/OPS/opendap/AIRS/AIRX3ST8.003/2002.09.17

[warmerdam]

I have confirmed serious holes in the iBandDim selection logic for EOS_GRID datasets. I have committed fixes as r11340 (trunk) and r11341 (branches/1.4). Testing with your datasets shows things operating ok.

I also noticed that access to later bands of that dataset are extremely slow. GDAL reads individual scanlines via GDreadfield(), and it appears that to read a given scanline all the previous scanlines of this band, and the complete data of previous bands needs to be decompressed. Yikes! I don't know how common use of this sort of compression is in HDF4 EOS_GRID products, but it is super-painful. If this resurfaces as a major issue, we could improve performance by using a larger block size but that still is a pretty poor solution.

Please re-open if you still see bugs with EOS_GRID products.