Version 8 (modified by mloskot, 5 years ago)

--

HDF

There are two HDF formats, HDF4, and HDF5 which each have their own libraries and drivers. HDF4 is more common, but HDF5 is the next generation format.

Building with HDF4

NCSA HDF library can be downloaded from the  The NCSA HDF Home Page at the the  National Center for Supercomputing Applications. HDF 4.2r1 is generally the preferred version if working from source. The szip option is not widely used, and may be omitted for simplicity.

If your OS distribution already contains prebuilt HDF library you can use one from the distribution.

Open File Limits

Please note, that NCSA HDF library compiled with several defaults which is defined in hlimits.h file. For example, hlimits.h defines the maximum number of opened files:

#   define MAX_FILE   32

If you need open more HDF4 files simultaneously you should change this value and rebuild HDF4 library (there is no need to rebuild GDAL if it is already compiled with HDF4 support).

Incompatibility with NetCDF Libraries

The HDF4 libraries include an implementation of the netcdf api which can access hdf files. If building with HDF4 and NetCDF it is necessary to build the HDF library with this disable. This can be accomplished by defining the macro HAVE_NETCDF when building the HDF libraries. I normally accomplish this by configuring the HDF4 libraries as follows:

export CFLAGS="-fPIC -DHAVE_NETCDF"
export CXXFLAGS="-fPIC -DHAVE_NETCDF"
export LIBS="-lm"
./configure --disable-fortran

The -fPIC and LIBS may not be necessary on all platforms. Without this fix either GDAL will crash intermittently when accessing netcdf files, or the build of GDAL will fail. On more recent HDF4 releases it has been added a new configuration flag, so that you have to use

./configure --disable-netcdf --disable-fortran

and HDF4 will move its embedded NetCDF functions in a different private namespace to avoid name clashes.

Potential conflicts with internal libz

The HDF4 libraries depend on  libz library. If you build HDF4 from sources, you most likely use libz library already installed in your system. Then, when you run GDAL ./configure script using option --with-libz=internal requesting GDAL to use its internal version of libz, you may notice that HDF4 support is not enabled as you expected. This might signal a conflict between internal libz and the version installed in you system against which HDF libraries were linked. More detailed description of the problem and its symptoms can be found in summary of Ticket #1955.

Open Tickets

#430
ASTER HDF Georeferencing Off by 1KM?
#772
HDF - Georeferencing for ASTER HDF_EOS products
#1239
MODIS HDF LAI product: ERROR 1: latitude or longitude exceeded limits in gdalwarp
#1424
subset in an hdf5 file let gdal_info and gdal_translate bail
#1900
Get hdf band, inverse data set dimensions
#2417
HDF4 endian problems on read in OSX 64bits
#2420
Subdataset metadata unavalable
#2539
patch for frmts/HDF4 (HDF_GLOBAL#{spatial_ref/GeoTransform})
#2758
HDF4 reading MISR Level 3 with incorrect dimension
#2843
HDF4 Update In Place Support
#3534
HDF5 driver fixes for subdataset name escaping and dimension capture
#4121
[PATCH] hdf5imagedataset doesn't get the metadata asociated to a subdataset
#4173
HDF4, IReadBlock() and GDA_Update
#4227
[""PATCH""] HDF5 : cannot read/convert some multi-band multi-image dataset
#4305
subdatasets not read in a HDF file
#4425
support more HDF4 files by dropping requirement of "Signature" attribute
#4426
Link to GDAL in HDF4 Signature is dead
#4599
GDAL reports incorrect longitude coordinates in HDF5 files as GCPs
#4672
HDF4 read incorrectly
#4697
gdal can't support hdf5 file of Cosmo-skymed?
#4698
[gdal_merge.py] HDF input, ENVI output; unable to open in ENVI
#4890
PATCH: DODS driver can now read 3-D datasets, metadata, projection, remote NetCDF files
#4891
HDF4 scale/offset CoastWatch convention questionable