<div dir="ltr"><div>Thanks for the replies, Even and Greg.</div><div><br></div><div>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.</div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr"><div><div dir="ltr" data-smartmail="gmail_signature"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div style="font-size:small"><div dir="ltr" class="gmail_attr">Even Rouault wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">For the case where it is a single step operation, you would have to define <br>
either one transformation for each grid (a bit like the records for GEOID99 <br>
where CONUS was split in 8 grids), or have a single transformation pointing to <br>
a single file made of several grids (PROJ's GeoTIFF TIFF Grids allow this).<br>
There's no method in EPSG where, for a given transformation, you can provide <br>
an arbitrary list of grids that wouldn't have the same extent (and that would <br>
make it inefficient for PROJ, or any other software, since you'll have to open <br>
each grid to figure out if its extent contains the point to transform)<br>
<br>
I'm not sure if it makes sense to define the individual datums without <br>
associated CRS. As far as I can see in EPSG, there's just one case where this <br>
happens with the vertical datum EPSG:5107 that has no corresponding CRS, but <br>
that datum is deprecated. But the introduction of the datum ensemble concept <br>
might perhaps change this.</blockquote><div><br></div></div></div></div></div></div></div></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Greg Troxel wrote:</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I can see why you would want to do that, but I don't think it fits the<br>
datum ensemble concept.  It's logically separate, and you are basically<br>
creating a CRS with a large extent that is defined to match a bunch of<br>
other CRSes with smaller extent in each of those extents, rather than<br>
aggregating successive refinements of the same thing.<br>
...<br>I basically view datum ensembles as an accomodation to people that don't<br>
really know what datum their data is in, not something to strive for.<br>
<br>
Now, if NOAA would like to publish a "chart datum" vertical datum which<br>
is defined as one datum, and has grid files that are based on area, and<br>
a transform from NAVD88 to that or NAD83 HAE to that, that would seem<br>
like an entirely reasonable approach.<br>
<br>
Basically I'm suggesting that you put the complexity of the sub-datums<br>
inside a datum you publish, rather than putting it on the outside world.<br>
</blockquote></div></div>