[gdal-dev] HDF5 and CF conventions

[Even Rouault]

Piyush,

> We are considering extending the HDF5 driver to support CF conventions.

My main question is :
Why... ? Why the netCDF driver on a netCDF v4 / HDF5 file doesn't do the job already ? I'm 
quite concerned by the CF logic being duplicated in several drivers.

> All the logic exists as part of the netcdf driver (pretty much) and it should not take a really 
long time to add that support to HDF5 driver as well.

I love your optimism :-)

> 1.  Working towards this, would it be ok to move  the “CF_*” defines / constants to its own 
CF.h header file? That will then let us use it in other drivers as well.

Constants are only one part of the equation. The whole logic to build the 
OGRSpatialReference object from attributes is also something that would be great to have 
coded just once. To reuse it in multiple drivers would require to abstract the way to query 
attributes. Which brings me to thinking that the new multidim API could potentially be of use 
to have a driver-independent CF CRS decoding logic.

> 2.  CF conventions 1.7+ supports an attribute
> called “crs_wkt”. GDAL has traditionally referred to this attribute as
> “spatial_ref”. Would it be ok to update netcdf driver to look for crs_wkt
> first and then fall back to usual spatial_ref attribute when it is not
> found?

Sounds good to me. Could/should be a separate pull request.

> 3.  If one were to add CF support for HDF5, would it be preferable
> to make this its own driver like KEA/BAG (say H5CF) or part of the
> HDF5imagedataset core like CosmoSkymed / KompSAT products? 

I'd say more in the existing HDF5 driver to limit the amount of new code.
KEA & BAG are really very specialized profiles of HDF5.

Even


-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20200331/1eba1357/attachment-0001.html>