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 <[email protected]> wrote: > On 24-10-2011 14:04, Jose Gomez-Dans wrote: > > Hi Joaquim, > > On 24 October 2011 13:56, Joaquim Luis <[email protected]> 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 > [email protected] > http://lists.osgeo.org/mailman/listinfo/gdal-dev > _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
