<div dir="ltr">Hi Even,<div><br></div><div>Thanks for these notes. I agree that what I have isn't great. Ideally we will be following what you describe as the 'proper model' when we move to register in EPSG. What I have here is our attempt to build something that at the very least documents the process and does so in a way that does not require the creation of a separate NOAA Chart Datum definition, since our archived data would just have one WKT field to represent the data CRS. </div><div><br></div><div>I was planning on manually defining pipelines from this WKT string to run through PROJ, using some code to wrap the WKT. We currently define end point datums in our data with just a 'MLLW' string, so I figured this would at least be better for now. But perhaps this is not a step in the right direction. Maybe moving to EPSG is the only route forward for us, and we should wait for that process before making any changes, regardless of how bad what we currently do is. </div><div><br></div><div>Thanks,<br>Eric</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Mar 26, 2021 at 12:58 PM Even Rouault <<a href="mailto:even.rouault@spatialys.com">even.rouault@spatialys.com</a>> 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">
<div>
<p>Eric,</p>
<p>Besides a few minor issues in the below WKT (use of single
quotes, or non-ASCII double quote characters), more fundamental
remarks:</p>
<p>- I don't think DerivedVerticalCRS is the appropriate modeling.
<a href="http://docs.opengeospatial.org/is/18-010r7/18-010r7.html" target="_blank">http://docs.opengeospatial.org/is/18-010r7/18-010r7.html</a> in §3.1.14
mentions: "A derived coordinate reference system inherits its
datum or reference frame from its base coordinate reference
system.", so you can't have the derived CRS having VDATUM["NOAA
Chart Datum"] and the base CRS VDATUM["NAD83(2011) Height"]. And
if you look at the grammar at
<a href="http://docs.opengeospatial.org/is/18-010r7/18-010r7.html#120" target="_blank">http://docs.opengeospatial.org/is/18-010r7/18-010r7.html#120</a>,
VDATUM[] is not allowed for the derived vertical CRS, and when
PROJ re-exports to WKT2 this definition, it will omit it.<br>
</p>
<p>- One could question too if the derivation is a conversion.
§14.2.1 mentions "Because by definition coordinate conversions are
exact, the attribute operation accuracy is not relevant and
excluded from the deriving conversion WKT string". Using grids is
probably a big unusual to define a conversion</p>
<p>- you can't use EPSG:6319 that is the Geographic 3D CRS as a
(base) vertical CRS. Ellipsoidal heights in ISO-19111 can't exist
as standalone vertical CRS. They must be associated with the
horizontal coordinates.</p>
<p>- the proper model would probably be to define a NOAA Chart Datum
vertical datum and vertical CRS, and define a transformation
between EPSG:6319 and the NOAA Chart Datum vertical CRS. You could
reference that transformation in a GEOIDMODEL[] node attached as a
child of the VERTCRS[].<br>
</p>
<p>- besides importing/exporting/querying the attributes, PROJ will
not be able currently to do anything useful (ie compute a PROJ
pipeline between that and another vertical CRS) with a derived
projected CRS.<br>
</p>
<p>Even<br>
</p>
<div>Le 26/03/2021 à 16:06, Eric Younkin -
NOAA Federal via PROJ a écrit :<br>
</div>
<blockquote type="cite">
<div dir="ltr">Hello,
<div><br>
</div>
<div>As we move to registering our vdatum grids in EPSG, we
needed to develop a stop gap solution, describing our custom
datums in WKT for archival. These would be derived datums
based on elheight or geoid height, with proj vgrid pipelines
applied to get to water level datum. We are thinking about
using something like this:</div>
<div><br>
</div>
<div>VERTCRS["NOAA Chart Datum",<br>
BASEVERTCRS["NAD83(2011) Height",<br>
VDATUM["NAD83(2011) Height"],<br>
ID["EPSG",6319]],<br>
DERIVINGCONVERSION["NAD83(2011) Height to
NOAA Mean Lower Low Water",<br>
METHOD["VDatum_VXXX gtx grid transformation",<br>
ID["EPSG",1084]],<br>
PARAMETERFILE['g2012bu0', 'core\\geoid12b\\g2012bu0.gtx',<br>
ID[“NOAA
VDatum”, “NAD83 to Geoid12B”, “10/23/2012”]],<br>
PARAMETERFILE['tss', 'CAORblan01_8301\\tss.gtx',<br>
ID[“NOAA
VDatum”, “Geoid12B to Tss", “06/20/2019”]],<br>
PARAMETERFILE['mllw', 'CAORblan01_8301\\mllw.gtx',<br>
ID[“NOAA
VDatum”, “Tss to Mean Lower Low Water”, “06/20/2019”]]],<br>
VDATUM["NOAA Chart Datum"],<br>
CS[vertical,1],<br>
AXIS["gravity-related height
(H)",up],<br>
LENGTHUNIT["metre",1]]<br>
</div>
<div><br>
</div>
<div>I know this isn't something we could use in PROJ in the
same way that a registered EPSG reference could, but we could
at least have something describing what we do for archival.
I'm thinking of building some code to manually translate a
move between two of these WKT strings into a pipeline
operation.</div>
<div><br>
</div>
<div>Hopefully that made sense. Please let me know if you have
any suggestions.</div>
<div><br>
</div>
<div>Thanks,<br>
Eric</div>
<div>
<div><br>
</div>
-- <br>
<div dir="ltr">
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr"><span>Eric Younkin<br>
Physical Scientist<br>
</span></div>
<div dir="ltr"><span>NOAA OCS, </span><span>Hydrographic
Systems and Technology Branch</span></div>
<div dir="ltr"><span>1315 East-West
Highway</span></div>
<div dir="ltr"><span>N/CS11, Room 6604<br>
Silver Spring, MD 20910</span></div>
<div><span>Office: </span><span>240-847-8208</span></div>
<div dir="ltr"><span>
Cell: 828-331-8197<br>
</span></div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
PROJ mailing list
<a href="mailto:PROJ@lists.osgeo.org" target="_blank">PROJ@lists.osgeo.org</a>
<a href="https://lists.osgeo.org/mailman/listinfo/proj" target="_blank">https://lists.osgeo.org/mailman/listinfo/proj</a>
</pre>
</blockquote>
<pre cols="72">--
<a href="http://www.spatialys.com" target="_blank">http://www.spatialys.com</a>
My software is free, but my time generally not.</pre>
</div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><span><font color="#0000ff">Eric Younkin<br>Physical Scientist<br></font></span></div><div dir="ltr"><span><font color="#0000ff">NOAA OCS, </font></span><span style="color:rgb(0,0,255);font-size:12.8px">Hydrographic Systems and Technology Branch</span></div><div dir="ltr"><span><font color="#0000ff">1315 East-West Highway</font></span></div><div dir="ltr"><span><font color="#0000ff">N/CS11, Room 6604<br>Silver Spring, MD 20910</font></span></div><div><span><font color="#0000ff">Office: </font></span><span style="font-family:arial,sans,sans-serif;font-size:13px;white-space:pre-wrap"><font color="#0000ff">240-847-8208</font></span></div><div dir="ltr"><span><font color="#0000ff">
Cell: 828-331-8197</font><br>
</span></div></div></div></div></div></div></div></div></div></div></div></div>