[PROJ] Preferred grid format for transformations?

[Even Rouault]

Martin,

> I do not have an answer about the 2022 grids, but even if they are 2D
> indexed, a future grid could be 3D for example with time as the third
> dimension (e.g. a same file could contain many grids at different
> epochs). The NetCDF format may be more future proof in this regard.

RFC 4 indeed discusses the pros & cons of a few formats: netCDF v3, netCDF 4 / 
HDF5, GeoTIFF, GeoPackage.

> GeoTIFF has better established tags for defining the CRS, but in the
> case of datum shift grid we are defining a transformation between 2 CRS.
> Some extension may be needed for defining the second CRS (or at least
> its datum). I do not know if anyone is free to invent new GeoTIFF tags,
> or if a coordination is needed with some standard (e.g. for avoiding
> keys collision). By comparison defining new NetCDF attributes is
> relatively "natural" in that format.

RFC 4 goes into the details how I envision dealing with 2 CRS (actually 3). 
Basically. Adding new TIFF tags is complicated. My proposal is to feed the 
extra metadata information we need in the already well established 
GDAL_METADATA tag that contains a XML payload with arbitrary KEY=VALUE pairs 
(with a few refinements explained in the RFC)

> 
> While GeoTIFF has better defined conventions regarding CRS definition,
> NetCDF has better defined conventions regarding uncertainties definition
> and other scientific information (e.g. units of measurements, standard
> names for a wide range of physical phenomenons, etc).
> 
> Regarding the binary format complexity, it is possible to leave some
> choice to data producers. NetCDF 3 is simpler than GeoTIFF while NetCDF
> 4 is more complex (I think). But a convention for storing datum shift
> grids in a NetCDF file does not need to choose between NetCDF 3 or 4;
> the same convention can work for both. A NetCDF 3 file would not support
> tiles, compression and sub-grids, but that may be sufficient for small
> grids. A data producer could use the NetCDF 4 format only for larger
> grids. For a user of UCAR NetCDF library it should be transparent (at
> least in Java; I presume it is the case in C/C++ too). PROJ could have a
> very lightweight NetCDF 3 reader embedded with just enough capabilities
> for those datum shift grids (so it would not even require a libtiff
> dependency), and requires the real NetCDF library only for more complex
> grids.

I initially considered having a "hand-written" TIFF/GeoTIFF reader (that is 
without libtiff dependency), with a very strict subset of TIFF supports, but 
my feeling was that people would want the "full thing" with all the bells and 
whistles supported by GeoTIFF, and they wouldn't understand why this ".tif" 
file works, and not that other one. With netCDF that would be the same, a 
".nc" being netCDF 3 would work with a hand written netCDF v3 reader, but 
suddenly people would want to ue another ".nc" that happens to be netCDF v4/
HDF5 and that wouldn't work.

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com