<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0cm;
font-size:10.0pt;
font-family:"Courier New";}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;}
span.EmailStyle21
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="NL" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal" style="margin-left:35.4pt"><span lang="EN-GB">KE wrote:<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:35.4pt"><span lang="EN-GB">> Coincidentally I am working on a similar grid for Denmark. I’ve used VERTICAL_OFFSET_VERTICAL_TO_VERTICAL, which seems to fit the bill. </span><span lang="EN-GB" style="mso-fareast-language:EN-US"><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:35.4pt"><span lang="EN-GB" style="mso-fareast-language:EN-US">ER wrote:<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:35.4pt"><span lang="EN-GB">> I see that's what was used in the Norway case.</span><span lang="EN-GB" style="mso-fareast-language:EN-US"><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="mso-fareast-language:EN-US">The documentation (</span><a href="https://proj.org/specifications/geodetictiffgrids.html"><span lang="EN-GB" style="mso-fareast-language:EN-US">https://proj.org/specifications/geodetictiffgrids.html</span></a><span lang="EN-GB" style="mso-fareast-language:EN-US">)
indicates that </span><span lang="EN-GB">VERTICAL_OFFSET_</span><span lang="EN-GB" style="mso-fareast-language:EN-US">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 (</span><a href="https://github.com/OSGeo/PROJ-data/blob/master/grid_tools/vertoffset_grid_to_gtiff.py"><span lang="EN-GB" style="mso-fareast-language:EN-US">https://github.com/OSGeo/PROJ-data/blob/master/grid_tools/vertoffset_grid_to_gtiff.py</span></a><span lang="EN-GB" style="mso-fareast-language:EN-US">)
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:<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:35.4pt"><i><span lang="EN-GB" style="mso-fareast-language:EN-US">“Geoid model</span></i><span lang="EN-GB" style="mso-fareast-language:EN-US"> 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.”<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="mso-fareast-language:EN-US">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.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:35.4pt"><span lang="EN-GB" style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:35.4pt"><span lang="EN-GB" style="mso-fareast-language:EN-US">ER wrote:<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:35.4pt"><span lang="EN-GB" style="mso-fareast-language:EN-US">> W</span><span lang="EN-GB">e could potential extend PROJ to accept hydroidHeight as a valid band description name.</span><span lang="EN-GB" style="mso-fareast-language:EN-US"><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="mso-fareast-language:EN-US">That would make things more clear too. Would that apply to
</span><span lang="EN-GB">VERTICAL_OFFSET_</span><span lang="EN-GB" style="mso-fareast-language:EN-US">GEOGRAPHIC_TO_VERTICAL as well as
</span><span lang="EN-GB">VERTICAL_OFFSET_VERTICAL_TO_VERTICAL then?<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB">I am still a bit in doubt now what to do. Should I use
</span><span lang="EN-GB">VERTICAL_OFFSET_</span><span lang="EN-GB" style="mso-fareast-language:EN-US">GEOGRAPHIC_TO_VERTICAL which seems more appropriate, or should I use
</span><span lang="EN-GB">VERTICAL_OFFSET_VERTICAL_TO_VERTICAL to prevent a situation where LAT / Chart Datum grids of different countries use a different choice?<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB">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?
<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="mso-fareast-language:EN-US">Jochem<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> Even Rouault <even.rouault@spatialys.com>
<br>
<b>Sent:</b> donderdag 16 maart 2023 18:43<br>
<b>To:</b> Lesparre, Jochem <Jochem.Lesparre@kadaster.nl>; PROJ@lists.osgeo.org<br>
<b>Subject:</b> Re: [PROJ] Lowest Astronimical Tide reference surface in Geodetic TIFF Grid<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><span lang="EN-GB"><o:p> </o:p></span></p>
<p><span lang="EN-GB">Hi,<o:p></o:p></span></p>
<p><span lang="EN-GB">Cf </span><a href="https://github.com/OSGeo/PROJ/issues/2739"><span lang="EN-GB">https://github.com/OSGeo/PROJ/issues/2739</span></a><span lang="EN-GB">,
</span><a href="https://github.com/OSGeo/PROJ/pull/3010"><span lang="EN-GB">https://github.com/OSGeo/PROJ/pull/3010</span></a><span lang="EN-GB"> and
</span><a href="https://github.com/OSGeo/PROJ-data/pull/76"><span lang="EN-GB">https://github.com/OSGeo/PROJ-data/pull/76</span></a><span lang="EN-GB"> for a similar case for Norway<o:p></o:p></span></p>
<p><span lang="EN-GB">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 (</span><a href="https://raw.githubusercontent.com/opengeospatial/CRS-Gridded-Geodetic-data-eXchange-Format/master/specification/GGXF%20v1-0%20OGC-22-051r2_2023-01-09.pdf"><span lang="EN-GB">https://raw.githubusercontent.com/opengeospatial/CRS-Gridded-Geodetic-data-eXchange-Format/master/specification/GGXF%20v1-0%20OGC-22-051r2_2023-01-09.pdf</span></a><span lang="EN-GB">),
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.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB"><br>
<br>
<o:p></o:p></span></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-GB">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 “</span><span lang="EN-GB" style="font-size:10.0pt;font-family:"Arial",sans-serif;color:#303030;background:white">Geog3D to Geog2D+Depth (txt)”
(</span><a href="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"><span lang="EN-GB">https://epsg.org/coord-operation-method_1115/Geog3D-to-Geog2D-Depth-txt.html</span></a><span lang="EN-GB">)?
<o:p></o:p></span></p>
</div>
</blockquote>
<p><span lang="EN-GB">That should be sufficient. That's what is used for the Norway case (for the 'Geographic3D to Depth (Gravsoft)' method)<o:p></o:p></span></p>
<p><span lang="EN-GB">Even<o:p></o:p></span></p>
<p><span lang="EN-GB"><o:p> </o:p></span></p>
<pre><a href="http://secure-web.cisco.com/1NU-0JulCrJLRDZJdvWQTDOS7K4tcn6sG8TtGsqXahTmUki65uCwMwqkXmD7ffIu9KQ3pnDVzwNxr0KTZ6mK1PTHHgiW_azzqMmT-wkdNL5QDtEVU1Je-OuxxM2q1wxwvnJzG3qVjfETmiZjjXpfHGArKoxHWR62etoFBFNirvzMa-4grsOPQzZtTEtGB9cohTOPt8kt5eYDg_zqmim3TveSYEuK4i0J5Ra6q-ZkLmc3wYB2RoL000xBI364JyprRtlE-y7m3954dd70vKMHoBkJJWmOUWvhZJ9IBWIQqu8_kXgqn8scyLbpxQCZ_Cw9Zc41aOQmBdflXS9AfqTOxVw/http%3A%2F%2Fwww.spatialys.com"><span lang="EN-GB">http://www.spatialys.com</span></a><span lang="EN-GB"><o:p></o:p></span></pre>
<pre><span lang="EN-GB">My software is free, but my time generally not.<o:p></o:p></span></pre>
</div>
<br>
<br>
<font size="2">Disclaimer:<br>
De inhoud van deze e-mail is vertrouwelijk en uitsluitend bestemd voor de geadresseerde(n).<br>
Gebruik, openbaarmaking, vermenigvuldiging, verspreiding en/of verstrekking van deze informatie aan derden is niet toegestaan.<br>
Op al onze producten en diensten zijn onze algemene leveringsvoorwaarden van toepassing<br>
[https://www.kadaster.nl/algemene-leveringsvoorwaarden].<br>
<br>
Disclaimer:<br>
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.<br>
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.<br>
Our general terms and conditions of delivery apply to all our products and services<br>
[https://www.kadaster.com/general-terms-and-conditions]. <br>
</font>
</body>
</html>