[PROJ] Using latest realization of a datum ensemble ?

[Even Rouault]

On mercredi 14 octobre 2020 14:45:44 CEST Greg Troxel wrote:
> Thanks for your detailed comments and for taking the time to think about
> my issue..  I am going to quote and reply to only the big-picture issue
> in this message to keep it general interest.
> 

I'm not sure if you got my message from monday in its entirety. I've just 
resent it and it looks fine now in
https://lists.osgeo.org/pipermail/proj/2020-October/009866.html

> I find the justification for "ensemble has high intrinsic errors so null
> transform is good" to be hard to undertand.  I certainly can understand
> "null transform error is comparable to existing possible error", but to
> me it's picking zero as a magic number because it is a very round number
> rather than picking the value that minimizes errors overall.

In my email I suggested a potential software solution, but code in PROJ to 
find and infer transformations is already horribly super complicated. Adding 
more heuristics to it will not help.
So certainly the most simple solution for PROJ (and anyone relying on EPSG), 
which would require no software update but just a database update, would be to 
get the records in EPSG modified in the direction you indicate.
One thing that could potenitally be done is to have let's say the NAD83(2011) 
-> WGS84(G1762) copied to be the one to apply to the ensemble version NAD83 -> 
WGS 84, but with a lower indicative accuracy (but better than the null 
transformation one, so that's the improved transformation is proposed by 
default!). But I'm not sure that fits into IOGP vision. You could try 
suggesting that to them, and see how they react. That's just at the reach of 
one email.
(For your own personal needs, you could certainly add new records in proj.db 
for what you want, but I'm aware that's not a really long-term maintainable 
solution)

> Finally, while I realize we probably can't strictly have this property,
> I think it would be good if the relative output positions of data in CRS
> A and CRS B are consistent, whether the prroject CRS is A, B, C, or D.
> Right now we essentially "round to zero" differently, and this seems
> avoidable.

Generally, you shouldn't expect any kind of transitivity. A => C will 
generally lead to a different result than doing A => B => C (this was exactly 
the Australian issue with A = GDA94, B = WGS84, C = GDA2020 where A => B and B 
=> C are null transformation, where A = > C is not)

Even


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