16.3. KML file format

16.3.1. Introduction to KML file format
16.3.2. LineString KML files
16.3.3. MultiGeometry KML files

16.3.1. Introduction to KML file format


Keyhole Markup Language (KML) is an XML-based language schema for expressing geographic annotation and visualization on existing or future Internet-based, two-dimensional maps and three-dimensional Earth browsers. KML was developed for use with Google Earth, which was originally named Keyhole Earth Viewer. It was created by Keyhole, Inc, which was acquired by Google in 2004. The name "Keyhole" is an homage to the KH reconnaissance satellites, the original eye-in-the-sky military reconnaissance system first launched in 1976. KML is an international standard of the Open Geospatial Consortium. Google Earth was the first program able to view and graphically edit KML files, and other projects such as Marble have also started to develop KML support

 --WikiPedia, 2010

Whilst it has military roots, the KML dialect of XML has received wide adoption for the recording and distribution of positional information. KML extends the GML standard. KML and GML provide a number of ways of recording positional data. This section will record the KML dialects that Debrief understands.

16.3.2. LineString KML files

Handheld GPS systems (including mobile phones) tend to store positional data in a Placemark that contains a single, lengthy LineString element containing a series of long, lat, altitude elements - devoid of time stamps. Debrief makes the following assumptions regarding this format:

  1. If altitude data is missing, its comma separator will still be present

  2. The filename will be of the form w20090802164801.kml, where the digits represent year, month, day, hour, minute, second

  3. The data items will have been recorded at one second intervals

  4. The filename (without suffix) is used as the track identifier

16.3.3. MultiGeometry KML files

More capable recording systems tend to store positional data in a more refined, time-stamped format - using series of Placemark entries - each containing a MultiGeometry record. Additionally, these more complex files are able to represent data for a number of different vehicles. Debrief makes the following assumptions regarding this file format:

  1. Only Placemark elements that contain a MultiGeometry element are treated as compliant and processed

  2. The Placemark name element is used to determine the track id: any digits/letters appearing before a "-" hyphen are treated as a track id, this multiple positions are attributed to their relevant track

  3. Tracks imported into Debrief from this file format are named as the first component of the filename (before the "."), followed by the unique id declared in the Placemark entries.

  4. The contents of the when element are treated as the time-stamp of the position record (time-zone ignored, always treated as GMT)

  5. The long/lat/altitude coordinates are taken from the first coordinates element in the Placemark

  6. Course and speed data is taken from the description element, based on a presumption that the element contains a string formatted like: <br>Course: 345.2<br>Speed: 9.6 knots<br>Date: