[gdal-dev] HDF5-R (Re: Intro)

[Even Rouault]

Peter,

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 
storage backend.
- 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 
looking further.

> 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.


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/20200507/c6105196/attachment.html>