[PROJ] Proposal for a geodetic deformation model format

[Martin Desruisseaux]

Hello Howard

Le 05/12/2019 à 17:03, Howard Butler a écrit :

> Since you brought it up, Even extensively compared and contrasted the 
> possible choices for formats in his RFC 4 draft [1].
>
This is true that Even extensively compared the choices. But advantages 
and inconvenient beyond the ones mentioned in that page have been 
discussed by email (CF-Conventions allowing WKT in netCDF files, 
benchmarking done by other peoples, existence of standards for encoding 
uncertainties, needs for multi-dimensional grids, etc.). However it 
appeared during that discussion that GDAL/PROJ convenience was a major 
driver for the GeoTIFF choice. I do not challenge that, this is a good 
reason for this project.


> I don't understand the sentiment about a wider target audience, 
> however. Who is this wider audience you speak of?
>
I'm thinking to ESRI among others, who started experiments on this topic 
for many years. They presented their current state of work during OGC 
meeting last month (Even was present by teleconference). They 
experimented a custom format a few years ago, but finally selected 
netCDF. I think their choice is not final and I presume they are open to 
debate, but they have good reasons for selecting netCDF.

Other audience are the various geospatial projects in Java.


> Does HDF of any flavor have more ubiquitous support than TIFFs in 
> geospatial software?
>
It depends on the community. For scientists and software like MatLab or 
NASA Panoply, NetCDF is as ubiquitous, if not more, than GeoTIFF. At 
least in oceanography (my background), almost all data are in NetCDF and 
rarely in GeoTIFF. HDF5 and NetCDF are standard formats at NASA as far 
as I know, and European Sentinel 3 data (a few TB/day) are in NetCDF. 
I'm not questioning that GeoTIFF is used a lot, but I think that 
NetCDF/HDF5 are also ubiquitous enough for consideration as candidate 
formats.


> 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

There are good cases, but to my knowledge all those points have their 
counterpart in HDF5. There is even JavaScript HDF5 readers ("HDF5 
Node.js", "jsfive") and pure Python readers ("pyfive"). On the other 
side, there is cases for HDF5 for which the GeoTIFF counterparts require 
hacks:

  * Multi-dimensional grids. Email discussion pointed-out a need for a
    temporal axis. It can be done with multi-images GeoTIFF, but this is
    not as clean as a truly multi-dimensional file format.
  * Addition of custom attributes. The GeoTIFF approach require to put
    everything in a GDAL-specific entry.
  * Standard for expressing uncertainties. The GeoTIFF approach requires
    the invention of new conventions.


>
> OGC CRS activity on the topic was dormant until we started our efforts.

The timing between PROJ starting this effort and OGC discussing this 
topic is a coincidence. The discussion at OGC did not started because of 
PROJ effort, but because the completion of ISO 19111 and ISO 19162 
revisions released some resources that can now be used for this topic.

     Regards,

         Martin


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