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

[Martin Desruisseaux]

Hello Glen

An alternative to BOUNDCRS with more flexibility would be 
COORDINATEOPERATION. 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 COORDINATEOPERATION can be used, it allows the declaration 
of INTERPOLATIONCRS and OPERATIONACCURACY elements among other. Example 
5 below shows its use in a "DHHN92 height to EVRF2007 height" 
transformation:

    http://docs.opengeospatial.org/is/18-010r7/18-010r7.html#143

I saw that the BoundCRS for "NAD83 / UTM zone 15N + NOAA Chart Datum" 
uses parameters that a paths to *.gtx files. This is a case where those 
files may be replaceable by GGXF files. Latest draft is available as a 
PDF document there:

    https://github.com/opengeospatial/CRS-Gridded-Geodetic-data-eXchange-Format/issues/40

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).

     Martin


Le 23/08/2022 à 16:58, Glen Rice - NOAA Federal via PROJ a écrit :

> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20220823/7f69f2fe/attachment-0001.htm>