[gdal-dev] subdatasets not read in a HDF file

Mon Oct 24 12:02:20 EDT 2011

On 24-10-2011 15:21, Etienne Tourigny wrote:
> Joaquim,
>
> I tried reading your dataset with the updated netcdf driver in linux,
> but it reads the same (22) subdatasets (see below).  But at least it
> opens, with the following call:
> gdalinfo NETCDF:S1998031140424.L2_MLAC_OC.x.hdf

Etienne, I rebuilt with your instructions ( 1) + the netcdfdataset.h 
quick fix) and still get the same error, but perhaps it's something 
related to the driverName:fileName mechanism as I get the same error 
message when using the HDF driver

gdalinfo HDF:S1998031140424.L2_MLAC_OC.x.hdf
ERROR 4: `HDF:S1998031140424.L2_MLAC_OC.x.hdf' does not exist in the 
file system,

> In fact, your email prompted me to try it out and add support for HDF4
> in the netcdf driver (since netcdf-4 can support it).
> I think it doesn't read what you want because netcdf uses SDOpen and
> does not support all of HDF4's capabilities (only SDS datasets).

I don't know if it's in some way related (I know little about hdf) but 
my Matlab code has

cntl_pt_cols = hdf_funs('hdfread', att.fname, 
att.hdrModisL2.Vgroup(Vg_index).SDS(3).Name, ...

the 'SDS' member name is provided by the Matlab MEX and I don't know if 
it is related but I notice the coincidence.

>
> I asked Even if he can update the windows makefiles, but if you can
> help out (especially if you use netcdf-4) it would be nice!
> Please post any patches to ticket http://trac.osgeo.org/gdal/ticket/4294
>
> my opinion (and Even's) is that you should
>
> 1) add to nmake.opt the following in the netcdf section
> # Uncomment the following to add NC4 and HDF4 support
> #NETCDF_HAS_NC4 = yes
> #NETCDF_HAS_HDF4 = yes
>
> 2) and frmts/netcdf/makefile.vc is where you need to add the -D statements
>
> NETCDF_HAS_NC4
> NETCDF_HAS_HDF4
> HAVE_HDF4 (if HDF4_DIR is defined)
> HAVE_HDF5 (if HDF5_DIR is defined)
>
> a quick fix is to add the defines in netcdfdataset.h, see if that works
> #define NETCDF_HAS_NC4
> #define NETCDF_HAS_HDF4
> #define HAVE_HDF4
> #define HAVE_HDF5
>
> definitely do not add NC_NETCDF4 as it is defined by netcdf-4 itself.
>
>    SUBDATASET_1_NAME=NETCDF:"S1998031140424.L2_MLAC_OC.x.hdf":longitude
>    SUBDATASET_1_DESC=[391x78] longitude (32-bit floating-point)
>    SUBDATASET_2_NAME=NETCDF:"S1998031140424.L2_MLAC_OC.x.hdf":latitude
>    SUBDATASET_2_DESC=[391x78] latitude (32-bit floating-point)
>    SUBDATASET_3_NAME=NETCDF:"S1998031140424.L2_MLAC_OC.x.hdf":Rrs_412
>    SUBDATASET_3_DESC=[391x78] Rrs_412 (8-bit integer)
>    SUBDATASET_4_NAME=NETCDF:"S1998031140424.L2_MLAC_OC.x.hdf":Rrs_443
>    SUBDATASET_4_DESC=[391x78] Rrs_443 (8-bit integer)
>    SUBDATASET_5_NAME=NETCDF:"S1998031140424.L2_MLAC_OC.x.hdf":Rrs_490
>    SUBDATASET_5_DESC=[391x78] Rrs_490 (8-bit integer)
>    SUBDATASET_6_NAME=NETCDF:"S1998031140424.L2_MLAC_OC.x.hdf":Rrs_510
>    SUBDATASET_6_DESC=[391x78] Rrs_510 (8-bit integer)
>    SUBDATASET_7_NAME=NETCDF:"S1998031140424.L2_MLAC_OC.x.hdf":Rrs_555
>    SUBDATASET_7_DESC=[391x78] Rrs_555 (8-bit integer)
>    SUBDATASET_8_NAME=NETCDF:"S1998031140424.L2_MLAC_OC.x.hdf":Rrs_670
>    SUBDATASET_8_DESC=[391x78] Rrs_670 (8-bit integer)
>    SUBDATASET_9_NAME=NETCDF:"S1998031140424.L2_MLAC_OC.x.hdf":chlor_a
>    SUBDATASET_9_DESC=[391x78] chlor_a (32-bit floating-point)
>    SUBDATASET_10_NAME=NETCDF:"S1998031140424.L2_MLAC_OC.x.hdf":Kd_490
>    SUBDATASET_10_DESC=[391x78] Kd_490 (8-bit integer)
>    SUBDATASET_11_NAME=NETCDF:"S1998031140424.L2_MLAC_OC.x.hdf":pic
>    SUBDATASET_11_DESC=[391x78] pic (8-bit integer)
>    SUBDATASET_12_NAME=NETCDF:"S1998031140424.L2_MLAC_OC.x.hdf":poc
>    SUBDATASET_12_DESC=[391x78] poc (8-bit integer)
>    SUBDATASET_13_NAME=NETCDF:"S1998031140424.L2_MLAC_OC.x.hdf":cdom_index
>    SUBDATASET_13_DESC=[391x78] cdom_index (8-bit integer)
>    SUBDATASET_14_NAME=NETCDF:"S1998031140424.L2_MLAC_OC.x.hdf":par
>    SUBDATASET_14_DESC=[391x78] par (8-bit integer)
>    SUBDATASET_15_NAME=NETCDF:"S1998031140424.L2_MLAC_OC.x.hdf":l2_flags
>    SUBDATASET_15_DESC=[391x78] l2_flags (16-bit integer)
>    SUBDATASET_16_NAME=NETCDF:"S1998031140424.L2_MLAC_OC.x.hdf":orb_vec
>    SUBDATASET_16_DESC=[391x3] orb_vec (32-bit floating-point)
>    SUBDATASET_17_NAME=NETCDF:"S1998031140424.L2_MLAC_OC.x.hdf":sun_ref
>    SUBDATASET_17_DESC=[391x3] sun_ref (32-bit floating-point)
>    SUBDATASET_18_NAME=NETCDF:"S1998031140424.L2_MLAC_OC.x.hdf":att_ang
>    SUBDATASET_18_DESC=[391x3] att_ang (32-bit floating-point)
>    SUBDATASET_19_NAME=NETCDF:"S1998031140424.L2_MLAC_OC.x.hdf":sen_mat
>    SUBDATASET_19_DESC=[391x3x3] sen_mat (32-bit floating-point)
>    SUBDATASET_20_NAME=NETCDF:"S1998031140424.L2_MLAC_OC.x.hdf":scan_ell
>    SUBDATASET_20_DESC=[391x6] scan_ell (32-bit floating-point)
>    SUBDATASET_21_NAME=NETCDF:"S1998031140424.L2_MLAC_OC.x.hdf":nflag
>    SUBDATASET_21_DESC=[391x8] nflag (16-bit integer)
>    SUBDATASET_22_NAME=NETCDF:"S1998031140424.L2_MLAC_OC.x.hdf":tilt_ranges
>    SUBDATASET_22_DESC=[20x2] tilt_ranges (8-bit integer)
>
>
> thanks,
> Etienne
>
> On Mon, Oct 24, 2011 at 11:15 AM, Joaquim Luis<jluis at ualg.pt>  wrote:
>> On 24-10-2011 14:04, Jose Gomez-Dans wrote:
>>
>> Hi Joaquim,
>>
>> On 24 October 2011 13:56, Joaquim Luis<jluis at ualg.pt>  wrote:
>>> Anton,
>>>
>>> I don't remember the details because I programmed that some time ago, but
>>> from what I recall that's the most accurate way of interpolating the data
>>> into a regular grid. The whole procedure is implemented in Mirone were the
>>> x,y,z triplets (computed after the cnt_pt_col|row)  are reinterpolated with
>>> minimum curvature or nearneighbor algorithms to calculate a regular grid.
>>>   Now, this used to work with temperature data but it didn't anymore with
>>> that chlorophyll file (Mirone stand-alone crashed) .  The implementation use
>>> a Matlab hdf reader MEX and that MEX of the time of ML6.5 crashes. New
>>> versions work okay but I cannot used them in the Mirone stand-alone so I
>>> though in using GDAL (as I do in many other instances), except that ... it
>>> doesn't work too.
>> I think that GDAL doesn't do the 1D datasets you find in some products
>> (MODIS MOD09XX springn to mind). Here's a message I sent to the list in
>> 2008, and a reply from F Warmerdam on it. I ended up using pyhdf in the
>> end:
>> <http://osgeo-org.1803224.n2.nabble.com/HDF-V-and-VR-components-td2032993.html>
>>
>> Hi Jose,
>>
>> That's indeed a pitty ... but perhaps there is s new hope in town -  the
>> updated netcdf driver. Etienne?
>> BTW what do I need to change in nmake.opt to compile with the new abilities
>> of the netCDF driver on Windows? I have netcd4 built with HDF support and
>> tried by adding
>>
>> -DNC_NETCDF4 -DNETCDF_HAS_NC4 -DNETCDF_HAS_HDF4
>>
>> to the compile flags but still no luck in reading a HDF file with it's
>> cousin driver.
>>
>> Joaqium
>>
>> _______________________________________________
>> gdal-dev mailing list
>> gdal-dev at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>>
>