[Proj] +towgs84 approximation error
Noel Zinn (cc)
ndzinn at comcast.net
Thu Mar 23 16:27:51 EST 2017
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
More information about the Proj
mailing list