Boost logo

Geometry :

Subject: [ggl] question regarding rotate_transformer strategy
From: Barend Gehrels (barend)
Date: 2011-11-09 12:24:19


Hi Jeff, Luke,

On 7-11-2011 1:17, Simonson, Lucanus J wrote:
> -----Original Message-----
> From: ggl-bounces_at_[hidden] [mailto:ggl-bounces_at_[hidden]] On Behalf Of Jeff Trull
> Sent: Sunday, November 06, 2011 2:39 PM
>> I was tracking down a rotation issue and I noticed that the 2D
>> rotation matrix (around Z) is defined as:
>>
>> cos(angle), sin(angle), 0,
>> -sin(angle), cos(angle), 0,
>> 0, 0, 1)
>>
>> But in other sources I have seen it defined as:
>>
>> cos(angle), -sin(angle), 0,
>> sin(angle), cos(angle), 0,
>> 0, 0, 1)
> Your math seems spot on and using the right hand rule to define the direction of positive rotation would be most intuitive from a math perspective. I would guess that the OGD standard defines the direction of positive rotation to be clockwise. The documentation should probably provide what the assumed direction of positive rotation is. The current doxygen description leaves this detail out: "Rotate rotates a geometry of specified angle about a fixed point (e.g. origin)."
>

Right, it should indeed be documented. We're talking about 2D here
(thought the matrix is sized 3 for convenience). To be honest I don't
know anymore which source I've used here at that time. I normally often
look in Wikipedia and Mathworld. But they both give the convention you
expected, for 2D.

It might be that GIS users are more common to clockwise rotations but
Math users will probably expect counter clockwise rotation. For 3D it is
even more ambiguous, by the way, and Wiki and Mathworld give different
matrices. See also
http://en.wikipedia.org/wiki/Rotation_matrix#Ambiguities

Anyway, the rotation matrix might be used as is, so we should not change
it without measures. OGC SF (according to which most algorithms of
Boost.Geometry are modelled) does not give specifications here.

If we change it I would suggest to add an extra, required,
template-parameter to avoid run-time errors and force a compile-time
error. Any opinions?

Regards, Barend


Geometry list run by mateusz at loskot.net