Animation and Dynamic Updates with KML

Although KML has quickly become the main format used for map annotation, it has a number of advanced features which only have limited support outside of Google Earth. Some of these absences are logical – for example, few mapping systems support 3d views and buildings. With the current pace of development it is likely that many of the other advanced features will be added to future versions of these products. One of the advanced features that will almost certainly see much wider support is that of animation. This article looks at KML’s animation and dynamic update features.

There are a lot of mapping formats in circulation, but few support the concept of time. The one big exception that I have used is the UK Ordnance Survey’s Mastermap format which is based on GML. Every single feature has a time stamp and version number, allowing feature changes to be documented over time. KML is only designed for annotation, so it is considerably more lighweight and less advanced than Mastermap. Therefore credit should be given to the designers of KML for adding animation, time stamps, and automated map updates to the KML standard. KML’s utility is greatly increased with the addition of time and animation to KML.

KML features can be animated using time stamps, time spans, and network (server) updates.

Time Stamps

Individual feature elements (placemarks) can have a time stamp. This specifies what a placemark looks like and where it is located at that specific time. By listing a series of such placemarks with successive time stamps, it is possible to animate a feature. This method is often used with simple features such as icons. The following example animates an icon along a GPS trail. The GPS trail was collected during a field guide’s tour across a lava flow at Arenal in Costa Rica during the EcoMap Costa Rica 2008 Field Season.

The full KML file can be downloaded here. Here is the beginning of the KML including the first three placemarks:

<?xml version="1.0" encoding="UTF-8"?> 
<kml xmlns="http://www.opengis.net/kml/2.2"> 
 <Document> 
  <name>Demonstration of KML TimeStamp Animation: Arenal Walk, EcoMapCostaRica.com 2008 Field Season</name>

<Style id="track_style"> 
  <IconStyle><Icon><href>http://www.ecomapcostarica.com/map/icon/large_smiley.png</href></Icon></IconStyle> 
</Style> 

<Style id="check-hide-children">
  <ListStyle>
    <listItemType>checkHideChildren</listItemType>
  </ListStyle>
</Style>
<styleUrl>#check-hide-children</styleUrl>

<Placemark>
 <TimeStamp>
   <when>2008-05-26T21:51:17Z</when> 
 </TimeStamp>
 <styleUrl>#track_style</styleUrl> 
    <Point>
      <coordinates>-84.735102277,10.460481773</coordinates> 
    </Point>
</Placemark>
<Placemark>
 <TimeStamp>
   <when>2008-05-26T21:51:20Z</when> 
 </TimeStamp>
 <styleUrl>#track_style</styleUrl> 
    <Point>
      <coordinates>-84.735101592,10.460480402</coordinates> 
    </Point>
</Placemark>
<Placemark>
 <TimeStamp>
   <when>2008-05-26T21:51:25Z</when> 
 </TimeStamp>
 <styleUrl>#track_style</styleUrl> 
    <Point>
      <coordinates>-84.735089001,10.460476080</coordinates> 
    </Point>
</Placemark>

The beginning of the file is simple KML that defines a document, and an icon style (#track_style) for the animated icon. Things become a little unusual with the check-hide-children style and styleUrl tag. These hide the document’s children from Google Earth’s list view. We want the document to be listed, but not the hundred or so individual positions!

This is followed by Placemark definitions for each and every position. The Placemark code was actually created using a custom template in the Trimble GPS Pathfinder software. This saved hand typing, or the writing of a custom script in something like Python or even AWK to format the coordinates and times correctly.

Each Placemark definition is a conventional Placemark with a Point coordinate and style. The only unusual tag is the TimeStamp tag which marks the actual time stamp. This has one child element: ‘when‘ which encloses the date and time using the XML standard dateTime format. This formats a date and time as yyyy-mm-ddThh:mm:sszzzzzzyyyy, mm, dd, hh, mm, ss are all number fields specifying year, month, day, hours (24hr), minutes, and seconds respectively. The ‘-‘, ‘:’, and ‘T‘ characters are all separators. The final field, zzzzzz, specifies the time zone. Here we use ‘Z’ for UTC time. This is also known as ‘Greenwich Mean Time’, or ‘Zulu’ time. It is also commonly used by GPS devices such as this one. See the XML standard for the other available time zones.

A time stamp only specifies a definition for a specific time. Technically, the feature is not visible before or after that point in time. This would result in limited visibility and a feature that flickers on and off as it is animated. Google Earth’s user interface solves this by allowing the user to show all features marked within a period of time. Here is an example with the period stretched out to show all of the placemarks:

All of the placemarks for all time

 

The period can be reduced to a short period and this can then be played as an animation. Here is a still from such an animation:

Placemarks for only a short period

 

Note that as this is a real world GPS track, the locations are not evenly distributed. The Trimble was set to record locations at periodic intervals of time. This results in “clumping” when we were walking slowly or pausing to listen to the guide. In contrast, there is a stretch at the south east end which has only a few widely separated points. This was due to dense forest with a limited view of the sky, and hence few GPS location fixes. Google Earth animates the points in terms of their time stamps, so this stretch of limited data does not suddenly speed up.

 

Time Spans

Time spans work in a similar manner as time stamps, except they cover a period of time instead of a single point in time. As with the TimeStamp tag, the TimeSpan tag is specified as a child of the Placemark tag. The time span’s start and end times are marked with start and end tags. For example:

<Placemark>
 <TimeSpan>
   <begin>2008-05-26T21:51:17Z</begin>
   <end>2008-05-26T21:51:20Z</end>
 </TimeSpan>
 <styleUrl>#track_style</styleUrl> 
    <Point>
      <coordinates>-84.735102277,10.460481773</coordinates> 
    </Point>
</Placemark>

 

Network Link Updates

Network Links (using the NetworkLink tag) allow an external KML file to be included in the current KML model. These links can be updated in a number of ways. For example, the link’s refreshMode tag can be set to reload the external KML file at periodic intervals. An example application would be a weather map which displayed static information in the parent KML (eg. weather station locations). Weather warnings and predicted storm tracks could be displayed in a child KML file that is set to refresh every 10 minutes or so. For example:

<Document>
 <Name>Sample</Name>
 <NetworkLink>
  <Link>
   <href>http://localhost/weatherupdate.kml</href>
   <refreshMode>onInterval</refreshMode>
   <refreshInterval>600</refreshInterval>
  </Link>
 </NetworkLink>
</Document>

This example loads the weatherupdate.kml file and updates it every 10 minutes. With each update, the server delivers a new KML file with the latest weather information. This mechanism could also be used to update images from a webcam, or to show the latest snapshot of data stored in a geospatial database.

A more sophisticated update mechanism uses the NetworkLinkControl tag. This tag can be used to update KML elements by their individual id identifier. Elements can be created, changed, or deleted. This is particularly useful if a large KML file has already been loaded and only a few elements need to be changed. The client update could be specified with a NetworkLink element’s refreshMode as before.  However, this time, the server supplies a KML file using the NetworkLinkControl tag to specify only the changes that are required. Typically the server would create this KML file using a server-side script. Here is an example of such a NetworkLinkControl:

<NetworkLinkControl>
 <Update>
  <targetHref>http://localhost/original.kml</targetHref>
  <Delete>
    <Placemark targetId="oldMarker"></Placemark>
  </Delete>
  <Change>
    <Placemark targetId="targetMarker">
      <name>Modified Marker</name>
      <visibility>1</visibility>
      <description>This marker has been modified</description>
      <Point>
        <coordinates>130.00, 5.3</coordinates>
      </Point>
    </Placemark>
  </Change>
 </Update>
</NetworkLinkControl>

This code snippet updates elements which were originally loaded from the original.kml file. It removes a placemarker called ‘oldMarker’ and modifies an existing marker called ‘targetMarker’. New elements can also be created using the Create child element.

Note that the original and updated KML files have to be served from the same domain. This is a simple security measure that helps to maintain element integrity.

 

Summary

As can be seen, there a number of different ways to add dynamic updates and animation to KML files. Animation can be specified in unchanging KML files, or updates can be supplied over a network connection. Use of the NetworkLinkControl can greatly reduce bandwidth usage when large files require updates.

Although Google Earth is the only KML client which currently supports all these features, a combination of the utility of these features and rapid development of competing products means we shoould expect to see wider support over the next year or so.

Leave a Reply