[PROJ] Lowest Astronimical Tide reference surface in Geodetic TIFF Grid

Fri Mar 17 02:10:06 PDT 2023

KE wrote:
> Coincidentally I am working on a similar grid for Denmark. I’ve used VERTICAL_OFFSET_VERTICAL_TO_VERTICAL, which seems to fit the bill.

ER wrote:
> I see that's what was used in the Norway case.

The documentation (https://proj.org/specifications/geodetictiffgrids.html) indicates that VERTICAL_OFFSET_GEOGRAPHIC_TO_VERTICAL should be used in case of 3D geographic input. And if one doesn’t read the documentation, but like me just runs the script (https://github.com/OSGeo/PROJ-data/blob/master/grid_tools/vertoffset_grid_to_gtiff.py) to convert a .gtx grid to a .tif grid then one is not even aware there is a “geoid_undulation” description in the .tif grid. And if one finds this description (e.g. with gdalinfo), one might conclude that “geoid_undulation” is used loosely just like in EPSG, where all Geog3D-to-GravityRelatedHeight and Geog3D-to-Geog2D-GravityRelatedHeight methods mention:
“Geoid model is used loosely in the parameter name. If the offset is between the ellipsoid and the geoid then the offset will be the geoid separation N. When the offset is between the ellipsoid and a realisation of the geoid through a vertical datum then the offsets C will form a height correction surface. A height correction surface differs from a geoid model by small amounts due to the difference between the geoid and the actual datum surface as well as some other assumptions regarding the gravity field.”

To prevent users to make different choices in similar use cases, the documentation should indicate what to do for Lowest Astronomical Tide (LAT) or other Chart Datum grids.

ER wrote:
> We could potential extend PROJ to accept hydroidHeight as a valid band description name.

That would make things more clear too. Would that apply to VERTICAL_OFFSET_GEOGRAPHIC_TO_VERTICAL as well as VERTICAL_OFFSET_VERTICAL_TO_VERTICAL then?

I am still a bit in doubt now what to do. Should I use VERTICAL_OFFSET_GEOGRAPHIC_TO_VERTICAL which seems more appropriate, or should I use VERTICAL_OFFSET_VERTICAL_TO_VERTICAL to prevent a situation where LAT / Chart Datum grids of different countries use a different choice?

Another question is if it is a good idea to add a Geodetic TIFF Grid for the transformation between the national levelling height system NAP and LAT of the Netherlands to EPSG? And should we add that instead of the ETRS89 – LAT transformation, or should we publish both in EPSG to shorten the number of transformation steps in PROJ?

Jochem

From: Even Rouault <even.rouault at spatialys.com>
Sent: donderdag 16 maart 2023 18:43
To: Lesparre, Jochem <Jochem.Lesparre at kadaster.nl>; PROJ at lists.osgeo.org
Subject: Re: [PROJ] Lowest Astronimical Tide reference surface in Geodetic TIFF Grid

Hi,

Cf https://github.com/OSGeo/PROJ/issues/2739, https://github.com/OSGeo/PROJ/pull/3010 and https://github.com/OSGeo/PROJ-data/pull/76 for a similar case for Norway

Using VERTICAL_OFFSET_VERTICAL_TO_VERTICAL / vertical_offset isn't super appropriate as this is intented for VerticalCRS to VerticalCRS but I see that's what was used in the Norway case. PROJ isn't super pedantic about that and just checks that geoid_undulation or vertical_offset are found in the band description. Looking at the beloved GGXF draft (https://raw.githubusercontent.com/opengeospatial/CRS-Gridded-Geodetic-data-eXchange-Format/master/specification/GGXF%20v1-0%20OGC-22-051r2_2023-01-09.pdf), they have distinguished geoid and hydroid cases with a "hydroidHeight" parameter, but ultimately the maths are the same. We could potential extend PROJ to accept hydroidHeight as a valid band description name.

Another, thing I was wondering is how to deal with the difference between height and depth. Should the Geodetic TIFF Grid specify ETRS89 + LAT NL depth (EPSG:9289) as target CRS, so EPSG would only have to make transformation code and a tif equivalent of the transformation method “Geog3D to Geog2D+Depth (txt)” (https://epsg.org/coord-operation-method_1115/Geog3D-to-Geog2D-Depth-txt.html<https://secure-web.cisco.com/1C0OGwbcSQayRKLMfTRpLb-EtR-PXOfProPA5vmhahSALbHJyreYBWZw_A36ZeSCiFwipwL8Ei4dd4poCrz-_ESacDyeG2lBpKkq72Yw-1oLUjf09O2WjX8FLim91QmPvSrB3ytqzVJ-UCdr5obZuxUnvR3DWNhhP27YZESiqmIZK6iYoFYWO7OhL6WLf_GT5heq1zxD_8mvrtFuiuVvhM36mhQviBCqGbz0MalLL4zgzcsML1cnTbAfFaurP94v01F0YFA8ZnYt1XhwmCBg02LkqoXJ77xCpKtQFs5JZNRuderEYbfDXy5zwoTq8PYTNjZszmwh9R3dVOcZ5gNRaYQ/https%3A%2F%2Fepsg.org%2Fcoord-operation-method_1115%2FGeog3D-to-Geog2D-Depth-txt.html>)?

That should be sufficient. That's what is used for the Norway case (for the 'Geographic3D to Depth (Gravsoft)' method)

Even

http://www.spatialys.com<http://secure-web.cisco.com/1NU-0JulCrJLRDZJdvWQTDOS7K4tcn6sG8TtGsqXahTmUki65uCwMwqkXmD7ffIu9KQ3pnDVzwNxr0KTZ6mK1PTHHgiW_azzqMmT-wkdNL5QDtEVU1Je-OuxxM2q1wxwvnJzG3qVjfETmiZjjXpfHGArKoxHWR62etoFBFNirvzMa-4grsOPQzZtTEtGB9cohTOPt8kt5eYDg_zqmim3TveSYEuK4i0J5Ra6q-ZkLmc3wYB2RoL000xBI364JyprRtlE-y7m3954dd70vKMHoBkJJWmOUWvhZJ9IBWIQqu8_kXgqn8scyLbpxQCZ_Cw9Zc41aOQmBdflXS9AfqTOxVw/http%3A%2F%2Fwww.spatialys.com>

My software is free, but my time generally not.

Disclaimer:
De inhoud van deze e-mail is vertrouwelijk en uitsluitend bestemd voor de geadresseerde(n).
Gebruik, openbaarmaking, vermenigvuldiging, verspreiding en/of verstrekking van deze informatie aan derden is niet toegestaan.
Op al onze producten en diensten zijn onze algemene leveringsvoorwaarden van toepassing
[https://www.kadaster.nl/algemene-leveringsvoorwaarden].

Disclaimer:
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed.
If you are not the intended recipient, you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.
Our general terms and conditions of delivery apply to all our products and services
[https://www.kadaster.com/general-terms-and-conditions].
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20230317/6b5db0c4/attachment-0001.htm>