[PROJ] Combining custom transformations with EPSG

[Kristian Evers]

Even,

Thanks for you feedback and confirming my suspicion about PROJ’s limitation.

> Happy to see too that we are able to encode custom advanced transformations in 
> the formalism of the database. 

So am I! You’ve done a great job making all this work.

> 
> Side notes:
> - the ETRF92_2000_TO_ETRF92_1994 transformation would in an ideal world be 
> encoded as a point motion operation (similarly to EPSG:7957 "Canada velocity 
> grid v6" that we don't support) if we had ways of doing change of coordinate 
> epoch in a "cleaner" way than what we do currently, that is that 
> createOperations() could take a input and output coordinate epoch. But that 
> would bring new interesting problems regarding on at which step you do the 
> coordinate epoch change . I remember there's a EPSG guidance note that 
> examines different scenarios regarding that, but not sure that it adresses all 
> cases we could hit.
> Hum actually looking closer at the way you define this transformation, that 
> couldn't be a point motion operation as your target CRS code != source CRS, 
> saying that ETRF92 at 1994.704 == ETRS89 in Denmark.

It’s a bit tricky, but yes, the endpoint is a static frame which effectively is a snapshot
of ETRS89/ETRF92 at epoch 1994.704. It is common practice to put a local name
on such realizations of ETRS89, e.g. the Swedish SWEREF99, but unfortunately
that was never done for the Danish realization of ETRS89. Hence using the ETRS89
ensemble EPSG:4936. I may add NKG:DK CRS/datum to make things clearer but I
haven’t decided on that yet.

> 
> - ETRF2000_TO_NKG_ETRF00 using a fixed central epoch would need to be another 
> kind of operation. It would be a bit like the time-specific Helmert 
> transformation that is used in a few EPSG transformations (but we currently 
> don't map to a PROJ transformation).

I am not sure I follow, are you thinking about a WKT2-mapping of +proj=deformation?
Or perhaps an EPSG-mapping? At some point I will get round to submitting these
transformations to the EPSG registry.

> You guessed right. Figuring out that ITRF2008 to ETRS89 needs to go through 
> ITRF2014 and then NKG_ETRF00 as intermediate steps is out of reach of PROJ 
> inference capabilities.  It indeed "just" manages one hop. For performance 
> results mostly and because the SQL requests would be quite horrific (have a 
> look at AuthorityFactory::createFromCRSCodesWithIntermediates() and
> AuthorityFactory::createBetweenGeodeticCRSWithDatumBasedIntermediates() for 
> the "simple" version with just one intermediate). And with just one hop, in 
> some cases that can lead to hundreds of results being returned.
> 

I figured. I think I remember we had a discussion about this way back when. It’s
good to get confirmed that is the case.

> So my suggesting would be that you create concatenated operations for
> ITRFxxxx -> NKG_ETRF00
> chaining ITRFxxxx -> ITRF2014 and ITRF2014 -> NKG_ETRF00

That would probably work, yes. Another solution is to not use NKG_ETRF00
as a hub at all and simply make one big concatenated operation from ITRF2000
to each national realization of ETRS89. In this particular setup I actually don’t
need the NKG_ETRF00 as a hub. That was usefull in the init-file but shouldn’t
be necessary here. 

> 
> One idea I had in the past to make PROJ inference a bit more powerful, without 
> going to a full 2 or 3-hops database lookups would be do define "families" of 
> datums, that is sets of datums that are known to be related by 
> transformations, which would guide PROJ in infering more transformation paths. 
> For example the various NAD83(xxxx) datum (especially if NADCON5 is 
> integrated, which has transformations only between 'consecutive' NAD83(xxxx) 
> variants, but not between arbitrary pairs of them), or ITRFxxxx, could be such 
> families. Writing that, it looks a bit like the DatumEnsemble concept, except 
> that we wouldn't constraint those datums to be considered as "equivalent" for 
> lower accuracy purposes. Anyway this is just an idea without any 
> implementation reality right now.

It’s an interesting idea, I can see how that might be useful. 

/Kristian