<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Jochem,</p>
<p>Yes, this is related to the ETRS89 related changes in the EPSG
database. </p>
<p><a class="moz-txt-link-freetext" href="EPSG:9281">EPSG:9281</a> which used to be "Amersfoort to ETRS89 (8)" has been
renamed to "Amersfoort to ETRS89-NLD [AGRS2010] (8)" and its
target CRS is now the national realization CRS "ETRS89-NLD
[AGRS2010]" instead of the generic ETRS89 one (similarly for Amersfoort
to ETRS89 (9)). PROJ prefers to do ETRF2000 to Amersfoort doing
ETRF2000 -> ETRS89 (using a null transformation created from
the datum ensemble at EPSG database import) followed by inverse
"Amersfoort to ETRS89 (5)" , rather than ETRF2000 ->
ETRS89-NLD [AGRS2010] + inverse "Amersfoort to ETRS89-NLD
[AGRS2010] (8)" because we have a direct transformation between
the CRS code for ETRF2000 -> ETRS89 , which shortcircuits the
attempt at trying ETRF2000 -> ETRS89-NLD [AGRS2010] which
requires more effort from a database search point of view, since
the "ETRS89-NLD [AGRS2010] to ETRF2000 (1)" transformation is
between the geocentric CRS. In
<a class="moz-txt-link-freetext" href="https://github.com/OSGeo/PROJ/pull/4709">https://github.com/OSGeo/PROJ/pull/4709</a>, I've added logic to force
the more expensive look up if the result set from the lighter look
ups only return operations using a datum ensemble member
<--> datum ensemble null transformation.</p>
<p>Regarding ETRS89 to Amersfoort, this is even worse since there
are direct transformations between both, which stops PROJ from
searching more. I've also been able to tweak that case since all
those operations have a remark that they have been replaced by
others. So in that case, we also use the more expensive lookup
which finally finds the operations going through ETRS89-NLD
[AGRS2010]</p>
<p>Even</p>
<div class="moz-cite-prefix">Le 10/03/2026 à 14:56, Lesparre, Jochem
via PROJ a écrit :<br>
</div>
<blockquote type="cite"
cite="mid:DU2P192MB223588C15C3E87FFE8559FDEEF46A@DU2P192MB2235.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:Aptos;}@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:12.0pt;
font-family:"Aptos",sans-serif;
mso-ligatures:standardcontextual;
mso-fareast-language:EN-US;}.MsoChpDefault
{mso-style-type:export-only;
mso-fareast-language:EN-US;}div.WordSection1
{page:WordSection1;}</style>
<div class="WordSection1">
<p class="MsoNormal"><span lang="EN-GB"
style="font-size:11.0pt;font-family:"Arial",sans-serif">Some
transformations that used to give correct results (e.g. in
PROJ 9.7.1) do no longer give results according to the
official transformation (Amersfoort to ETRS89 (9)) of the
Dutch national authority in PROJ 9.8.0. <o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB"
style="font-size:11.0pt;font-family:"Arial",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB"
style="font-size:11.0pt;font-family:"Arial",sans-serif">I
suspect it has to do with the introduction of national
realisations of ETRS89 in EPSG. Complicating factor is that
EPSG erroneously removed the superseded label from some
outdated transformations (Amersfoort to ETRS89 (5) and
Amersfoort to ETRS89 (6)). However, these old
transformations have a lower accuracy than the official one,
so I think PROJ should be able to still find the official
transformation.
<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB"
style="font-size:11.0pt;font-family:"Arial",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB"
style="font-size:11.0pt;font-family:"Arial",sans-serif">Why
can’t PROJ find it? Is there something else wrong in EPSG,
preventing PROJ to find the official transformation? Or is
this an issue in PROJ 9.8.0?<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB"
style="font-size:11.0pt;font-family:"Arial",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB"
style="font-size:11.0pt;font-family:"Arial",sans-serif">Jochem<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB"
style="font-size:11.0pt;font-family:"Arial",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB"
style="font-size:11.0pt;font-family:"Arial",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span lang="EN-GB"
style="font-size:11.0pt;font-family:"Arial",sans-serif">Example
1: Forward<o:p></o:p></span></b></p>
<p class="MsoNormal"><span lang="EN-GB"
style="font-size:11.0pt;font-family:"Arial",sans-serif">From
the national ETRS89 realisation to the national projected
CRS, PROJ uses the correct transformation Amersfoort to
ETRS89 (9):<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB"
style="font-family:Consolas">projinfo <a class="moz-txt-link-freetext" href="EPSG:11037">EPSG:11037</a> <a class="moz-txt-link-freetext" href="EPSG:28992">EPSG:28992</a>
--spatial-test intersects -o proj --hide-ballpark<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB"
style="font-size:11.0pt;font-family:"Arial",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB"
style="font-size:11.0pt;font-family:"Arial",sans-serif">But
from ETRF2000 and the ETRS89 ensemble PROJ doesn’t use the
official transformation of the national authority anymore:<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB"
style="font-family:Consolas">projinfo <a class="moz-txt-link-freetext" href="EPSG:9067">EPSG:9067</a> <a class="moz-txt-link-freetext" href="EPSG:28992">EPSG:28992</a>
--spatial-test intersects -o proj --hide-ballpark
<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB"
style="font-family:Consolas">projinfo <a class="moz-txt-link-freetext" href="EPSG:4258">EPSG:4258</a> <a class="moz-txt-link-freetext" href="EPSG:28992">EPSG:28992</a>
--spatial-test intersects -o proj --hide-ballpark
<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span lang="EN-GB"
style="font-size:11.0pt;font-family:"Arial",sans-serif">Example
2: Reverse<o:p></o:p></span></b></p>
<p class="MsoNormal"><span lang="EN-GB"
style="font-size:11.0pt;font-family:"Arial",sans-serif">From
the national projected CRS to the national ETRS89
realisation, PROJ uses the correct transformation Amersfoort
to ETRS89 (9):<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB"
style="font-family:Consolas">projinfo <a class="moz-txt-link-freetext" href="EPSG:28992">EPSG:28992</a> <a class="moz-txt-link-freetext" href="EPSG:11037">EPSG:11037</a>
--spatial-test intersects -o proj --hide-ballpark<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB"
style="font-size:11.0pt;font-family:"Arial",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB"
style="font-size:11.0pt;font-family:"Arial",sans-serif">But to
ETRF2000 and the ETRS89 ensemble PROJ doesn’t use the
official transformation of the national authority anymore:<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB"
style="font-family:Consolas">projinfo <a class="moz-txt-link-freetext" href="EPSG:28992">EPSG:28992</a> <a class="moz-txt-link-freetext" href="EPSG:9067">EPSG:9067</a>
--spatial-test intersects -o proj --hide-ballpark
<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB"
style="font-family:Consolas">projinfo <a class="moz-txt-link-freetext" href="EPSG:28992">EPSG:28992</a> <a class="moz-txt-link-freetext" href="EPSG:4258">EPSG:4258</a>
--spatial-test intersects -o proj --hide-ballpark<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="font-family:Consolas"><o:p> </o:p></span></p>
</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>
[<a class="moz-txt-link-freetext" href="https://www.kadaster.nl/algemene-leveringsvoorwaarden">https://www.kadaster.nl/algemene-leveringsvoorwaarden</a>].<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>
[<a class="moz-txt-link-freetext" href="https://www.kadaster.com/general-terms-and-conditions">https://www.kadaster.com/general-terms-and-conditions</a>]. <br>
</font>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre wrap="" class="moz-quote-pre">_______________________________________________
PROJ mailing list
<a class="moz-txt-link-abbreviated" href="mailto:PROJ@lists.osgeo.org">PROJ@lists.osgeo.org</a>
<a class="moz-txt-link-freetext" href="https://lists.osgeo.org/mailman/listinfo/proj">https://lists.osgeo.org/mailman/listinfo/proj</a>
</pre>
</blockquote>
<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>