[PROJ] Using latest realization of a datum ensemble ?

[Even Rouault]

(Resending the last part of my message from Monday whose text-only output got 
truncated for some reason. The HTML version was OK)

============
REAL SUBJECT
============
 
What is tricky in the suggestion to 'promote' to the latest realization of a  
datum ensemble is that you might have both low accuracy transformations that > 
exist like shown above for NAD83 -> WGS84 and high accuracy for NAD83(2011) -> 
WGS84 (G1762) (here I assume that NAD83 would be an enssemble, which it is not 
formally currently). Depending on the situation, one or the other might be 
relevant.
 
So there could be 2 options:
 
1) in addition to the lower resolution results, also consider the ones using 
the latest realization of the datum. and do that systematically
 
- Pro: more possibilities returned
- Con: more possibilities returned! (users might already be overwhelmed by 
current output which in some cases can offer of the order of 100 
possibilities), and greater pipeline computation time (there are already 
optimizations/heuristics to avoid doing the advanced pipeline searchs, like 
using an intermediate CRS/datum, when direct ones are returned.)
- Pro or con: the default pipeline (that is the one used by cs2cs or 
proj_create_crs_to_crs() when the user has no say on the pipeline to use) 
would probably be in a lot of situation the high resolution one, which might 
be appropriate or not. The high accuracy pipelines also often need a 
coordinate epoch, so when it is not specified in the input coordinates 
provided to PROJ, the transformation will be done at the central epoch of the 
Helmert transformation.
 
In some circumstances, I imagine there might not be a transformation 
registered from/to the latest realization of a datum ensemble, but to an 
earlier realization.
 
2) or the same, but do that only on user request (projinfo switch, new 
function in C/C++ API).
 
- End users have to turn that on to benefit from the new capability
- Downstream software (like QGIS) has to make use of that new API, and 
possibly reflect that in its user interface.
 
I am a bit unconfortable about having PROJ being "too smart" by default with 
option 1. There are already known circumstances where it is too smart in a bad 
sense, such as in one of the above examples with WGS 84 to ITRF2014, using a 
NAD27 intermediate, or in https://github.com/OSGeo/PROJ/issues/2348

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com