<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">Le 31/01/2022 à 12:45, Lesparre, Jochem
a écrit :<br>
</div>
<blockquote type="cite"
cite="mid:AM0P192MB0482CC870191B6BD4F60CD58EF259@AM0P192MB0482.EURP192.PROD.OUTLOOK.COM">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta name="Generator" content="Microsoft Word 15 (filtered
medium)">
<style>@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;}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:#0563C1;
text-decoration:underline;}span.EmailStyle22
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}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]-->
<div class="WordSection1"><span lang="EN-GB"><o:p></o:p></span>
<p><span lang="EN-GB">I didn’t realise this, but it seems you
are right. It looks like the behaviour of PROJ has changed.
Although I like the new order (first vertical then
horizontal) better, it is very confusing that this has
changed. I wonder if this was a bug, or an intended
improvement?</span></p>
</div>
</blockquote>
<p>I would say this was a case that wasn't taken at all into account
during initial development since there was no test case in the
existing regression test suite for it. And it is particularly
difficult to model PROJ.4 string using +nadgrids and +geoidgrids
into ISO-19111 CRS, which is the representation model used by the
PROJ 6 coordinate transformation logic. So I use, or rather
abuse/extend, the BoundCRS concept building a CompoundCRS of a
BoundCRS of the horizontal CRS and a BoundCRS of the vertical CRS.
But in the PROJ.4 syntax the "pivot" CRS was implicitly WGS84, so
in those BoundCRS the targetCRS is WGS84. So when you transform to
EPSG:4937, PROJ also does a WGS84 to ETRS89 transformation, which
happens to be null luckily. And even if the target of the BoundCRS
was known to be ETRS89, it is unclear when using such CompoundCRS
of BoundCRS which order of operation should be applied, even more
than the concept of interpolation CRS is also absent in the
BoundCRS model. so all in all, there's little luck of reproducing
the PROJ.4 behaviour with such CRS object. Or one should take into
account the original PROJ.4 string attached to the CRS and have a
special transformation code path when detecting it. Given that
this is legacy syntax, probably not worth the effort.<br>
</p>
<span lang="EN-GB"><o:p></o:p></span>
<blockquote type="cite"
cite="mid:AM0P192MB0482CC870191B6BD4F60CD58EF259@AM0P192MB0482.EURP192.PROD.OUTLOOK.COM">
<div class="WordSection1">
<p style="margin-bottom:12.0pt"><span lang="EN-GB">So, if we
accept the change of behaviour in PROJ >=6, we only need
the naptrans2008 and 2018 grids for PROJ <6 users. PROJ
>=6 users can use the nlgeo2008 and 2018 grids instead.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:35.4pt"><span
lang="EN-GB">> On reflection, it might be better to have
the GeoTIFF SRS be the interpolation CRS (like in the
VERTICAL_TO_VERTICAL case, but in that case there's no other
sane choice), an explicit source_crs_code=7931 and
interpolation_crs_wkt=.... The </span><a
href="https://secure-web.cisco.com/16SSmij_qIqbZT7vkQpUgv3KX-6ecNxzEzEXIoOqSbC8wsdbTwfrbE_FHii5vpGRXpy7p7mDJPOV9wwZH5frOT8wENoH3KeWcaJNKsvOcWR102emBb5lTF8g_1Uy7RktJ2UUmj3z6nwbZkOZd3WQ6QeCVKSIRuOgLOe2qshPpMN0mjpyNmZCCOtzD-WFnTN9GJpjcLhgy0uPONd4jA9BqtfzV3_rO7ZZlnOt2NVivF9vXtsez9PnwTiLsFYEcz-qUn4KR6xmRX7nIWT4NeqSkOr2Nx-PEGX3Xx45MPDXKpKzAO5l7xVmeKxcee4UBtr2x8EfeJmv6rPQ8qjX_kOFdafhFPEwhG30LbhIKo8taaFs/https%3A%2F%2Fproj.org%2Fspecifications%2Fgeodetictiffgrids.html"
moz-do-not-send="true"><span lang="EN-GB">https://proj.org/specifications/geodetictiffgrids.html</span></a><span
lang="EN-GB"> page should be amended to document that, and
the validation script too. And perhaps the conversion
script too if that's thought to be a not-so-rare use case.<br>
<br>
<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB">That’s what I was
thinking. However, you won’t need a
interpolation_crs_wkt=.... in that case, as it would be the
same as the GeoTIFF SRS, right? </span></p>
</div>
</blockquote>
Yes, that was really to make it clear that the GeoTIFF SRS was the
interpolation CRS, but it could also just be something documented in
the spec<br>
<blockquote type="cite"
cite="mid:AM0P192MB0482CC870191B6BD4F60CD58EF259@AM0P192MB0482.EURP192.PROD.OUTLOOK.COM">
<div class="WordSection1">
<p class="MsoNormal"><span lang="EN-GB">Since the naptrans2008
and 2018 grids of the Netherlands are the only use case, and
these are only needed for PROJ <6, then we might not need
GeoTIFFs for these grids, I think. Maybe, this option could
be removed entirely?</span></p>
</div>
</blockquote>
I personally wouldn't mind, but it might potential break users who
rely on them explictly. Maybe Sebastiaan has some thoughts on that ?<br>
<br>
<pre class="moz-signature" cols="72">--
<a class="moz-txt-link-freetext" href="http://www.spatialys.com">http://www.spatialys.com</a>
My software is free, but my time generally not.</pre>
</body>
</html>