TimeMapper: Visualizing Moving Object Data using WMS Time and SVG SMIL Interactive Animations

The current version of the TimeMapper prototype is now specialized for moving-objects visualization. Figure 1 shows the prototype presenting three icebergs in Antarctica. The system functions in the following way: it retrieves spatio-temporal data from the database and generates interactive animated maps showing the movement of the objects.

Figure 1. The TimeMapper prototype showing the movement of three icebergs in Antarctica.

OGC’s Web Map Server Implementation Specification [OGCWMS] introduces the way to store temporal data. It adopts the ISO 8601 standard, which recommends storing time stamps in one single string. Up to 14 digits specify century, year, month, day, hour, minute, seconds, and optionally a decimal point followed by zero or more digits for fractional seconds, with non-numeric characters to separate each piece. All times should be expressed in Coordinated Universal Time (UTC) as indicated by the suffix Z (for "zulu"):

ccyy-mm-ddThh:mm:ss.sssZ 
2009-10-04T14:50:58Z 
= October 4th 2009 at 2:50 pm and 58 seconds

We designed our database to comply with this specification. Figure 2 shows example tuples of our icebergs database table. The function of the column timeinseconds will be explained later.

Figure 2. Icebergs database table.

In geographic theories on change, three main types of change are usually recognized: existential change (e.g. appearance/disappearance), change of spatial properties (e.g. location, shape) and change in attribute (e.g. land-cover change). The traditional partition of geographic data into polygons, lines and points are the objects on which these changes occur. In the present test-case, we mainly focused on changes in position and existential change for point objects.

To show the movement of our objects, two main types of animations were used, stepwise animations and linearly interpolated animations. Such animations are easy to generate using SVG SMIL. The following code shows an example of an animation for the movement of a circle element, depicting iceberg A22B:

<circle id="IB_A22B" cx="0" cy="600" r="25" >
  <animate id="XanimIB_A22B_0" attributeName="cx" repeatCount="none" fill="freeze" begin="0s"
   from="0" to="200" dur="2s" calcmode="discrete" />
  <animate id="YanimIB_A22B_0" attributeName="cy" repeatCount="none" fill="freeze" begin="0s" 
   from="600" to="550" dur="2s" calcmode="discrete" />
</circle>

The first animate element will lead to movement along the x-axis and the second on the y-axis. The begin attribute tells the animation when to start and the dur attribute sets its duration and therefore its apparent speed. The calcMode attribute is set to “discrete”, which means we will see a stepwise animation. In brief, the effect of these two animations is that the object is going to jump from 0 to 200 on the x-axis and from 600 to 550 on the y-axis after a period of 2 seconds. For a linearly interpolated animation, the calcMode attribute would have been set to “linear”.

In our moving-object prototype, the interpolated animation type is offered to the users for them to be able to appreciate the movement of the objects taken individually or in small groups. In other words, we are interested in the dynamics of the trajectories. To help visualize this, we add animated tracks. SVG SMIL doesn’t have a built-in way of animating growing line segments. However, members of the SVG community have developed a workaround by animating the stroke-dasharray attribute of lines.

Animations to render existential changes were also developed for our test-case. The visual effect desired is to have the objects appear/disappear at the display-time corresponding to the real-world time that they “appear/disappear” in the dataset. To achieve this, we use the set animation on the attribute visibility in the following way:

<set id="ShowAnimIB_A22B" attributeName="visibility" begin="0.94" from="hidden" to="visible"/>

In the two previous subsections, we first saw the way that the data is stored in the database and then, how time is used in SMIL animations. We now need to find an algorithm to go from real-world time in the database to display time in the animations. Three steps effectuate the necessary conversion. These three steps are illustrated in Figure 3.

Figure 3. Steps in converting from real-world time to display time.

If the animations were viewed at this stage, they would last as long as the real-world events. For geological data for instance, this could last for hundreds of millions of years! The third step is therefore to multiply all time-stamps by a ratio that we call the temporal scale. Just as in traditional cartographic spaial scale (the ratio between map distances and real-world distances), in animated cartography the temporal scale of an animation is the ratio between display-time and real-world time [HarFab]. Most often, in geographic studies, time will be shrunk for the viewer to visualize in a short time the events which happened during a comparatively long period.

Most animated mapping theorists agree that the user should be aided in his visualization task by two elements: temporal legends and ways to interact with the temporal dimension of the maps.

Temporal legends

Kraak and others [KraakEdsall] state that temporal legends are useful to “understand a temporal animation” because they help him to “apply an appropriate temporal schema” thus allowing him “to interpret meaning inherent in the sequence and pacing of the animation.” Three main types of temporal legends exist: digital clocks, time bars and cyclic temporal legends. All three of these legend types were developed. Regarding the cyclic temporal legend, we chose to develop three different versions with the intention of testing their cognitive effectiveness.

Coding the three types of temporal legends was done using different methods. The time-bar and two versions of the cyclic temporal legend were developed using simple SMIL animations (linear in the first case and cyclic in the second). To develop the cyclic legend that we call “small pie” (see figure 4), a total of five animation elements were necessary.

Figure 4. The small pie cyclic temporal legend.

The digital clock was built in the following manner: a JavaScript function is run which retrieves the animated value (animVal) of the time-bar temporal legend. This value is processed in a way which includes graphical parameters as well as the temporal scale parameter. The value resulting from this process is the real-world time (in seconds) corresponding to the instant being displayed. This value is transformed into a JavaScript Date object and time elements, such as years, months, etc., are further concatenated in a string which is injected in the text element of the clock. The function is run a few times per second which makes the clock run.

The system’s architecture is presented in figure 5. A spatial database back-end is used for storing both the configuration of the Web Map Services as well as the actual spatial and attribute data the maps are derived from. A template SVG file defines the setup of the GUI: the necessary scripts for the basic WMS GUI as well as the animation GUI are loaded, and the map layers are defined as a set of nested SVG elements. The content of the map layers is not limited to animated SVG. External WMS layers can also be included, for instance in the example in Figure 1, “The TimeMapper prototype showing the movement of three icebergs in Antarctica.”, the land and ice-shelf are (raster) layers from the Antarctic Cryosphere Access Portal OGC services (http://nsidc.org/agdc/acap). Additonally, one or more non-animated SVG layers can be retrieved from the TimeMapper system.

The application tier is a set of Java Servlets that can be deployed in any J2EE compatible servlet container (eg. Apache Tomcat). The servlets do recurring tasks like extracting OGC features and attribute data from the database, translating these into fragments of SVG and ECMAscript, collecting and structuring these fragments into valid output and delivering this output to the clients. The interfaces to the servlets complies to OGC's Web Map Service standard: GetCapabilities, returning an XML description of the WMS’s information content and acceptable request parameters and GetMap, returning the map itself.

Figure 5. The system architecture

We will first describe how the system functions from a user perspective. For this, the reader may refer to Figure 1, “The TimeMapper prototype showing the movement of three icebergs in Antarctica.” for a screenshot of the system. The first choice a user needs to make regards the type of animations he desires to visualize. He can choose stepwise animations, which are convenient to study distributions, or linear interpolated animations, which, especially when adding interpolated tracks, are effective to visualize movement dynamics (trajectories, speeds and comparing the behaviors of a few icebergs).

The second choice the user needs to make is to set the speed of the animations. The speed is set with the speed control slider which actually sets the temporal scale of the animated map. The speed shall be set for the objects to move at convenient speeds to observe the behavior under study. Other choices the user can make are displaying optional temporal legends (cyclic and digital) and choosing the looping visualization mode or not.

These choices will determine what the user will see in the map display as well as the behavior of the animations. The display shows the temporal legends and the animated objects. When the animation is played, the dynamic items start running and the user can interact with the moment of the animations by clicking and dragging the time slider.

In addition, the spatial GUI of the original RIMapper system has been integrated, and can be accessed by clicking the small "?" icon. Here, one can switch layer visibility, retrieve data attributes. Also the user can pan or zoom the map, at which point a new WMS request is sent to the server(s) and new animations are compiled for the spatial bounding box now to be visualized.

For testing purposes, a series of three test-cases have been generated with an increasing number of icebergs displayed. The first, or “small” test-case has three icebergs. The second, or “middle” test-case, has nineteen icebergs (all the icebergs present in the Weddell Sea region during the five years visualized). The third, or “big” test-case, shows 99 icebergs (all icebergs in the Antarctic Ocean during the five years visualized). For the moment, testing has only been done using the Opera web browser.

While testing the prototype with the small test-case, we assert that all the features function as planned. The speed setting system as well as the time-slider work particularly well. Thanks to a third degree polynomial equation, the speed-slider can be set with satisfactory modularity. Without this equation, moving the slider a given distance could double the speed in low speeds (temporal scale from 1/1,000 to 1/2,000) or have no effect at all in high speeds (1/9,500,000 to 1/9,501,000). With this small test-case, the time-slider is very responsive. The user can interact with the temporal moment of the animation with hardly any response delay.

However, with larger test-cases, there are important responsiveness limitations, that mostly affect the speed-setting mechanism and the time-slider. Setting the speed of the animations with the middle test-case takes a few seconds. Interacting with the time slider with this test-case still works but is too slow to constitute a usable exploratory tool. This is due to the fact that the rendering engine of the browser needs to calculate the positions of many objects. At the present stage of development, each segment travelled by an object leads to two animations (one x and one y) and it may be that the rendering goes through all these animations even if they are not relevant to the moment of the animation being shown. We plan to do some testing using a different coding method for the animation, using keyTimes/values. With this method, the whole trajectory travelled by one object would lead to only two animations and this may improve the responsiveness of the animations to the time slider. This change might also improve the responsiveness of the speed-setting mechanism drastically.

Finally, the big test-case takes a very long time to load. Setting the speed of the animations and interacting with time with the time slider hardly works at all. As seen above, re-coding the animations with the keyTimes/values method might improve the responsiveness of the speed-setting mechanism. However, we predict that it wouldn’t have enough effect on the time slider’s responsiveness. For that, other performance enhancements might be necessary.

Our experimentations with our test-cases showed that different iceberg behaviors can be visualized depending on two visualization parameters: the number of icebergs and the type of animation used.

While viewing a small number of icebergs with interpolated animations and interpolated animated tracks, the user can effectively study the relative movement dynamics of the icebergs. In other words, he can observe and compare the directions and speeds of the few icebergs viewed. In addition, we found that the time slider helped the user grasp these movement characteristics. To the contrary, the behaviors observed here are much harder to observe using the stepwise animations.

When the user visualizes more icebergs (middle or big test-case), simple stepwise animations are effectively used to show moving clusters of icebergs. Seasonal variations in the number of bergs calving from the ice-shelf can also be detected and the cyclic temporal legends are helpful in this regard. More testing would need to be done and ways to emphasize the calvings might be helpful.

The iceberg use case also gave us reasons to begin testing other animation types. For instance, to emphasize the moment of calvings, we started experimenting with the use of blinking animations and changes of color. We also started experimenting with animations to show the changes in size of the icebergs. In effect, our dataset includes attributes about the lengths of the sides and areas of icebergs. These three types of animation would be of use in a more complete animated mapping system and the testing we did shows that they respond well to our interactive controls.

A more advanced type of animation is the polygon-morphing. We developed a test-case by re-using an animation developed by the carto.net team, which shows the morphing of a polygon into another. The test-case also includes supplementary animations affecting the opacity of fills. Screen captures of this animation can be seen in figure 6. This test-case is particularly interesting because morph animations could be argued to be the most complex type. They could be useful in the showing of floods or tectonic-plate deformations. This animation was successfully integrated into the TimeMapper environment and the different interactive functionalities work very well. The time slider in particular works without any lag! This is a promising result for developing a system offering all types of animations that could be useful in animated cartography.

Figure 6. Interactive control of polygon morphing test-case