[PROJ] Using latest realization of a datum ensemble ?

[Greg Troxel]

Even Rouault <even.rouault at spatialys.com> writes:

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

Thanks.  I don't see HTML so I missed this.

> ============
> 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.

I can see how this would get hard.

> 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 don't see this as really fixing the problem, which is that people are
getting what I consider to be bad transforms, when those people might
not understand.

> 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

I think your idea of having entries in the database to lead to the
transforms to most-recent-realization is a very promising appraoch, and
probably the right approach.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20201014/c3e07cd7/attachment.sig>