Add libgdal-hdf5 dependency

[seisman]

Checklist

• Used a personal fork of the feedstock to propose changes
• Bumped the build number (if the version is unchanged)
• Reset the build number to 0 (if the version changed)
• Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
• Ensured the license file is being packaged.

[conda-forge-webservices]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe/meta.yaml) and found it was in an excellent condition.

[weiji14]

Sort h-i-j. Can you also add a test for reading a NetCDF/HDF5 file?

Suggested change

	- libgdal-jp2openjpeg
	- libgdal-hdf5
	- libgdal-hdf5
	- libgdal-jp2openjpeg

[seisman]

Can you also add a test for reading a NetCDF/HDF5 file?

I added a test in ff8d995, and it worked without the libgdal-hdf5 library, but if I add libgdal-hdf5 in GenericMappingTools/pygmt@bb0efe3, tests passed (except one failure which is not directly related to the issue).

I think the reason is, when reading a netCDF file, GMT calls the netcdf library, but in GenericMappingTools/pygmt#3338, we're actually trying to read a netCDF file as an image (into a GMT_IMAGE container), which instead calls GDAL to read the file.

[weiji14]

Right... so should we actually add libgdal-hdf5 as a dependency here then? To be honest, that test_clib_read_data_image_actual_grid test in GenericMappingTools/pygmt#3338 is a bit weird since we're trying to read a 1-band grid as a GMT image.

[seisman]

To be honest, that test_clib_read_data_image_actual_grid test in GenericMappingTools/pygmt#3338 is a bit weird since we're trying to read a 1-band grid as a GMT image.

The original idea comes from GenericMappingTools/pygmt#3318 (comment) to solve the issue GenericMappingTools/pygmt#3115 (comment).

For any given file, we can call Session.read_data to read the file header only and determine the raster kind (grid, image or cube). It turns out, we can read ".nc" file as a GMT image and read ".tif" file as a GMT grid. So that test was added to understand what's exactly happening.

so should we actually add libgdal-hdf5 as a dependency here then?

We still need libgdal-hdf5, because reading other image formats via GDAL will likely need the HDF5 library.

[weiji14]

Or actually, can you add the test back and use the =gd modifier to force GMT to read the NetCDF file using GDAL? https://docs.generic-mapping-tools.org/6.5/reference/features.html#modifiers-to-read-and-write-grids-and-images-via-gdal

[seisman]

gmt grdcut @earth_relief_01d=gd -R-10/-9/3/5 -Greliefcut.nc

Test fails without libgdal-hdf5. See
https://github.com/conda-forge/gmt-feedstock/pull/293/checks?check_run_id=27695109707

[weiji14]

Awesome, I'll apply this to the dev branch for the next dev version update next week or so.

[weiji14]

Won't this use the libgdal-netcdf driver instead?

[seisman]

Tried the HDF5 driver in f374cf3. It also doesn't work https://github.com/conda-forge/gmt-feedstock/runs/27696142205.