[Proj] +towgs84 approximation error

[Martin Desruisseaux]

Hello Jochem

I do not know the details about how data are selected for computing the
7-parameters, but I would presume that the set of stations in "A to
WGS84 to B" is not necessarily the same than in "A to B". For example an
operation from A to B may be designed for a smaller geographic area than
an operation involving WGS84.

Before to talk about derived CRS, one note about ISO 19111 terminology.
They define two kinds of coordinate operations:

  * A *conversion* is a coordinate operation defined only by mathematics
    and arbitrary parameters. Theoretically, the precision of coordinate
    conversion is infinite (ignoring limitations of floating point
    arithmetic). All map projections are conversions. Change of axis
    order, unit of measurement, etc. are also conversions.
  * A *transformation* is a coordinate operation derived from
    measurements. Regardless the computer accuracy, coordinate
    transformations have a limited accuracy because of stochastic
    errors. All datum shifts are transformations.

So an affine operation for example can be either an conversion or a
transformation, depending for which purpose it is used:

  * An affine operation used for changing the unit of measurement, or
    for changing the false easting or false northing parameters of a map
    projection, is a /conversion/. There is no error associated to that
    operation.
  * An affine operation used for applying a datum shift on geocentric
    coordinates is a /transformation/. There is an error associated to
    that operation no matter the accuracy of the mathematics behind it.

A derived CRS in ISO 19111 is a Coordinate Reference System defined by
another CRS (named the "base CRS") that we use as a starting point, then
a *conversion* that we apply /by definition/ on the coordinates in the
base CRS in order to get the coordinates in the derived CRS. Some key
points:

  * The base CRS and derived CRS are related by a coordinate conversion,
    not a transformation.
  * The above coordinate conversion is part of the derived CRS
    definition. In WKT 2 format, the parameters are specified inside the
    CRS definition.
  * The above coordinate operation is the only possible coordinate
    operation from the base CRS to the derived CRS.

By contrast, a change of datum between two CRS has the following properties:

  * Datum changes are transformation, not conversion.
  * Datum change parameters are not part of CRS definition. In WKT 2
    format, the operation is specified in a separated WKT element
    independent of the CRS definition (except for BOUNDCRS, which is a
    compromise done for early-binding implementations).
  * Many different coordinate operations can exist for the same pair of
    CRS. In USA, there is about 80 datum shift operations from NAD27 to
    WGS84.

To make a parallel with Proj.4, the current Proj.4 implementation is
designed as if all CRS were derived CRS since the +towgs84 parameter is
part of CRS definition. This is not the reality (many CRS were designed
before WGS84). In late-binding implementations of map projection
libraries, whether a coordinate operation is used for the definition of
a derived CRS or not make a difference in:

  * Where the parameter is defined (in the CRS or in a separated construct).
  * The cardinality of the coordinate operation(s) associated to that
    CRS (1:1 or 0:∞).
  * Whether the coordinate operation choice may depend on the geographic
    area of the coordinates that we want to transform.
  * Whether the operation may have stochastic errors.

That said, I mentioned the derived CRS because I saw a statement saying
that the CRS would be /by definition/ an other CRS with the coordinate
operation defined by the 7 parameters. But I still a little bit
surprised by a scenario where a derived CRS would be defined by
Bursa-Wolf parameters.

    Martin


Le 23/03/2017 à 22:53, Jochem a écrit :

> Hi Martin,
>
> Actually, I think that it is mathematically perfectly possible to derive
> exactly the same parameters from A to B by common points, as by combining
> the parameters form A to WGS84 and the parameters form B to WGS84 (if you
> used the same common points to estimate all the transformations).
>
> An important condition is that you take the full covariance matrices of the
> least-squares solutions into account. This is like the fact that you can
> compute the average body length of a school by taking the average of the
> average length of each class, as long as you weigh it with the number of
> students in each class. I think it works for 7 parameter transformations
> too. I could try if this actually works if you are interested.
>
> Anyway, it is definitely possible to compute the parameters from A to B from
> the parameters from A to WGS84 and from B to WGS84 in a way that A to B
> gives the same result as A to WGS84 to B. For small angles this is simple
> subtracting the parameters. For larger angles it is a bit more complicated
> but still commonly known linear algebra. I derived the formulas once to make
> a "calculator" for stacking and inverting transformations.
>
> If you have different sets of common points between A and B, A and WGS84 and
> B and WGS84, then you would indeed get 3 sets of inconsistent parameters.
> However, more precise and consistent parameters could then be obtained by
> least-squares adjustment of the 3 sets of parameters (ideally using the full
> covariance matrices again). That you would have to store 3 sets of
> parameters to relate 3 reference frames is utter nonsense. This is like
> claiming that the height difference between the floor and the ceiling is
> different from the sum of the height differences from the floor to the table
> and from the table to the ceiling. 
>
> The part of ISO 19111 I don't understand (I'm good in least-squares theory,
> but I bad in reading formal ISO norm texts. Could you explain that in normal
> English?).
>
> Now, there are two possibilities. Or what I just wrote is very interesting
> for you, or I completely misunderstood that you meant. The third possibility
> that I am wrong, I don't consider in this case ;-)
>
> Regards, Jochem

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20170324/9195245e/attachment.html>