Some HDF4 files from http://oceancolor.gsfc.nasa.gov are returnning 0 to the call GDALGetRasterCount( hDataset )

[jluis]

I'm having troubles reading some of files available at ​http://oceancolor.gsfc.nasa.gov In particular the SST files but not the ocean color files.

What is happening is that on the problematic files

GDALGetRasterCount( hDataset );

is returning 0, which is fatal to my gdalread mex file.

Here is an example file ​http://oceancolor.gsfc.nasa.gov/cgi/getfile/T20061822006212.L3m_MO_SST_9.bz2 Note that running gdalinfo on it does not print the Band 1 Block= ...

since that part of the code is inside a loop for( iBand = 0; iBand < GDALGetRasterCount( hDataset ); iBand++ )

and it's not executed since GDALGetRasterCount( hDataset ) == 0

[warmerdam]

Joaquim,

I've run gdalinfo on this file, and it reports:

Subdatasets:
  SUBDATASET_1_NAME=HDF4_SDS:UNKNOWN:"T20061822006212.L3m_MO_SST_9":0
  SUBDATASET_1_DESC=[2160x4320] l3m_data (16-bit unsigned integer)
  SUBDATASET_2_NAME=HDF4_SDS:UNKNOWN:"T20061822006212.L3m_MO_SST_9":1
  SUBDATASET_2_DESC=[2160x4320] l3m_qual (8-bit unsigned integer)

Some HDF files (this is also true of a few other file formats) are containers for several datasets, which much then be accessed by GDALOpen()'ing the names returned for subdatasets on the main file. In these cases the GDALDataset for the main file may have no bands at all since there is no obvious image to select as "primary". I imagine you would find that if you pass the dataset names in SUBDATASET_1_NAME or SUBDATASET_2_NAME to GDALOpen() you would get a dataset with bands you can operate on.