<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Eric,</p>
<p>You better know that me your challenges and constraints. My main
fear is that if you use non-conformant WKT (in syntax or in
spirit) for archival purposes, you might end up later in headaches
since most software will have issues understanding it. Reminds me
of some funky WKT in some LAS files...</p>
<p>Other possibility: use a conformant VERTCRS definition, and use
the REMARKS[] fields to explain in plain text how it was derived
from NAD83(20111) ellipsoidal heights<br>
</p>
<p>Even<br>
</p>
<div class="moz-cite-prefix">Le 26/03/2021 à 18:37, Eric Younkin -
NOAA Federal a écrit :<br>
</div>
<blockquote type="cite"
cite="mid:CAFe6qKh+0HbBL7rLEm95_qgkLFPo7vWrdSd2vWWp1STxwNakWA@mail.gmail.com">
<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"
moz-do-not-send="true">even.rouault@spatialys.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote">
<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" moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">PROJ@lists.osgeo.org</a>
<a href="https://lists.osgeo.org/mailman/listinfo/proj" target="_blank" moz-do-not-send="true">https://lists.osgeo.org/mailman/listinfo/proj</a>
</pre>
</blockquote>
<pre cols="72">--
<a href="http://www.spatialys.com" target="_blank" moz-do-not-send="true">http://www.spatialys.com</a>
My software is free, but my time generally not.</pre>
</div>
</blockquote>
</div>
<br>
<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>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>
</blockquote>
<pre class="moz-signature" cols="72">--
<a class="moz-txt-link-freetext" href="http://www.spatialys.com">http://www.spatialys.com</a>
My software is free, but my time generally not.</pre>
</body>
</html>