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

[Even Rouault]

Jack,

> 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

That's a good point, but the use of a datum ensemble to model this is quite 
surprising to me. According to ISO-19111:2019, a datum ensemble is a "group of 
multiple realizations of the same terrestrial or vertical reference system 
that, for approximate spatial referencing purposes, are not significantly 
different". One consequence of that would seem that all members of a same 
ensemble should have the same extent (otherwise if you use a 'random' member 
and its extent is not compatible with your point of interest, it is 
significantly different...). I'll raise the matter to EPSG.

> 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.
> Does this make sense and is it feasible? 

For the case where it is a single step operation, you would have to define 
either one transformation for each grid (a bit like the records for GEOID99 
where CONUS was split in 8 grids), or have a single transformation pointing to 
a single file made of several grids (PROJ's GeoTIFF TIFF Grids allow this).
There's no method in EPSG where, for a given transformation, you can provide 
an arbitrary list of grids that wouldn't have the same extent (and that would 
make it inefficient for PROJ, or any other software, since you'll have to open 
each grid to figure out if its extent contains the point to transform)

I'm not sure if it makes sense to define the individual datums without 
associated CRS. As far as I can see in EPSG, there's just one case where this 
happens with the vertical datum EPSG:5107 that has no corresponding CRS, but 
that datum is deprecated. But the introduction of the datum ensemble concept 
might perhaps change this.

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com