Re: Preferred grid format for transformations?

Le 25/11/2019 à 22:09, Even Rouault a écrit :

>> A few things that will be coming in 2022 include grids for 3D
>> velocities, uncertainties for grids (geoids, transformations) and more
>> so some of the things discussed like having multidimensional information
>> at each node would be nice.
> I assume here that by "multidimensional" you mean storing several samples per grid node,
> where the grid is still 2D indexed (referenced to a geographic longitude, latitude CRS
> typically) ? The above GeoTIFF proposal should be able to allow this.

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.

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.

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.

     Martin


_______________________________________________
PROJ mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/proj