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
_______________________________________________ gdal-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/gdal-dev
