<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">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">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><br></div><div>Hopefully that is useful and on point.</div><div>Glen</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Aug 23, 2022 at 10:11 AM Martin Desruisseaux <<a href="mailto:martin.desruisseaux@geomatys.com" target="_blank">martin.desruisseaux@geomatys.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<div>
<p>Le 20/08/2022 à 23:40, Cameron Shorter via PROJ a écrit :</p>
</div>
<blockquote type="cite">
<p>
</p>
<div dir="ltr">
<p>I now have a job at Google (outside of Geospatial), and have
been asked to present to Google's Geo team about misaligned
maps due to tectonic plate movements, and what to do about
that.</p>
</div>
</blockquote>
<p>I did not answered directly to the first question yet, but are
you aware of OGC GGXF effort?</p>
<blockquote>
<p><a href="https://github.com/opengeospatial/CRS-Gridded-Geodetic-data-eXchange-Format/" target="_blank">https://github.com/opengeospatial/CRS-Gridded-Geodetic-data-eXchange-Format/</a><br>
</p>
</blockquote>
<p align="justify">This is a proposed OGC standard format for
encoding the information needed for performing coordinate
transformations due to tectonic plate movements, among other
geodetic operations. It is currently based on netCDF, but we try
to split the standard in a "carrier neutral" core and an annex
which applies the core to netCDF-4 carrier. That way, it keeps the
door open for adding other carriers (e.g. ZARR or GeoTIFF) if
needed.<br>
</p>
<p align="justify">A little bit of history: ESRI and IOGP (the
maintainer of EPSG database) started to look at this issue maybe
5~10 years ago. ESRI already made a first proposal based on netCDF
at that time (so contrarily to what have been said on this mailing
list, this effort did not started because of PROJ doing something
similar 2 years ago). However that work had little progress until
2 years ago for human resource reason: CRS activity in the last
years at OGC has progressed a lot thanks to a man who accomplished
a tremendous amount of standardization work: Roger Lott from IOGP.
But Roger has been busy with the first version of ISO 19162 (WKT
2) before 2015, then with revision of ISO 19111 precisely for
taking in account plate movements (that ISO 19111 revision
introduced dynamic CRS and "Point Motion" operation), then with
revision of ISO 19162 for leveraging above-cited new capabilities,
and revision of EPSG database schema (version 10.x changed
significantly compared to 9.x) for same reason. Roger became
available for new work only 2 years ago.</p>
<p align="justify">The GGXF working group includes members from
IOGP, ESRI, AIG (International Association of Geodesy), various
mapping agencies and Chris Crook who helped to design the GeoTIFF
format used by PROJ for gridded datum shifts. So not only we are
well aware of the work PROJ initiated, but one of the key
designers of that work is one of the most active GGXF
contributors.</p>
<p align="justify">The group has produced two documents. One
document about deformation model (largely Chris's work) has been
completed and will be submitted at OGC for approval I think in
October. The other document is about the GGXF format itself, which
after 2 years of work is close to completion. The feasibility of
GGXF is tested by a prototype written in Python by Chris.</p>
<p align="justify">So to address the tectonic movements issue, I
think that OGC standards are putting pieces in place, thanks to
Roger's and Chris's work. I presume that when GGXF will be an
approved standard, it will be used in EPSG database as operation
parameters whose value is a path to a GGXF file. But there is a
delay of many years between standard approval and their actual
implementation in open source software. For example in Apache SIS,
we have not yet implemented the new features introduced in ISO
19111:2019 (point motion operations, etc.) and the corresponding
updates in ISO 19162:2019 and EPSG database version 10.x. In PROJ
as well, I'm not sure if "Point Motion operation" is already
implemented.</p>
<p align="justify">So I believe that OGC standards are in good
progress for addressing the issue raised by Cameron, but
implementations lag a few years behind (which is normal).</p>
<p align="justify"> Martin</p>
<p align="justify"><br>
</p>
</div>
_______________________________________________<br>
PROJ mailing list<br>
<a href="mailto:PROJ@lists.osgeo.org" target="_blank">PROJ@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/proj" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/proj</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><font color="#999999">Glen Rice</font></div><div><font color="#999999">National Bathymetric Source</font></div><div dir="ltr"><font color="#999999"><span style="font-size:12.8px">Hydrographic Systems and Technology Branch</span><br></font></div><div dir="ltr"><font color="#999999">Office of Coast Survey / Coast Survey Development Laboratory</font></div></div></div></div></div></div></div></div>