<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
</head>
<body>
<div class="moz-cite-prefix">
<p>Hello Howard</p>
<p>Le 05/12/2019 à 17:03, Howard Butler a écrit :</p>
</div>
<blockquote type="cite"
cite="mid:2CF9C686-B298-411E-8E33-3531D13F2810@hobu.co">
<p>
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
</p>
<div>
<div>
<p>Since you brought it up, Even extensively compared and
contrasted the possible choices for formats in his RFC 4
draft [1].</p>
</div>
</div>
</blockquote>
<p>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.</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:2CF9C686-B298-411E-8E33-3531D13F2810@hobu.co">
<div>
<div>
<p> I don't understand the sentiment about a wider target
audience, however. Who is this wider audience you speak of?</p>
</div>
</div>
</blockquote>
<p>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.</p>
<p>Other audience are the various geospatial projects in Java.<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:2CF9C686-B298-411E-8E33-3531D13F2810@hobu.co">
<div>
<div>
<p> Does HDF of any flavor have more ubiquitous support than
TIFFs in geospatial software?</p>
</div>
</div>
</blockquote>
<p>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.</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:2CF9C686-B298-411E-8E33-3531D13F2810@hobu.co">
<div>My case for GeoTIFF:
<div><br class="">
</div>
<div>- Every credible GIS software supports GeoTIFF.</div>
<div>- GeoTIFF is now an OGC standard. That pillory that held it
out of some circles is now gone</div>
<div>- Incremental access over HTTP is possible and regularized
in Cloud Optimized GeoTIFF</div>
<div>- geotiff.js </div>
<div>- libtiff is actively participating in oss-fuzz</div>
</div>
</blockquote>
<p>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:</p>
<ul>
<li>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.</li>
<li>Addition of custom attributes. The GeoTIFF approach require to
put everything in a GDAL-specific entry.</li>
<li>Standard for expressing uncertainties. The GeoTIFF approach
requires the invention of new conventions.</li>
</ul>
<p><br>
</p>
<blockquote type="cite"
cite="mid:2CF9C686-B298-411E-8E33-3531D13F2810@hobu.co">
<div>
<div><br class="">
</div>
<div>OGC CRS activity on the topic was dormant until we started
our efforts.</div>
</div>
</blockquote>
<p>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.</p>
<p> Regards,</p>
<p> Martin</p>
<p><br>
</p>
</body>
</html>