Hello all Le 2024-04-12 à 16 h 31, Howard Butler via PROJ a écrit :
Even's COG-based GTG [1] approach for PROJ supports both an incremental network and a local cache distribution model at the same time. I've found it frustrating the OGC CRS Standards Working Group didn't value a similar approach when it developed the GGXF standard. Not only is GGXF content going to require yet another transformation for use as an incremental network, its complexity in comparison to GTG is going to be challenging for grid producers.
The grid format and the network for distributing them are two separated things. GGXF addresses only the former. Hosting the files at OGC, EPSG or somewhere else does not depend on whether those files are in GTG or GGXF format, and the incremental model used by PROJ (or other software, caching is not a new concept) is an implementation strategy independent of the standard.
The complexity argument is disputable. The OGC working group did a survey before to start the GGXF work, and a majority of data producers who responded were more familiar with NetCDF than GeoTIFF. In scientific communities, netCDF and HDF are used a lot. It does not mean that GeoTIFF is not used, but it is not as dominant as in GDAL communities. Furthermore, the GeoTIFF format *is* complex. It has 2 or 3 layers of embedded encoding (GeoKeys inside TIFF tags, then a dictionary of object names packed in a single GeoKey, then embedded XML documents for everything not associated to a GeoKey). TIFF is a rigid format, difficult to extend beyond the 2D imagery for which it was designed, and the GeoTIFF extension (GeoKeys) is itself difficult to extend as well. For this reason, many geospatial data (including GTG) distributed as GeoTIFF files has to resort to XML or JSON auxiliary files. In comparison, netCDF can be seen as a kind of binary JSON optimized for multi-dimensional data cubes. It is as flexible as XML or JSON for storing desired metadata. It has been argued that this flexibility is an interoperability problem because of different interpretations done by different software, but the same can be said against XML, JSON, WKT or even TIFF: before TIFF version 6, a joke was that "TIFF" was the acronym of "Thousands of Incompatible File Formats". No matter the format, the only way to address this problem is with a specification as unambiguous as possible, which may take many versions.
A GeoTIFF problem is that it is very poor in metadata. GGXF needs to store three CRS (source, target, interpolation). The GeoKeys can store only one CRS, and the two others have to be stored somewhere else. The same problem applies to other metadata such as accuracy and interpolation method. By contrast, GGXF is self-contained: all metadata are cleanly stored in a single file: no auxiliary files, and no "TIFF-tags / GeoKeys / yet-another-encoding-packed-in-a-GeoKey / embedded-XML-document" mix inside the main file.
Another GGXF goal was to be at least as good as NADCON and NTv2 in order to be a potential replacement for them. The Cloud Optimized GeoTIFF (COG) convention cannot represent a pyramid of grids with different resolutions in different regions as NTv2 does (all pyramid levels in a COG file covers the same region). It would of course be possible to resolve this problem with more metadata, but the GeoTIFF metadata are already messy and it would make the situation worst.
GGXF is the result of 2 years (if my memory serve me right) of biweekly meetings between peoples from EPSG, ESRI, geodesic experts from data producer agencies and more. It is backed by an abstract specification posing the theoretical foundations before to address the actual encoding in a separated document. The encoding document itself it designed in a way to allow binary encodings other than netCDF in the future if there is a demand. ESRI is already implementing GGXF support and Apache SIS will follow hopefully this year. I understand that not adopting GTG may seem frustrating, but there is not the same level of expertise in those two formats.
Anyway, GGXF is currently pushed as an exchange format. Software can consume it directly, but not necessarily. Data producers would publish their data in GGXF, then PROJ (for example) may convert those files to GTG for publication on their network. Apache SIS on its side would consume the GGXF files directly. Having the original data published in GGXF rather than GTG is advantageous at least for archival purposes, because of the richer metadata.
Martin
_______________________________________________ PROJ mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/proj
