[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