[Proj] +towgs84 approximation error

[Noel Zinn (cc)]

All,

This has been a very interesting thread for me and thanks for all the 
insightful geodetic contributions.  The computer science implementation 
details (git, et al) are beyond my experience.  But one important detail has 
been missed so far.  That is that derivation of a 7-parameter transformation 
for any European country is badly ill-defined.  Even for a country the size 
of Germany, the adjustment correlations between the rotations and the 
translations are extremely high.  That's because, for a "small" area, a 
positional difference (error) at a survey monument can be explained by 
EITHER a combination of rotations and scale OR just a combination of 
translations.  Those effects are only separated out over a very large area 
(continental or larger).  Unavoidable surface errors result in statistically 
meaningless and egregious translations compared with, say, a simple 
3-parameter transformation.  So, while we're gilding 7-parameter 
transformations here with rotation matrices fully populated with sines and 
cosines, we ought to consider how those transformations were derived.  There 
may be acceptance behind them, but little science from a survey-adjustment 
perspective.  Better to keep it simple in Europe.

Noel

Noel Zinn, Principal, Hydrometronics LLC
+1-832-539-1472 (office), +1-281-221-0051 (cell)
noel.zinn at hydrometronics.com (email)
http://www.hydrometronics.com (website)

-----Original Message----- 
From: Martin Desruisseaux
Sent: Thursday, March 23, 2017 3:21 PM
To: proj at lists.maptools.org
Subject: Re: [Proj] +towgs84 approximation error

Hello Jochem and all

I think you already know that, but just for information for people
reading this thread that may be interested. Jochem shows below an
example of two steps using WGS84 as a hub (A to WGS84 to B) that are
mathematically combined for producing a single step going directly from
A to B. What we call "late-binding" goes a little step further in that
it is not just a mathematical combination. The 7-parameters for a datum
shift from A to WGS84 are derived by minimizing the errors in a set of
stations (like a "curve fitting"), and the 7-parameters for a datum
shift from WGS84 to B are derived by another "curve fitting". The
mathematical combination of the two is not exactly the same than what we
get if we do a "curve fitting" directly from A to B. Since those
parameter values can not be inferred mathematically from the "+towgs84"
parameters, they have to be stored in a separated table in the EPSG
database.

I'm not completely sure that I understood correctly the context, but it
may be that Jochem's intend could be understood not as improving a datum
shift operation, but rather as defining a Derived CRS in ISO 19111 sense
[1]. It doesn't make a difference for Proj.4 in its current state, but
if Proj.4 is someday upgraded to a "late-binding" implementation this
little nuance would need to be kept in mind.

    Regards,

        Martin


[1] http://portal.opengeospatial.org/files/?artifact_id=39049 section
B.1.2.2 at page 63.


Le 23/03/2017 à 13:49, Jochem a écrit :

> The "late-binding" will not solve these problems, since also for 
> parameters
> between system A and B the rotation angles are too large for the 
> approximate
> formulas:
>
> In my case:
>
> Frame A -> WGS84
> -294.1985,231.0171,-285.2462,-11.34441,40.54620,-9.73364,15.7901
>
> WGS84 -> Frame B
> 270.4047,-127.0720,286.7425,+11.13087,-1.67806,-24.24971,0.4536
>
> Frame A - > Frame B
> -23.764,103.995,1.506,-0.21346,38.86867,-33.98116,16.2437
> NB: I did not simple add the parameters, but used strict formulas to 
> combine
> them.
>
> Therefore, I'm still convinced that the formulas of +towgs84 should be
> corrected.

_______________________________________________
Proj mailing list
Proj at lists.maptools.org
http://lists.maptools.org/mailman/listinfo/proj