<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">
<p>Hello Glen</p>
<p align="justify">An alternative to <font face="monospace">BOUNDCRS</font>
with more flexibility would be <font face="monospace">COORDINATEOPERATION</font>.
However the main drawback is that it is not a CRS; it is another
kind of object. Whether this alternative is applicable or not
depends on if the WKT would be used in a context accepting only
CRS or if other kinds of object (namely coordinate operations)
are accepted as well. If <font face="monospace">COORDINATEOPERATION</font>
can be used, it allows the declaration of <font
face="monospace">INTERPOLATIONCRS</font> and <font
face="monospace">OPERATIONACCURACY</font> elements among
other. Example 5 below shows its use in a "DHHN92 height to
EVRF2007 height" transformation:</p>
<blockquote>
<p><a class="moz-txt-link-freetext" href="http://docs.opengeospatial.org/is/18-010r7/18-010r7.html#143">http://docs.opengeospatial.org/is/18-010r7/18-010r7.html#143</a></p>
</blockquote>
<p align="justify">I saw that the <font face="monospace">BoundCRS</font>
for "NAD83 / UTM zone 15N + NOAA Chart Datum" uses parameters
that a paths to <font face="monospace">*.gtx</font> files. This
is a case where those files may be replaceable by GGXF files.
Latest draft is available as a PDF document there:</p>
<blockquote>
<p align="justify"><a class="moz-txt-link-freetext" href="https://github.com/opengeospatial/CRS-Gridded-Geodetic-data-eXchange-Format/issues/40">https://github.com/opengeospatial/CRS-Gridded-Geodetic-data-eXchange-Format/issues/40</a><br>
</p>
</blockquote>
<p align="justify">The proposed standard supports hydroid models
at table C.4 (page 57). Uncertainty is also supported by the
proposed standard (table C.5 among others). Feedback would be
very welcome before the draft become final! (I suggest to post
comment directly on above GitHub issue if any).</p>
<p align="justify"> Martin<br>
</p>
<p><br>
</p>
<p>Le 23/08/2022 à 16:58, Glen Rice - NOAA Federal via PROJ a
écrit :</p>
</div>
<blockquote type="cite"
cite="mid:CAGm0ZKe=aJfKjqUWCCK0iQCMso5A-AoMbx_vB18MD9Ti5Hsabw@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">Since hydrographic offices were mentioned and
uncertainty is a central topic, I would like to add ortho-tidal
vertical datums to the discussion. For a bit of background I am
one of the leads for the <a
href="https://www.nauticalcharts.noaa.gov/data/bluetopo.html"
target="_blank" moz-do-not-send="true">National Bathymetric
Source project</a> with NOAA Office of Coast Survey. I am not
even close to an expert in datums, transformations, and OGC
specifications, but I can speak to some of our struggles
with compiling lots of different sources of bathymetry.
<div><br>
</div>
<div>Within NOAA / Office of Coast Survey (as both a data
provider and an external data user), the total
propagated uncertainty (TPU) is an important qualification of
datasets and includes the datum realization uncertainty.
Chart datum, such as Mean Lower Low Water (MLLW) and as
defined in the US, is an ensemble that changes with (VDatum)
region and the grids (geoid, etc) used. Being explicit about
the grids provides for a specific realization of the vertical
datum. We are looking at describing the vertical datum using
a WKT2 BoundCRS (example at the bottom <a
href="https://github.com/OpenNavigationSurface/crs_specification/blob/main/examples/boundcrs_compound.py"
target="_blank" moz-do-not-send="true">here</a>) to avoid
ensembles (such as EPSG:5703) and the complexity required to
accommodate all the possible permutations of grid combinations
as EPSG codes. Because we carry TPU with our data we will
adjust the TPU as transformations occur, and if
incorporated data is an ensemble we will incur the cost of the
ensemble when adding the data but moving forward the data will
be assumed to be in a specific realization.</div>
<div><br>
</div>
<div>One of our current struggles has been to operationalize
this approach to dealing with explicit vertical datums and
their uncertainty.</div>
</div>
</blockquote>
<br>
</body>
</html>