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

[Jack Riley - NOAA Federal]

Thanks for the replies, Even and Greg.

The GEOID99 example helped me understand that in EPSG gridded data
transformation extents don't have to encompass the (larger) extents of the
source & target CRS.  So the "chart datum" realizations may be a singular
CRS/datum construct, and N transformations may be attached to that src/tgt
per tiled extents of gridded data therein.  Under that model, we will have
to segregate PROJ actions according to the spatial extent attributed to
each individual transform (similar to NAD83(HARN) to NAVD88 transformations
per the bounds of the various GEOID99 grids).  Regarding the single
transformation option: Can an EPSG transformation parameter point to a
GeoTIFF TIFF Grids model file containing several grids, and PROJ would
handle lookup/interpolation of the appropriate grid on-the-fly?  I'm not
aware of any multi-grid storage formats referenced by EPSG outside of NTV2,
but those nodes hold horizontal corrections for lat & lon, rather than
vertical shift values.


Even Rouault wrote:

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


Greg Troxel wrote:

> 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.
> ...
> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20201217/13c5aa1f/attachment.html>