[PROJ] "Trustworthiness" of vertical transformations

[Chris Crook]

Am I right in understanding that where proj (6) determines two or more possible transformation paths between CRSs it uses the accuracy to decide which is preferable?

If so steps the algorithm for combining accuracies could be significant for transformations involving multiple whether or not they are strictly comparable

Also geodetic agencies defining parameters will need to be careful that accuracies are configured to ensure the desired preference is achieved.  In the past it is likely that not much attention would have been given to this as it isn't necessarily very meaningful (certainly not as a single value) and until now possibly didn't make much difference to anything...

Cheers
Chris


> -----Original Message-----
> From: PROJ [mailto:proj-bounces at lists.osgeo.org] On Behalf Of Kristian
> Evers
> Sent: Wednesday, 27 November 2019 9:21 p.m.
> To: Even Rouault; proj at lists.osgeo.org
> Subject: Re: [PROJ] "Trustworthiness" of vertical transformations
>
> > The algorithm currently is rather
> > simple: just add the (in)accuracies of each step. I do have some vague
> > remembering from univ that this was not always the "right" thing to do
> > from a math point of view. I guess sometimes perhaps taking the max()
> > would be more appropriate. But given that we can potentially mix
> > uncomparable things, probably not that a big deal...
>
> Yeah, this can definitely be improved but it's a simple and effective solution
> that doesn't promise too much which is always better that saying that
> accuracy is better than it really is. I think this could be a fun topic to have a
> workshop on at the OSGeo code sprint in the spring.
>
> /Kristian
>
> -----Original Message-----
> From: Even Rouault <even.rouault at spatialys.com>
> Sent: 27. november 2019 01:06
> To: proj at lists.osgeo.org
> Cc: Nyall Dawson <nyall.dawson at gmail.com>; Kristian Evers
> <kreve at sdfe.dk>
> Subject: Re: [PROJ] "Trustworthiness" of vertical transformations
>
> On mercredi 27 novembre 2019 09:34:33 CET Nyall Dawson wrote:
> > On Tue, 26 Nov 2019 at 20:52, Kristian Evers <kreve at sdfe.dk> wrote:
> > > You can get the transformation accuracy using the API function
> > > proj_coordoperation_get_accuracy(). I think it would be cool if
> > > information about transformation accuracy where readily available in
> > > software like QGIS (nudge, nudge :-))
>
> I should mention that the information about accuracy should be taken with a
> grain of salt for several reasons:
> - the EPSG guidance note 7-1 [1] underlines that the exact definition of
> accuracy varies according to geodetic agencies
> - in a number of situations, PROJ will have to synthetize the resulting
> accuracy when chaining several steps. The algorithm currently is rather
> simple: just add the (in)accuracies of each step. I do have some vague
> remembering from univ that this was not always the "right" thing to do from
> a math point of view. I guess sometimes perhaps taking the max() would be
> more appropriate. But given that we can potentially mix uncomparable
> things, probably not that a big deal...
>
> > That's where I'm coming from now... I'm just wondering if and how we
> > should expose vertical transformation functionality. Do you have any
> > ideas on what functionality you would expect an end-user application
> > to expose for vertical transformations?
>
> Depends on the use cases. If you want to aggregate point cloud datasets that
> are referenced against several vertical CRS into a single dataset, you will
> probably want to convert them into a single Geographic CRS (ITRF2014,
> WGS84
> G1762) or a single CompoundCRS appropriate for the area of study so that
> they can be stashed together.
>
> Even
>
> [1] http://www.epsg.org/Portals/0/373-07-1.pdf , §6.5.4.1 Coordinate
> Operation accuracy
>
> --
> Spatialys - Geospatial professional services http://www.spatialys.com
> _______________________________________________
> PROJ mailing list
> PROJ at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/proj

________________________________

This message contains information, which may be in confidence and may be subject to legal privilege. If you are not the intended recipient, you must not peruse, use, disseminate, distribute or copy this message. If you have received this message in error, please notify us immediately (Phone 0800 665 463 or info at linz.govt.nz) and destroy the original message. LINZ accepts no responsibility for changes to this email, or for any attachments, after its transmission from LINZ. Thank You.