[PROJ] Proposal for a geodetic deformation model format

[Howard Butler]

> On Dec 5, 2019, at 3:51 AM, Martin Desruisseaux <martin.desruisseaux at geomatys.com> wrote:
> 
> Hello Chris
> 
> Thanks for the proposal, I had a quick look on it. The explanation about rational, required metadata, etc. are very nice. My first question would be who is the intended audience. Is it a proposal for the PROJ/GDAL community, or e.g. a starting point for standardization at OGC? The reason why I ask is because in my understanding, the choice of GeoTIFF format for PROJ/GDAL is based on pragmatic reasons specific to that community (close connection between GDAL and GeoTIFF since they are maintained by the same peoples; more familiarity with GeoTIFF than with HDF5 and CF-Conventions). They are valid reasons for PROJ/GDAL, but if the target audience is wider then I would suggest to reconsider since, if it was not for PROJ/GDAL convenience, I think HDF5 + CF-Conventions (i.e. NetCDF 4) would be more appropriate for those kind of data.
> 
> However a "GeoTIFF versus HDF5" discussion could be left for a separated thread.

Since you brought it up, Even extensively compared and contrasted the possible choices for formats in his RFC 4 draft [1]. I don't understand the sentiment about a wider target audience, however. Who is this wider audience you speak of? Does HDF of any flavor have more ubiquitous support than TIFFs in geospatial software? Given our goals, you haven't made the case that HDF is anything other than a better GTX/NTV. It is, but we want more.

My case for GeoTIFF:

- Every credible GIS software supports GeoTIFF. 
- GeoTIFF is now an OGC standard. That pillory that held it out of some circles is now gone
- Incremental access over HTTP is possible and regularized in Cloud Optimized GeoTIFF
- geotiff.js 
- libtiff is actively participating in oss-fuzz 

Let's get something working before we worry about standardizing anything in OGC. OGC CRS activity on the topic was dormant until we started our efforts. Please give us the space to let it develop and mature before trying to stomp it into a mold that tries (and probably fails) to make it fit it every possible software scenario.

Howard

[1] https://github.com/rouault/PROJ/blob/rfc4_remote_and_geotiff_grid/docs/source/community/rfc/rfc-4.rst#discussion-on-choice-of-format <https://github.com/rouault/PROJ/blob/rfc4_remote_and_geotiff_grid/docs/source/community/rfc/rfc-4.rst#discussion-on-choice-of-format>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20191205/b87bab1d/attachment.html>