[PROJ] Constant vertical offset

Tue Nov 30 05:39:59 PST 2021

Javier,

I'm not sure we are concerned with the same use case, but your mention of
explicitly stating grids made me think there could be overlap with our
goals.

We are interested in explicitly stating the vertical datum as a
combination of grids in WKT(2), but we have been unsuccessful in making
this work operationally.  We started working at a VERTCRS with a
DERIVINGCONVERSTION as described here
<https://github.com/noaa-ocs-hydrography/vyperdatum/blob/8d2a83d78f74a926dc746da6604fb4a051086530/vyperdatum/vypercrs.py#L458>,
but this didn't seem to get where we wanted to go.  At this point we are
creating a compound CRS with a very simple VERTCRS with a remarks section
that contains the PROJ pipeline string (example here
<https://github.com/noaa-ocs-hydrography/vyperdatum/blob/8d2a83d78f74a926dc746da6604fb4a051086530/vyperdatum/vypercrs.py#L530>).
This solution is somewhat hamstrung by the remarks section being stripped
out of the WKT with GeoTIFFs, so at this point we have created a custom
GDAL Tiff Tag VERTICALDATUMWKT to store this information (example temp link
here
<https://noaa-ocs-nationalbathymetry-pds.s3.amazonaws.com/index.html#Bluetopo/US5NH1AH/>)
until we can find a better solution. [A side note for anyone that wants to
know why we did not just use the epsg code for NAVD88 in the above
example: NAVD88
as EPSG <https://epsg.org/crs_5703/NAVD88-height.html> is declared as an
ensemble of many different geoids which we prefer not to have included.]

While our process is tied into a bunch of business logic, we are interested
in making the data we make public as accessible as we can.  If there are
thoughts about how to solve this problem in a better way that facilitates
downstream use through explicit declaration of the grids in WKT I think we
would be interested in hearing other approaches.

Regards,
Glen

On Mon, Nov 29, 2021 at 11:12 AM Javier Jimenez Shaw <j1 at jimenezshaw.com>
wrote:

> I was thinking on a WKT that defines the offset as part of the CRS
> defintion, in a similar way the geoid grid file can be defined.
> .___ ._ ..._ .. . ._.  .___ .. __ . _. . __..  ... .... ._ .__
> Entre dos pensamientos racionales
> hay infinitos pensamientos irracionales.
>
>
>
> On Mon, 29 Nov 2021 at 17:05, Even Rouault <even.rouault at spatialys.com>
> wrote:
>
>> Javier,
>>
>> If you need a WKT2 with a coordinate operation, then you can simply wrap
>> any PROJ string expressing a coordinate operation like the following:
>>
>> $ projinfo "+proj=geogoffset +dh=5" -o WKT2:2019 -q
>>
>> CONVERSION["PROJ-based coordinate operation",
>>     METHOD["PROJ-based operation method: +proj=geogoffset +dh=5"]]
>>
>> Of course only interoperable in the PROJ universe.
>>
>> Otherwise using Transformation::createGeographic3DOffsets() /
>> createGeographic2DWithHeightOffsets() could have been an option, but if
>> your source and target CRS aren't geographic, PROJ will complain when
>> getting the PROJ transformation string.
>>
>> Even
>> Le 29/11/2021 à 16:53, Javier Jimenez Shaw a écrit :
>>
>> Thanks Even
>>
>> Is there anything equivalent to that as Vertical CRS to use in a
>> Compound? I know it is not correct geodetically, but I want it just as a
>> WKT temporary object. I just need that PROJ is able to understand it and
>> use it in a transformation.
>> That is, given a horizontal CRS, I want to create a compound (or anything
>> equivalent) with a vertical offset (as WKT2 if it makes things easier)
>>
>> Thanks.
>> .___ ._ ..._ .. . ._.  .___ .. __ . _. . __..  ... .... ._ .__
>> Entre dos pensamientos racionales
>> hay infinitos pensamientos irracionales.
>>
>>
>>
>> On Mon, 1 Nov 2021 at 17:01, Even Rouault <even.rouault at spatialys.com>
>> wrote:
>>
>>> Javier
>>> Le 01/11/2021 à 13:32, Javier Jimenez Shaw a écrit :
>>>
>>> Hi
>>>
>>> I want to make a transformation (at the end an
>>> operation::CoordinateOperation) that replaces the geoid model with a local
>>> constant value.
>>>
>>> In some cases there is public grid file for a geoid model, but I can get
>>> a (constant) undulation value (let's say 42.9m) in a (small) area of work.
>>> I would like to include this undulation value in the transformation.
>>>
>>> How can I do that? is there any pipeline option for that? (I do not see
>>> a way in https://proj.org/operations/transformations/vgridshift.html)
>>> Or a way to directly create the CoordinateOperation?
>>>
>>> You can use the
>>> https://proj.org/operations/transformations/geogoffset.html with the dh
>>> parameter. This is for example used for transformation EPSG:15596
>>>
>>> Even
>>>
>>>
>>> Thanks
>>> .___ ._ ..._ .. . ._.  .___ .. __ . _. . __..  ... .... ._ .__
>>> Entre dos pensamientos racionales
>>> hay infinitos pensamientos irracionales.
>>>
>>>
>>> _______________________________________________
>>> 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.
>>>
>>> -- http://www.spatialys.com
>> My software is free, but my time generally not.
>>
>> _______________________________________________
> PROJ mailing list
> PROJ at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/proj
>

-- 
Glen Rice
National Bathymetric Source
Hydrographic Systems and Technology Branch
Office of Coast Survey / Coast Survey Development Laboratory
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20211130/90172e6f/attachment.html>