[gdal-dev] HDF5-R (Re: Intro)
even.rouault at spatialys.com
Thu May 7 09:14:27 PDT 2020
Thanks for reaching out.
> On many of the projects we support, there has been a need to create a gdal
> driver / format to natively ingest a specification of the hdf5 format.
> Since this data type is used by mainy vendors
HDF5 in general, or this particular formulation ?
> , we thought the best approach
> would be to contribute the code back to the community. This would serve a
> couple of goals. 1. To supply an easy way for future vendors to access this
> driver. 2. Provide code back to a community that has already provided
> (indirectly) so much to our projects.
Several questions come to mind:
- What's the reason for this specification of HDF5 ? Besides the existing generic HDF5 driver,
there are also the specialized BAG one, and the generalist KEA one which was designed as a
100% match for the GDAL raster data model. Not mentionning netCDF which uses HDF5 as a
- Is it something only used in your lab ? Has it been reviewed by different stakeholders ?
- What use cases does it address: intended to be generic, or specific type of products?
- What is its history ?
- What is the volume of data available in this format ? Is it/will it be available as open or
commercial datasets ?
- What is the intended audience ? General public or governemental only ?
- Did you consider extending the existing HDF5 driver ? Really an open question since it might
be a good or bad idea depending on how the new driver is different.
I'm basically trying to have a clearer idea to which extent there would be an interest in having
such driver in the upstream project.
> The format which we would like to include is called HDF5-R. (The R stands
> for raster)
Minor point: the existing HDF5 driver is about raster too. And if I may comment on the
naming, I can anticipate some confusion since looking for HDF5-R in a popular search engine
leads to a HDF5 library for the R language.
> The detailed documentation/spec for the HDF5-R schema is
> available with sample data to registered users at boulderlab.org.
Having it behind a registration step looks like an unnecessary hurdle. That stopped me from
> As for maintenance, the Lab in which this code is used will be providing
> updates, if needed to support future projects and initiatives.
I was also thinking to "invisible" maintenance cost for people doing an initial contribution,
but that are well visible to people babysitting the project on a daily basis.
Spatialys - Geospatial professional services
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the gdal-dev