Add libgdal-hdf5 dependency#293
Conversation
|
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 ( |
| - libgdal-jp2openjpeg | ||
| - libgdal-hdf5 |
There was a problem hiding this comment.
Sort h-i-j. Can you also add a test for reading a NetCDF/HDF5 file?
| - libgdal-jp2openjpeg | |
| - libgdal-hdf5 | |
| - libgdal-hdf5 | |
| - libgdal-jp2openjpeg |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
To be honest, that
test_clib_read_data_image_actual_gridtest 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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
There was a problem hiding this comment.
Awesome, I'll apply this to the dev branch for the next dev version update next week or so.
| - gmt # [win] | ||
| - gmt grdmath -Rg -I1 0 90 SDIST = dist_to_NP.nc -x2 | ||
| # Test reading/writing a netCDF/HDF5 file | ||
| - gmt grdcut @earth_relief_01d=gd:netCDF -R5/10/3/5 -Greliefcut.nc |
There was a problem hiding this comment.
Won't this use the libgdal-netcdf driver instead?
There was a problem hiding this comment.
Tried the HDF5 driver in f374cf3. It also doesn't work https://github.com/conda-forge/gmt-feedstock/runs/27696142205.
Checklist
0(if the version changed)conda-smithy(Use the phrase@conda-forge-admin, please rerenderin a comment in this PR for automated rerendering)