[PROJ] Could you please explain me why I can't project RDN2008 (EPSG:6706) to ERTF2000 (EPSG:9067) or ITRF2000 (EPGS:8997)

[Even Rouault]

Le 19/07/2022 à 18:37, Greg Troxel a écrit :
> Even Rouault <even.rouault at spatialys.com> writes:
>
>> See the manually added records starting at
>> https://github.com/OSGeo/PROJ/blob/5b2d59b68f931303d73e742763309d258f9335d4/data/sql/customizations.sql#L187. "manually"
>> here means "not done in code": an alternative would be to explore the
>> datum ensembles and their members in the database and figure out the
>> null transformation between them. Given the relatively low number of
>> datum ensembles in the EPSG database (essentially only WGS 84 and
>> ETRS89), the manual way is much easier to implement than new code.
> Thank you for the pointer.
>
> I find the word "manual" to be very confusing here.  As I see it, this
> is basically forming a database which is the union of the EPSG database
> and some other entries.  Arguably, these entries or something like them
> should be in the EPSG database, but they aren't for various reasons.
One can see them as implicitly present in the EPSG database from the 
definition of each datum ensemble. It is just that this isn't super 
convenient for PROJ direct use.
>
> I wonder if instead, or probably, we should have transforms from each
> member to the next, as particularly for recent members the accuracy
> statement can be vastly lower.
That could be done, although I'm not sure this would help that much 
compared to having each datum ensemble member <--> datum ensemble 
transformation.
>
>> (to be pedantic we only record transformation from each member of the
>> ensemble to the ensemble, to avoid the combinatory explosion of
>> registering transformations between each member. but PROJ is smart
>> enough to combine 2 (not more) steps to do e.g WGS 84 (G1674) -> WGS
>> 84 (G1762) as WGS 84 (G1674) -> WGS 84 (ensemble) -> WGS 84 (G1762) )
> Is that limitation fundamental?

when you have one intermediate CRS as currently, in SQL, this is a (very 
complicated) self JOIN with the coordinate_operation_view appearing 
twice (and joining with other tables to account for the fact that most 
transformations are defined only between geographic 2D CRS, but the 
transformations we want to do may involve their related geographic 3D or 
geocentric CRS). Potential complexity O(N^2) in the number of coordinate 
operations

(it is actually the union of 4 such self JOIN to take into account that 
the 'left' and 'right' operations must be considered in the forward and 
inverse transformation)

If you allowed 2 intermediate CRS, that would be (really very 
complicated) self JOIN with the coordinate_operation_view appearing 
three times. Potential complexity O(N^3)

etc.

So computation time and code could become very ugly

A potential enhancement to PROJ would be to have a way for it to know 
which intermediate datums must be considered, so it is guided in its 
search, probably by defining "generation of datums" that apply to some 
area (e.g for the US: NAD27, NAD83 (86), NAD83(HARN), NAD83(NSRS2007), 
NAD83(2011))

But the more transformations PROJ chain together, the more questionable 
they are. One hop as done currently probably already covers > 90% of the 
cases.

That said, if we implemented the NADCON5 grids, a more complex logic 
would be needed as they are provided only for successive datums in the 
above mentionned NAD datums, and AFAIR, they recommend chaining them 
when wanting to transform between non immediately consecutive datums.

>   It could be reasonable to go through
> multiple steps from WGS84(TRANSIT) to WGS84(G2139), some of which are
> not null transforms.
Are such non-null transforms between members published somewhere ? 
Anyway, if they existed in its database, PROJ would use them in priority 
compared to chaining WGS84(XXX) -> WGS84(ensemble)->WGS84(YYYY)
>    Anyway we can avoid traversing an ensemble to
> solve a requested transform seems better as there is an intrinsic loss
> of accuracy from ensembles where we pause at "we don't really know what
> frame the data is in".

-- 
http://www.spatialys.com
My software is free, but my time generally not.