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

Mon Oct 24 10:21:58 EDT 2011

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

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 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
>