Heading interpolation for a Model using AnimatedUpdate crossing the North boundry rotates the long route

[GoogleCodeExporter]

Which products are affected?
Google Earth

What steps will reproduce the problem?
1. Open attached HeadingAnimExample.kmz
2. Run the tour

What is the expected output or behavior? What do you see instead?
I would expect the heading to rotate in the direction which the angle 
between is less than 180 degrees.  Instead, when your rotation crosses the 
north boundary between 0 and 360, the rotation goes the long route.

What application versions (if any) are you using?
Google Earth
5.1.3509.4636 (beta)

Which operating systems (and/or relevant web browsers) are affected?
Windows XP

Please provide any additional information (code snippets/links) below.
<gx:AnimatedUpdate>
  <gx:duration>1</gx:duration>
  <Update>
    <Change>
      <Orientation targetId="modelOrientation">
        <heading>359</heading>
      </Orientation>
    </Change>
  </Update>
</gx:AnimatedUpdate>
...
<gx:AnimatedUpdate>
  <gx:duration>1</gx:duration>
  <Update>
    <Change>
      <Orientation targetId="modelOrientation">
        <heading>1</heading>
      </Orientation>
    </Change>
  </Update>
</gx:AnimatedUpdate>

Original issue reported on code.google.com by tohl...@gmail.com on 9 Oct 2009 at 7:44

Attachments:

• HeadingAnimExample.kmz

[GoogleCodeExporter]

The same is true for FlyTo.

Original comment by matthew.s.whalley@gmail.com on 6 Nov 2009 at 5:46

[GoogleCodeExporter]

The example attached to the original post is a simple one and perhaps does not 
convey the frustration felt by users trying to create more complex animations.

I am working on the animation of a model ship to follow the track of H.M.Bark 
Endeavour during Cook's first voyage round the world (see Australia.kml 
attached or http://captainjamescook.wordpress.com for examples). 

I encounter this issue frequently as the ship needs to be 'steered' through 
heading changes where, as the original poster pointed out, it would make sense 
to rotate through the smaller of the two possible rotations rather than blindly 
rotating between the numerical values of the current heading and the target 
heading. For me, this is most irritating when the ship's heading needs to pass 
through north.

The attachment Rotation.kmz gives examples of what I mean. The first two tours 
in the attachment show expected behaviour while the third (South to North) 
further illustrates the issue. My workaround for this problem is to set a 
duration of 1ms for the rotation; this looks better than watching a bizarre 
rotation 'the wrong way' but still doesn't look very attractive.

My solution to this problem would be to extend the <Orientation> element in a 
way that would preserve backwards compatibility - after all there are loads of 
animated updates out there and some people might like the current behaviour.

Solution: include in the schema an optional <rotate> element as a child of 
<Orientation>. This new element would define the direction of rotation, with +1 
meaning clockwise and -1 meaning anticlockwise. The default behaviour would be 
as now, but when the <rotate> element is present in an <Update> its value would 
be used.

Please could you raise the priority of this defect.

Regards,
netkingcol

Original comment by netking...@gmail.com on 15 Jan 2012 at 11:50

Attachments:

• Rotation.kmz
• Australia.kml

[GoogleCodeExporter]

This is not only applicable to heading but also to pitch and roll.  For 
example, if you pitch to 179 degrees up then pitch over to -179 degrees, the 
model will turn 358 degrees the wrong way.

Original comment by chrissco...@gmail.com on 16 Nov 2012 at 3:14