[PROJ] Alternate use model on EPSG v10+ datum ensembles

[Greg Troxel]

Jack Riley - NOAA Federal via PROJ <proj at lists.osgeo.org> writes:

> OK, so the alternate use model of datum ensembles I'd like to pursue is for
> encapsulation of a set of realizations with extents that are mutually
> exclusive.  For example, I'd like to register a vertical CRS for (say)
> 'NOAA Chart depth' with a datum height ensemble where the set of datum
> members are realized within distinct extents. This vertical CRS/datum
> ensemble would then be used to define a compound CRS (e.g., geog2D
> NAD83(2011) + 'NOAA Chart depth'), and a coordinate operation would be
> defined to transform to/from (reversible) between that and a geog3D CRS.
> This transform involves one or more (if a multi-step operation) sets of
> gridded transforms in a 1:1 relationship with the extents of the ensemble
> members.  The idea being that proj would have to do the heavy lifting of
> point-by-point spatial tests per the defined extents in the metadata.

I can see why you would want to do that, but I don't think it fits the
datum ensemble concept.  It's logically separate, and you are basically
creating a CRS with a large extent that is defined to match a bunch of
other CRSes with smaller extent in each of those extents, rather than
aggregating successive refinements of the same thing.

So I would suggest this be "datum areal group" or some such words and
treated as a different concept.

Maybe I imagined it but I remember seeing something about this for NAD83
(2011, MA11, PA11) aaso being something that isn't really a datum
ensemble (even though there is an ensemble for each region).


This notion did get brought up in discussion of the problem of imagery
in TMS being in "WGS84", which even if one defuzzed to "current
realization" still isn't crust-fixed, and I think some wanted to at
least discuss having a world-wide areal group that aligned to
national (~crust-fixed) datums.  It didn't go very far, but I realize it
sort of fits your "chart datum" notion.)


> Does this make sense and is it feasible?  The big savings here is to avoid
> having to define distinct vertical CRSs plus the associated compound CRSs,
> as well as the separate coordinate operations attached to each datum
> member.  Not to mention alleviating the need for the user to identify and
> partition data set conversions according to the individual extents. The
> datum ensemble in question concerns NOAA VDatum which is comprised of
> approximately 50 constituent datum members.  That's pretty much entirely a
> consequence having to use regular gridding to define the transformations;
> the resolution must be constrained in areas which involve complex
> shoreline.  And we would would be looking at another set of defines for
> 'NOAA chart height' (more than a simple sign change; e.g., chart depth
> typically on a MLLW datum, whereas chart height per a MHW datum).

I don't think you get to avoid defining the  other CRSes.  Ensembles are
groups of defined CRSes.

I basically view datum ensembles as an accomodation to people that don't
really know what datum their data is in, not something to strive for.

Now, if NOAA would like to publish a "chart datum" vertical datum which
is defined as one datum, and has grid files that are based on area, and
a transform from NAVD88 to that or NAD83 HAE to that, that would seem
like an entirely reasonable approach.

Basically I'm suggesting that you put the complexity of the sub-datums
inside a datum you publish, rather than putting it on the outside world.

> There is one example in the v10 EPSG registry that demonstrates this
> alternate use model definition (datum members with mutually-exclusive
> extents), with vertical and compound CRSs, but no associated coordinate
> operations defined as of yet:
> Datum: British Isles height ensemble, EPSG Code 1288
> https://epsg.org/datum_1288/British-Isles-height-ensemble.html
> Vertical CRS: BI height, EPSG code 9451
> https://epsg.org/crs_9451/BI-height.html
> Compound CRS: ETRS89 + BI height, EPSG code 9452
> https://epsg.org/crs_9452/ETRS89-BI-height.html

It feels to me like the intent is that if anyone has data in any of
those and is trying to transform to HAE or EVRF/etc. then there is a
path from "this particular local orthometric height" to "british isles
height" to whatever.  I don't think there is any intent to have separate
transforms from each or at least I don't get it if so.  To me that's
what the 0.4m means - that set of datums is consistent at the 0.4m
level, and if you define transforms for each, they'll each have their
own accuracy.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20201217/9be02c2f/attachment.sig>