Kurt,
Looking at the expected behavior at GDAL's head, I see this. I think
it's probably fine, but figured I'd ask...
I don't reproduce with master:
$ gdalinfo autotest/gdrivers/data/hdf5/metadata.h5
Driver: HDF5/Hierarchical Data Format Release 5
[...]
$ gdalinfo autotest/gdrivers/data/hdf5/u8be.h5
Driver: HDF5Image/HDF5 Dataset
[...]
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?
No, that doesn't matter since drivers are re-ordered using the order
defined in frmts/drivers.ini
But in the netCDF vs HDF5 case, this doesn't matter much since the logic
in netCDFIdentifyFormat() will skip a HDF5 file if "#ifdef HAVE_HDF5" is
true and GDALGetDriverByName("HDF5") != nullptr
My guess would be that your build of the netCDF driver lacks -DHAVE_HDF5
. By the way I'm thinking this check might be incorrect. This HAVE_HDF5
is if libnetcdf has HDF5 support, but in the context of the check if
GDALGetDriverByName("HDF5") != nullptr, we don't actually care about the
capabilities of libnetcdf. It is just that if the HDF5 driver is there,
we should just use it.
Even
--
http://www.spatialys.com
My software is free, but my time generally not.
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
