[PROJ] Describing custom vertical datums in wkt

Fri Mar 26 10:37:42 PDT 2021

Hi Even,

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.

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.

Thanks,
Eric

On Fri, Mar 26, 2021 at 12:58 PM Even Rouault <even.rouault at spatialys.com>
wrote:

> Eric,
>
> Besides a few minor issues in the below WKT (use of single quotes, or
> non-ASCII double quote characters), more fundamental remarks:
>
> - I don't think DerivedVerticalCRS is the appropriate modeling.
> http://docs.opengeospatial.org/is/18-010r7/18-010r7.html 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
> http://docs.opengeospatial.org/is/18-010r7/18-010r7.html#120, VDATUM[] is
> not allowed for the derived vertical CRS, and when PROJ re-exports to WKT2
> this definition, it will omit it.
>
> - 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
>
> - 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.
>
> - 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[].
>
> - 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.
>
> Even
> Le 26/03/2021 à 16:06, Eric Younkin - NOAA Federal via PROJ a écrit :
>
> Hello,
>
> 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:
>
> VERTCRS["NOAA Chart Datum",
>                   BASEVERTCRS["NAD83(2011) Height",
>                                               VDATUM["NAD83(2011) Height"],
>                                               ID["EPSG",6319]],
>                   DERIVINGCONVERSION["NAD83(2011) Height to NOAA Mean
> Lower Low Water",
>                                                METHOD["VDatum_VXXX gtx
> grid transformation",
>                                                   ID["EPSG",1084]],
>                                                 PARAMETERFILE['g2012bu0',
> 'core\\geoid12b\\g2012bu0.gtx',
>                                                   ID[“NOAA VDatum”, “NAD83
> to Geoid12B”, “10/23/2012”]],
>                                                 PARAMETERFILE['tss',
> 'CAORblan01_8301\\tss.gtx',
>                                                   ID[“NOAA VDatum”,
> “Geoid12B to Tss", “06/20/2019”]],
>                                                 PARAMETERFILE['mllw',
> 'CAORblan01_8301\\mllw.gtx',
>                                                   ID[“NOAA VDatum”, “Tss
> to Mean Lower Low Water”, “06/20/2019”]]],
>                     VDATUM["NOAA Chart Datum"],
>                     CS[vertical,1],
>                           AXIS["gravity-related height (H)",up],
>                           LENGTHUNIT["metre",1]]
>
> 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.
>
> Hopefully that made sense.  Please let me know if you have any suggestions.
>
> Thanks,
> Eric
>
> --
> Eric Younkin
> Physical Scientist
> NOAA OCS, Hydrographic Systems and Technology Branch
> 1315 East-West Highway
> N/CS11, Room 6604
> Silver Spring, MD 20910
> Office: 240-847-8208
> Cell: 828-331-8197
>
> _______________________________________________
> PROJ mailing listPROJ at lists.osgeo.orghttps://lists.osgeo.org/mailman/listinfo/proj
>
> -- http://www.spatialys.com
> My software is free, but my time generally not.
>
>

-- 
Eric Younkin
Physical Scientist
NOAA OCS, Hydrographic Systems and Technology Branch
1315 East-West Highway
N/CS11, Room 6604
Silver Spring, MD 20910
Office: 240-847-8208
Cell: 828-331-8197
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20210326/8e211642/attachment-0001.html>