[PROJ] New national ETRS89 realisations in EPSG messing things up in PROJ 9.8.0?

[Even Rouault]

Jochem,

Yes, this is related to the ETRS89 related changes in the EPSG database.

EPSG:9281 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 
https://github.com/OSGeo/PROJ/pull/4709, 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.

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]

Even

Le 10/03/2026 à 14:56, Lesparre, Jochem via PROJ a écrit :
>
> 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.
>
> 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.
>
> 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?
>
> Jochem
>
> *Example 1: Forward*
>
> From the national ETRS89 realisation to the national projected CRS, 
> PROJ uses the correct transformation Amersfoort to ETRS89 (9):
>
> projinfo EPSG:11037 EPSG:28992 --spatial-test intersects -o proj 
> --hide-ballpark
>
> But from ETRF2000 and the ETRS89 ensemble PROJ doesn’t use the 
> official transformation of the national authority anymore:
>
> projinfo EPSG:9067 EPSG:28992 --spatial-test intersects -o proj 
> --hide-ballpark
>
> projinfo EPSG:4258 EPSG:28992 --spatial-test intersects -o proj 
> --hide-ballpark
>
> *Example 2: Reverse*
>
> From the national projected CRS to the national ETRS89 realisation, 
> PROJ uses the correct transformation Amersfoort to ETRS89 (9):
>
> projinfo EPSG:28992 EPSG:11037 --spatial-test intersects -o proj 
> --hide-ballpark
>
> But to ETRF2000 and the ETRS89 ensemble PROJ doesn’t use the official 
> transformation of the national authority anymore:
>
> projinfo EPSG:28992 EPSG:9067 --spatial-test intersects -o proj 
> --hide-ballpark
>
> projinfo EPSG:28992 EPSG:4258 --spatial-test intersects -o proj 
> --hide-ballpark
>
>
>
> 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].
>
> _______________________________________________
> PROJ mailing list
> PROJ at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/proj

-- 
http://www.spatialys.com
My software is free, but my time generally not.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20260311/0eff7143/attachment.htm>