Animation Cases

Interruptible Transitions in Map State

These types of animations change the map state (e.g. center and resolution) and re-render all layers with each change in state. During these transition, user generated events (e.g. mousedown, touchstart, mousewheel) must cancel the animation. During these transition, other events (e.g. tile loading) that might trigger a rendering must not cancel the animation.

Examples

• Fly to: a method is called that results in the map smoothly panning and zooming to a new center and resolution.

• Kinetic pan: a method is called at the end of a drag-pan that results in the map gradually coming to a stop.

Playback

These types of animation display changes in data over time. Typically the user would be presented with some playback controls and would start and stop the animation manually. An animation playback of this sort does not interfere with the animated changes in map state described above and vice versa.

Examples

• Hurricane track: a vector layer is populated with hurricane positions from a gx:Track in KML. The map is accompanied by a playback control that lets the user sit back and watch the position change over time. Things like kinetic panning work during this playback - though the application may also decide to center the map at the hurricane position at specific key frames.

Display Effects

Some aspects of map rendering may be animated for a simple display effect (without an accompanying gradual change in map state). These types of animations should be completely independent from the above animations.

Examples

• Tile fade: when tiles are drawn they may gradually fade in.

• Animated zoom: when the user requests a change in resolution (e.g. 2x), the renderer may choose to animate the transition (though the map state changes immediately).

Things that are not Animations

There may be dynamic aspects of a map application that are not necessarily animation.

Examples

• "Real-time" data updates: say we have a vector layer that streams data changes via a WebSocket. The layer may request a re-rendering of the map with every data change. The renderers should handle this in an efficient way (i.e. the layer shouldn't have to know how to animate, it should just demand a re-rendering with every data change).