Opened 16 years ago
Closed 16 years ago
#2024 closed defect (invalid)
Some HDF4 files from http://oceancolor.gsfc.nasa.gov are returnning 0 to the call GDALGetRasterCount( hDataset )
Reported by: | jluis | Owned by: | warmerdam |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | GDAL_Raster | Version: | svn-trunk |
Severity: | normal | Keywords: | hdf |
Cc: |
Description
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
Change History (1)
comment:1 by , 16 years ago
Keywords: | hdf added |
---|---|
Resolution: | → invalid |
Status: | new → closed |
Joaquim,
I've run gdalinfo on this file, and it reports:
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.