[PROJ] Describing custom vertical datums in wkt
Even Rouault
even.rouault at spatialys.com
Fri Mar 26 10:49:44 PDT 2021
Eric,
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...
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
Even
Le 26/03/2021 à 18:37, Eric Younkin - NOAA Federal a écrit :
> 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 <mailto: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
> <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
> <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 list
>> PROJ at lists.osgeo.org <mailto:PROJ at lists.osgeo.org>
>> https://lists.osgeo.org/mailman/listinfo/proj <https://lists.osgeo.org/mailman/listinfo/proj>
>
> --
> http://www.spatialys.com <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
--
http://www.spatialys.com
My software is free, but my time generally not.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20210326/8511f63f/attachment.html>
More information about the PROJ
mailing list