[Draft] Do not use ITRF2020 as an intermediate for NAD83(2011) to NATRF2022

[rouault]

Was confirmed to be inappropriate by NOAA. They will publish grid based transformations for that.

The downside (benefit?) is that the generic logic that avoid that also avoids using the ETRF2000 intermediate for 'ETRS89-PRT [1995]' to 'ETRS89-ESP [ERGNSS]', which breaks one of our test, but perhaps for good reasons. Trying to clarify with EPSG what should be done for that one, given this is suggested by IOGP guidance note 7-7 para 6.3.4 " Relationship between national realizations using an operation pipeline through the hub"

[kbevers]

Does this problem go away if NOAA publishes a direct transformation between NAD83(2011) and NATRF2022? I assumue the issue comes up because PROJ tries to find a way on it's own

[jjimenezshaw]

Does this problem go away if NOAA publishes a direct transformation between NAD83(2011) and NATRF2022? I assumue the issue comes up because PROJ tries to find a way on it's own

They said:
"The definitive NAD 83(2011) epoch 2010.00 to NATRF2022 epoch 2020.00 transformations will be grid-based, region-by-region, and come from NADCON"

[kbevers]

From https://www.ngs.noaa.gov/TOOLS/Nadcon/Nadcon.shtml:

NADCON – North American Datum Conversion Utility

*** This software has been superseded and replaced by NGS Coordinate Conversion and Transformation Tool (NCAT) and has been retained for historical context. For comments or questions please contact the NGS Infocenter ***

Sounds promising... Anyways, what I was getting at, if they put that grid based transformation in EPSG surely this isn't a problem we need to special case in code?

[jjimenezshaw]

this isn't a problem we need to special case in code?

If the user does not have the grids, thet it could take that wrong path via ITRF, right?

[rouault]

Does this problem go away if NOAA publishes a direct transformation between NAD83(2011) and NATRF2022? I assumue the issue comes up because PROJ tries to find a way on it's own

I had to experiment to be totally sure (as there are a number of situations where even a direct path is available we try an intermediate) and the answer is: yes, if there's a direct transformation, the ITRF2020 intermediate will not be considered.
That said, it doesn't fundamentally invalidate the need to tweak our logic:

• we don't know when such record will land to EPSG, so in the meantime users would get wrong results
• fundamentally doing static CRS -> dynamic CRS -> static CRS seems wrong, doesn't it ? Or at least we need some tweaking on how to handle the time dependency in that process. I'd bet the current 'ETRS89-PRT [1995]' to 'ETRS89-ESP [ERGNSS]' using ETRF2000 intermediate we have is wrong

For the record, my fictional DB entry:

diff --git a/data/sql/grid_transformation.sql b/data/sql/grid_transformation.sql
index 9a201164d5..fe7be7bf32 100644
--- a/data/sql/grid_transformation.sql
+++ b/data/sql/grid_transformation.sql
@@ -1996,3 +1996,6 @@ INSERT INTO "grid_transformation" VALUES('EPSG','15961','RGNC91-93 to NEA74 Noum
 INSERT INTO "usage" VALUES('EPSG','11972','grid_transformation','EPSG','15961','EPSG','2823','EPSG','1027');
 INSERT INTO "grid_transformation" VALUES('EPSG','15962','RGNC91-93 to IGN72 Grande Terre (6)','Emulation using NTv2 method of tfm IGN72 Grande Terre to RGNC91-93 (4) (code 9329). Note reversal sign of of parameter values in grid file.','EPSG','9615','NTv2','EPSG','4749','EPSG','4662',0.1,'EPSG','8656','Latitude and longitude difference file','RGNC1991_IGN72GrandeTerre.gsb',NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,'ESRI-Ncl 0.1m',0);
 INSERT INTO "usage" VALUES('EPSG','11973','grid_transformation','EPSG','15962','EPSG','2822','EPSG','1031');
+
+INSERT INTO "grid_transformation" VALUES('EPSG','XXXX','NAD83(2011) to NATRF2022','','EPSG','9615','NTv2','EPSG','6318','EPSG','10968',0.03,'EPSG','8656','Latitude and longitude difference file','xxOSTN15_NTv2_OSGBtoETRS.gsb',NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,'OSGB-UK Gbr15 NT',0);
+INSERT INTO "usage" VALUES('EPSG','usage_XXXX','grid_transformation','EPSG','XXXX','EPSG','4803','EPSG','1252');
diff --git a/data/sql/proj.db.sql.expected.md5 b/data/sql/proj.db.sql.expected.md5
index cd319fb90d..1e9630abc9 100644
--- a/data/sql/proj.db.sql.expected.md5
+++ b/data/sql/proj.db.sql.expected.md5
@@ -1 +1 @@
-8d352a923eb8e5d3beed6f2d3106074f
+d7a9c429fdf044ff9e52bc707a968703

[kbevers]

we don't know when such record will land to EPSG, so in the meantime users would get wrong results

My view is that geodetic authorities should take responsibility in cases like this. It shouldn't be surprising to NOAA that software and downstream users rely on the information in EPSG.

fundamentally doing static CRS -> dynamic CRS -> static CRS seems wrong, doesn't it ?

I don't see anything wrong in going down that route, but there will be many cases where it is not possible. For it to make sense you need to have some information about coordinate epochs and I suspect that's not available in 99% of cases. You might get away with using the inherent epoch of the static CRS's, not sure if that would be a bullet proof solution though

Nonetheless, this is a difficult situation to handle. I guess we offer ways to get warnings about non-ideal situations (missing grids etc) as well as give users the option to choose only the best available transformation and avoiding ballparks. It all depends on the user or settings in downstream software though.

[rouault]

Nonetheless, this is a difficult situation to handle. I guess we offer ways to get warnings about non-ideal situations (missing grids etc) as well as give users the option to choose only the best available transformation and avoiding ballparks. It all depends on the user or settings in downstream software though.

in the 'ETRS89-PRT [1995]' to 'ETRS89-ESP [ERGNSS]' situation, projinfo (or equivalent use of the underlying API) will report that a time-dependent operation is involved, but cs2cs won't (the warning I added recently was only when the source or target CRS are dynamic and no coordinate epoch is provided). In that case, given that the 'ETRS89-ESP [ERGNSS]' to ETRF2000 transformation is null, the only remaining one is the 'ETRS89-PRT [1995]' to ETRF2000 part which uses as central epoch the same value as then anchorepoch of "ETRS89-PRT [1995]" : 1995.4.
So I suspect it might somehow accidentally work here...

$ echo 40 -10 | bin/cs2cs -d 8  'ETRS89-PRT [1995]'  'ETRS89-ESP [ERGNSS]' 
40.00000014	-10.00000003 0.00570560

$ echo 40 -10 0 1995.4 | bin/cs2cs -d 8  'ETRS89-PRT [1995]'  'ETRS89-ESP [ERGNSS]' 
40.00000014	-10.00000003 0.00570560 1995.4

It shouldn't be surprising to NOAA that software and downstream users rely on the information in EPSG.

Yes. In practice their experts (speaking broadly, not just NOAA) seem only to be knowledgable of their "in-house" solution, which is humanly understandable. Hence thoughts about feeding EPSG, and practical consequences of how records behave in software are an after thought. We have the difficultnearly impossible task of making something generic work by just data mining with heuristics. Or maybe we should give up and

if (  NAD83(2011) to NATRF2022 ) then
...
else if( RGF93v2 to NTF) then
....

I wouldn't be surprised that a number of coordinate transformation packages are slightly improved versions of this.