[PROJ] Using latest realization of a datum ensemble ?

[Greg Troxel]

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

> 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

Yes, I responded to the other half separately so more people could ignore that.

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

I see where you are coming from.

> 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!).

That makes a lot of sense.  Essentially do what I'm suggesing, but add
some transform db records with manual thought.  We don't need that many
to really fix this for almost everything.

> 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)

I will attempt to write to them.   Probably I should hand-add records
so I can tell them that my idea makes sense...

>> 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)

I realize one can't expect it to really hold.  I was trying to suggest
that choices that make it hold better can be seen as preferred choices,
all else being equal.
-------------- 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/fc442b2f/attachment.sig>