<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">
<p>Hello all<br>
</p>
<p>Le 2024-04-12 à 16 h 31, Howard Butler via PROJ a écrit :</p>
</div>
<blockquote type="cite"
cite="mid:F3EAA8D6-09D7-40C0-831B-E680273C3595@hobu.co"><span
style="white-space: pre-wrap">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.</span></blockquote>
<p align="justify">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.</p>
<p align="justify">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.</p>
<p align="justify">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.</p>
<p align="justify">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.</p>
<p align="justify">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.</p>
<p align="justify">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.</p>
<p align="justify"> Martin</p>
<p align="justify"><br>
</p>
</body>
</html>