Opened 12 years ago

Closed 5 years ago

#4305 closed defect (wontfix)

subdatasets not read in a HDF file

Reported by: jluis Owned by: warmerdam
Priority: normal Milestone: closed_because_of_github_migration
Component: GDAL_Raster Version: svn-trunk
Severity: normal Keywords: hdf4, hdf
Cc:

Description

In the attached hdf (a SeaWifs L2 file) two of the subdatsets are not 'seen' by gdalinfo. They are the cntl_pt_cols & cntl_pt_rows.

This screencapture of HDF Explorerat http://lists.osgeo.org/pipermail/gdal-dev/attachments/20111022/01bbe110/attachment-0001.png

shows that those subdatasets do exist.

extract of gdalinfo

Subdatasets:

SUBDATASET_1_NAME=HDF4_SDS:SEAWIFS_L2:"S1998031140424.L2_MLAC_OC.x.hdf":11 SUBDATASET_1_DESC=[391x78] longitude (32-bit floating-point) SUBDATASET_2_NAME=HDF4_SDS:SEAWIFS_L2:"S1998031140424.L2_MLAC_OC.x.hdf":12 SUBDATASET_2_DESC=[391x78] latitude (32-bit floating-point) SUBDATASET_3_NAME=HDF4_SDS:SEAWIFS_L2:"S1998031140424.L2_MLAC_OC.x.hdf":13 SUBDATASET_3_DESC=[391x78] Rrs_412 (16-bit integer) SUBDATASET_4_NAME=HDF4_SDS:SEAWIFS_L2:"S1998031140424.L2_MLAC_OC.x.hdf":14 SUBDATASET_4_DESC=[391x78] Rrs_443 (16-bit integer) SUBDATASET_5_NAME=HDF4_SDS:SEAWIFS_L2:"S1998031140424.L2_MLAC_OC.x.hdf":15 SUBDATASET_5_DESC=[391x78] Rrs_490 (16-bit integer) SUBDATASET_6_NAME=HDF4_SDS:SEAWIFS_L2:"S1998031140424.L2_MLAC_OC.x.hdf":16 SUBDATASET_6_DESC=[391x78] Rrs_510 (16-bit integer) SUBDATASET_7_NAME=HDF4_SDS:SEAWIFS_L2:"S1998031140424.L2_MLAC_OC.x.hdf":17 SUBDATASET_7_DESC=[391x78] Rrs_555 (16-bit integer) SUBDATASET_8_NAME=HDF4_SDS:SEAWIFS_L2:"S1998031140424.L2_MLAC_OC.x.hdf":18 SUBDATASET_8_DESC=[391x78] Rrs_670 (16-bit integer) SUBDATASET_9_NAME=HDF4_SDS:SEAWIFS_L2:"S1998031140424.L2_MLAC_OC.x.hdf":19 SUBDATASET_9_DESC=[391x78] chlor_a (32-bit floating-point) SUBDATASET_10_NAME=HDF4_SDS:SEAWIFS_L2:"S1998031140424.L2_MLAC_OC.x.hdf":20 SUBDATASET_10_DESC=[391x78] Kd_490 (16-bit integer) SUBDATASET_11_NAME=HDF4_SDS:SEAWIFS_L2:"S1998031140424.L2_MLAC_OC.x.hdf":21 SUBDATASET_11_DESC=[391x78] pic (16-bit integer) SUBDATASET_12_NAME=HDF4_SDS:SEAWIFS_L2:"S1998031140424.L2_MLAC_OC.x.hdf":22 SUBDATASET_12_DESC=[391x78] poc (16-bit integer) SUBDATASET_13_NAME=HDF4_SDS:SEAWIFS_L2:"S1998031140424.L2_MLAC_OC.x.hdf":23 SUBDATASET_13_DESC=[391x78] cdom_index (16-bit integer) SUBDATASET_14_NAME=HDF4_SDS:SEAWIFS_L2:"S1998031140424.L2_MLAC_OC.x.hdf":24 SUBDATASET_14_DESC=[391x78] par (16-bit integer) SUBDATASET_15_NAME=HDF4_SDS:SEAWIFS_L2:"S1998031140424.L2_MLAC_OC.x.hdf":25 SUBDATASET_15_DESC=[391x78] l2_flags (32-bit integer) SUBDATASET_16_NAME=HDF4_SDS:SEAWIFS_L2:"S1998031140424.L2_MLAC_OC.x.hdf":34 SUBDATASET_16_DESC=[391x3] orb_vec (32-bit floating-point) SUBDATASET_17_NAME=HDF4_SDS:SEAWIFS_L2:"S1998031140424.L2_MLAC_OC.x.hdf":35 SUBDATASET_17_DESC=[391x3] sun_ref (32-bit floating-point) SUBDATASET_18_NAME=HDF4_SDS:SEAWIFS_L2:"S1998031140424.L2_MLAC_OC.x.hdf":36 SUBDATASET_18_DESC=[391x3] att_ang (32-bit floating-point) SUBDATASET_19_NAME=HDF4_SDS:SEAWIFS_L2:"S1998031140424.L2_MLAC_OC.x.hdf":37 SUBDATASET_19_DESC=[391x3x3] sen_mat (32-bit floating-point) SUBDATASET_20_NAME=HDF4_SDS:SEAWIFS_L2:"S1998031140424.L2_MLAC_OC.x.hdf":38 SUBDATASET_20_DESC=[391x6] scan_ell (32-bit floating-point) SUBDATASET_21_NAME=HDF4_SDS:SEAWIFS_L2:"S1998031140424.L2_MLAC_OC.x.hdf":39 SUBDATASET_21_DESC=[391x8] nflag (32-bit integer) SUBDATASET_22_NAME=HDF4_SDS:SEAWIFS_L2:"S1998031140424.L2_MLAC_OC.x.hdf":42 SUBDATASET_22_DESC=[20x2] tilt_ranges (16-bit integer)

Attachments (1)

S1998031140424.L2_MLAC_OC.x.zip (399.2 KB ) - added by jluis 12 years ago.

Download all attachments as: .zip

Change History (7)

by jluis, 12 years ago

comment:1 by etourigny, 12 years ago

Keywords: hdf4 hdf added

comment:2 by jluis, 12 years ago

It turns out that this issue can be solved very easily if the following two lines (currently) 1013 & 1014 of hdf4dataset.cpp (in function HDF4Dataset::Open) are commented

if ( iRank == 1 ) Skip 1D datsets

continue;

comment:3 by etourigny, 12 years ago

I am concerned with possible unwanted side effects and regressions with this. The must be a reason why 1D datasets are skipped.

Hunting down in the commits I found r18945 (HDF4 : prevent reading unexisting subdatasets; allow reading 1D subdatasets, in particular for GEOLOC bands; workaround strange test that swaps xsize, ysize and nbands for the particular case of the dataset of ticket #3316).

However, since that fix was to "allow reading of 1D datasets", what is different in this case?

Perhaps Even can comment further as he worked on bug #3316.

comment:4 by Even Rouault, 12 years ago

I'm afraid I don't remember the details of the fix done in r18945. It might perhaps have helped dealing with 1D subdatasets, but only in the context of GEOLOC, and not in the general case. The GEOLOC arrays must be subdatasets that are not specified by the user but directly by the code in HDF4ImageDataset::ProcessModisSDSGeolocation(), which might explain why I didn't need to change the code in hdf4dataset.cpp

Disabling the if (iRank == 1) test would required testing mostly that IReadBlock() / IWriteBlock() are ready to work in that case.

I'm not particularly willing to pursue on this myself. Etienne, if you are interested in, I let it to you.

comment:5 by Jukka Rahkonen, 9 years ago

I have no idea what GDAL could do with the missing 1 dimensional datasets but GDAL 2.0-dev still finds only 22 subdataset as in the original description.

comment:6 by Even Rouault, 5 years ago

Milestone: closed_because_of_github_migration
Resolution: wontfix
Status: newclosed

This ticket has been automatically closed because Trac is no longer used for GDAL bug tracking, since the project has migrated to GitHub. If you believe this ticket is still valid, you may file it to https://github.com/OSGeo/gdal/issues if it is not already reported there.

Note: See TracTickets for help on using tickets.