<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Kurt,<br>
</p>
<br>
<blockquote type="cite"
cite="mid:CACmBxysEtSq2q-MhksyTjXmAucxjd0DGYpfyozbUKT8x12p8vw@mail.gmail.com">
<div dir="ltr">
<div>Looking at the expected behavior at GDAL's head, I see
this. I think it's probably fine, but figured I'd ask...</div>
</div>
</blockquote>
<p>I don't reproduce with master:</p>
<p>$ gdalinfo autotest/gdrivers/data/hdf5/metadata.h5 <br>
Driver: HDF5/Hierarchical Data Format Release 5<br>
[...]</p>
<p>$ gdalinfo autotest/gdrivers/data/hdf5/u8be.h5 <br>
Driver: HDF5Image/HDF5 Dataset<br>
[...]</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:CACmBxysEtSq2q-MhksyTjXmAucxjd0DGYpfyozbUKT8x12p8vw@mail.gmail.com">
<div dir="ltr">
<div><br>
</div>
<div>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?</div>
<div><br>
</div>
<br>
</div>
</blockquote>
<p>No, that doesn't matter since drivers are re-ordered using the
order defined in frmts/drivers.ini</p>
<p>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</p>
<p>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.<br>
</p>
<p>Even</p>
<span style="white-space: pre-wrap">
</span>
<pre class="moz-signature" cols="72">--
<a class="moz-txt-link-freetext" href="http://www.spatialys.com">http://www.spatialys.com</a>
My software is free, but my time generally not.</pre>
</body>
</html>