[PROJ] Pitching the proj project to Google's Geo team

Tue Aug 23 07:58:17 PDT 2022

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 National Bathymetric
Source project <https://www.nauticalcharts.noaa.gov/data/bluetopo.html>
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.

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 here
<https://github.com/OpenNavigationSurface/crs_specification/blob/main/examples/boundcrs_compound.py>)
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.

One of our current struggles has been to operationalize this approach to
dealing with explicit vertical datums and their uncertainty.

Hopefully that is useful and on point.
Glen

On Tue, Aug 23, 2022 at 10:11 AM Martin Desruisseaux <
martin.desruisseaux at geomatys.com> wrote:

> Le 20/08/2022 à 23:40, Cameron Shorter via PROJ a écrit :
>
> 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.
>
> I did not answered directly to the first question yet, but are you aware
> of OGC GGXF effort?
>
>
> https://github.com/opengeospatial/CRS-Gridded-Geodetic-data-eXchange-Format/
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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).
>
>     Martin
>
>
> _______________________________________________
> PROJ mailing list
> PROJ at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/proj
>

-- 
Glen Rice
National Bathymetric Source
Hydrographic Systems and Technology Branch
Office of Coast Survey / Coast Survey Development Laboratory
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20220823/22ad402f/attachment.htm>