Improve ETRFxxx to ETRFyyy, and WGS 84 (xxx) to WGS 84 (yyy)

[rouault]

(on top of #4363 for convenience)

• createOperations(): more relevant ETRFxxxx to ETRFyyyy results
• Database: add concatenated operations for all WGS 84 (xxx) to WGS 84 (yyy) realizations

[jjimenezshaw]

I don't know if you want to consider differently ETRF2000-PL

https://spatialreference.org/explorer.html?searchText=ETRF&ignoreWorld=false&allowDeprecated=false&authorities=EPSG&activeTypes=GEOGRAPHIC_2D_CRS

[rouault]

I don't know if you want to consider differently ETRF2000-PL

As far as I can see this pull request doesn't affect anything related to it. This pull request only affects transformations between "regular" / non-national-specific ETRFxxxx that imply going through ITRF.

ETRF2000-PL is only connected to generic ETRS89 and WGS 84 through a null transformation.
So you get things like (with or without this PR):

$ PROJ_DATA=data bin/projinfo -s "ETRF2000-PL" -t "ETRF2014" -o PROJ
Candidate operations found: 1
-------------------------------------
Operation No. 1:

unknown id, ETRF2000-PL to ETRS89 (1) + ETRS89 to ETRF2014, 0.1 m, Poland - onshore and offshore.

PROJ string:
+proj=noop

which is probably suboptimal if one could reasonably consider ETRF2000-PL to be equivalent to ETRF2000 (but can we... ?)

[jjimenezshaw]

I said that just because there is a check "starts_with("ETRF")"

[rouault]

I said that just because there is a check "starts_with("ETRF")"

yes, thanks for raising this. The code should be safe even with ETRF2000-PL (if one day there would be a connection between ETRF2000-PL and ITRFxxxx, then the added logic would probably make sense). I've added a test to check that ETRF2000-PL to ETRF2014 doesn't misbehave badly.