[gdal-dev] Driver order for HDF5 versus netCDF

Kurt Schwehr schwehr at gmail.com
Thu Sep 5 13:10:14 PDT 2024


Hi Even,

I'm trying to enable NETCDF_HAS_NC4 in my distribution's copy of GDAL. This
is causing files metadata.h5 to show up as opened with netcdf rather than
hdf5.  I'm way back at 103fdca10 on 2022-Nov-16.

e.g. these

blaze-bin/third_party/gdal/gdalinfo
third_party/gdal/autotest2/python/gdrivers/testdata/hdf5/metadata.h5 | head
-5
Driver: netCDF/Network Common Data Format
Files: third_party/gdal/autotest2/python/gdrivers/testdata/hdf5/metadata.h5
Size is 512, 512
Metadata:
  /G1/NC_GLOBAL#attribute=value


and

blaze-bin/third_party/gdal/gdalinfo
third_party/gdal/autotest2/python/gdrivers/testdata/hdf5/u8be.h5 | head -5
Driver: netCDF/Network Common Data Format
Files: third_party/gdal/autotest2/python/gdrivers/testdata/hdf5/u8be.h5
Size is 5, 6
Corner Coordinates:
Upper Left  (    0.0,    0.0)


Any ideas what could be causing this?

Looking at the expected behavior at GDAL's head, I see this. I think it's
probably fine, but figured I'd ask...

Is there a reason for the order to be different for the drivers in the
DEFERRED section compared to the normal driver registration? Does the order
not matter for DEFERRED?

egrep -i 'netcdf|hdf5' gdalallregister.cpp | egrep -i 'defined|ifdef'
#if defined(DEFERRED_HDF5_DRIVER)
#if defined(DEFERRED_NETCDF_DRIVER)
#ifdef FRMT_netcdf
#ifdef FRMT_hdf5

https://github.com/OSGeo/gdal/blob/ac213a38e748e22c055d3187fd076bcedbe5892a/frmts/gdalallregister.cpp

Thanks,
-Kurt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20240905/34aed7e8/attachment.htm>


More information about the gdal-dev mailing list