[Proj] Meaning of 7-parameter transformation rotations

Martin Vermeer martin.vermeer at hut.fi
Wed Nov 30 04:23:00 EST 2005

On Tue, 2005-11-29 at 20:08 +0100, Oscar van Vlijmen wrote:
> > From: Martin Vermeer <martin.vermeer-hut.fi>
> > I find in the document gen_parms.html the remark
> > "The seven parameter case uses delta_x, delta_y, delta_z, Rx - rotation
> > X, Ry -  rotation  Y, Rz - rotation Z, M_BF - Scaling. The three
> > translation parameters are in meters as in the three parameter case. The
> > rotational parameters are not in physical units. They are something like the
> > sine of the rotational angle times the ellipoid axis length, but I don't know
> > the exact details of how to derive these from a physical description of
> > the rotation."
> In the 7-parameter Helmert transformation the rotation parameters are indeed
> in arcseconds according to geodetic practice.
> In principle the transformation should be done with mathematical accuracy
> and in that case in the rotation matrix combinations of sines and cosines of
> angles are found.
> Since the translations are relatively small, the rotation angles are small,
> the scaling factor is small and a (spherical) Helmert transformation on an
> ellipsoidal earth introduces small errors anyway, the sines/cosines in the
> rotation matrix are approximated. sin(angle) is nearly equal to angle
> (expressed in rad), cos(angle) is nearly 1 and sin(angle)*sin(angle) is
> about 0.
> See EPSG coordinate operation method code 9606 and ISO 19111.
> This approximation has several interesting practical consequences. The order
> (around geocentric X-Y-Z axes) of the rotations is no longer important, the
> inverse transformation can be done by negating all parameters, switch from
> coordinate frame to position vector rotation can be done by negating the
> angles only.

Yes, I know. Just wanted to point out that the above quoted text is
uninformative. Yes, the exact matrix contains sines and cosines, but of
the angles Rx, Ry, Rz that are in seconds of arc (and thus, in any
computation, must be converted to radians first).

The text following "not in physical units" just expresses the author's
lack of information, and contains a wrong guess. I propose to replace it
by correct information.

- Martin Vermeer

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.maptools.org/pipermail/proj/attachments/20051130/2d17efa4/attachment.bin

More information about the Proj mailing list