More Google Earth – Time Animation



Fig 1 – Google Earth Time Animation tool visible in the upper part of the view frame –

I was out of town for a trip back to Washington DC the last couple of weeks, but now that I’m back I wanted to play with some more KML features in Google Earth 4.3. One of the more interesting elements offered by KML inside Google Earth is the use of timestamps for animated sequences.
KML offers a couple of time elements:

<TimeStamp>

        <TimeStamp>
	<when>2002-09-27T21:44:41.087Z</when>
        </TimeStamp>

<TimeSpan>

        <TimeSpan>
	<begin>2002-09-27T21:44:41.087Z</begin>
                <end>2002-09-27T21:45:41.087Z</end>
        </TimeSpan>

By attaching a time stamp element to kml rendered elements it is possible to make use of the built in Google Earth time animation tool. I have a table of GMTI events for a few simulated missions that is ideal for this type of viewing. The time stamp deltas are in the millisecond range and work best as timestamp elements.

KML time formats are defined as dateTime (YYYY-MM-DDThh:mm:ssZ) which translates to a Java formatter:

SimpleDateFormat timeout = new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss.SSS'Z'");

In KML the T char delimits date from time, while the Z indicates UTC. In my case using simulated mission data I am more interested in delta time effects than actual time.

By adding the appropriately formatted <TimeStamp> to each <Placemark> from the GMTI data set I can create a KML data stream with the time animation tool enabled.

<Placemark id="gmti_target.80916">
        <TimeStamp>
          <when>2002-09-27T21:00:06Z</when>
        </TimeStamp>
         <description><![CDATA[<table border='1'>
           <tr>
             <th colspan='8' scope='col'>gmti_target</th>
           </tr>
           <tr>
             <td>targetid</td>
             <td>missionid</td>
             <td>dwellid</td>
             <td>name</td>
             <td>time</td>
             <td>the_geom</td>
             <td>classification</td>
             <td>dwellindex</td>
             <td>trackindex</td>
             <td>geom</td>
           </tr>
           <tr>
             <td>78840</td>
             <td>16</td>
             <td>135417</td>
             <td>gh1_v4bt.cgmti</td>
             <td>75606708</td>
             <td></td>
             <td>Unknown, Simulated Target</td>
             <td>1476</td>
             <td>0</td>
             <td>SRID=4269;POINT(-111.89313294366 35.1604509260505 2180)</td>
           </tr>
           </table>
           ]]></description>
         <LookAt>
            <longitude>-111.89313294366002</longitude>
            <latitude>35.160450926050544</latitude>
            <range>700</range>
            <tilt>10.0</tilt>
            <heading>10.0</heading>
         </LookAt>
         <styleUrl>#Stylegmti_target.634</styleUrl>
         <Point>
            <coordinates-111.89313294366002,35.160450926050544</coordinates>
         </Point>
      </Placemark>

For this experiment I utilized a mission with a relatively small number of gmti targets in the 6000 point range. The time to load is still a bit slow even with only 6000 points to load. In order to boost performance I switched from a simple kml stream to a zipped kmz stream for the servlet response.·····

Response.setContentType("application/vnd.google-earth.kmz");
ZipOutputStream out = new ZipOutputStream(response.getOutputStream());

This helps with bandspeed latency by reducing the data stream from 5Mb to 0.25Mb, however, the biggest latency on my system is the Google Earth load rendering rather than the download. Im using a medium 5Mb DSL connection here on an Intel Core2 Quad CPU Q6600 2.39Ghz. The download of the kmz is about 5sec but the Google Earth ingest and rendering, complete with blanked viewport, is around 50sec.

Once rendered the point icons are available for time sequence animation. Google Earth furnishes a built in tool that automates this process. The time tool includes option settings for adjusting speed, time range view, a setting to keep or discard points from the beginning, as well as repeat, stop, or reverse selection for end of time range event. The animation is helpful for visual analysis of target association. The tool provides step and slider views as well as animation.


Fig 2 – Google Earth time animation

The built in tools provided by Google Earth are quite helpful. Virtual Earth or WPF tools can be used for time sequence as well but require writing the necessary client javascript or C# to step through the set of elements in sequence. Having the tool already available makes simple view animation much easier to create. The potential for customization and interaction is a bit limited, but many applications are well served by the prebuilt viewing tools provided by default in GE. The large terrain and imagery infrastructure behind Google Earth is a real asset to viewing. Additional high resolution imagery can be added as GroundOverlay elements for enhancing specific gmti view areas.

For classification and analysis the simple view capability is somewhat limited. What is needed is a mode of selection to group and classify point data to create track associations. This requires more interactive events than afforded by GE. WPF is more difficult to work with, but the ability to add a variety of selection tools and change classification interactively may make the effort worthwhile from a GMTI analyst’s point of view. Any background imagery, terrain, or mapping layers need to be added to the WPF UI so there would be quite a bit more effort involved.


Fig 3 – Google Earth time animationviewed from above

GMTI is only one of a number of time sequence vehicle tracking data resources. The increasing use of GPS and fleet tracking software makes these types of data sets fairly common. The use of timestamp animation is a nice addition to the viewing capability of historical tracks, of course live tracks generally retain a history tail as well, so a live tracking databases could also make good use of this timestamp element. NetworkLinkControl refresh events can keep the track synchronized with the live data feeds.

The lack of interactive UI capability in Google Earth limits its use for operator classification and analysis. However, GE is just one viewing possibility. A UI system using a FOSS GIS stack such as PostGIS, Java, and Geoserver can be accessed in a number of ways through the browser. For example one browser tool could view the data set through a WPF UI, which allows operator reclassification and filtering using a variety of selection tools, while simultaneously a GE viewer with a NetworkLinkControl refreshed from the serverside backing datastore can be open from the same client. One aspect of the power of Browser based UIs is the ability to access multiple heterogeneous views simultaneously.


Fig 4 – Multiple browser views of gmti data source – WPF xbap UI and GE Time animation

Comments are closed.