Keyhole Markup Language

Introduction

The use of the Keyhole Markup Language was a key component of MARVIN and the research undertaken and presented here. As previously outlined, KML was evaluated in this research as the data format for information sent between the server-side processes

manipulating spatio-temporal data (in the DBMS) and the client-side Virtual Globe browser visualising spatio-temporal datastreams.

KML is based on the Extensible Markup Language (XML) for encoding geographic data. Briefly, XML files are human readable text files consisting of characters divided into markup and content elements. Markup elements are words which are enclosed by greater than and less than symbols in the code. A start-tag and end-tag pair such as <name>John

</name> is an example of markup elements. John is a content element in this case. Hence, name has been specified to be equal to John. An attribute can be associated with a tag such

as <name type=christrian>John </name>.

KML’s long list of elements allowing the encoding of geographic data are KML-specific XML markup elements. For instance, <heading>, <latitude> and <longitude> elements within a KML file specify the data required by a <Camera> element, where the <Camera> element describes the viewpoint and from which to create a 3D view.

Importantly and necessarily for this research, KML supports both negative and positive elevations (depths and heights) as well as the time component of spatial objects. KML also allows symbology information to be included which can be used by software packages accessing a KML dataset.

Regardless of the software package used to open a KML document, identical symbology should ideally be used. For example, the symbology used to create the visualisations of data contained in a correctly formatted KML document should ideally appear the same, when opened with desktop GIS software (ArcMap or MapInfo) and a Virtual Globe browser (Google Earth or Worldwind). For example, major roads would appear as thick orange lines and lakes would appear as blue filled polygons.

This is in contrast to common geographic data exchange formats such as E00 (ESRI) and DXF (Autocad) which provide no or limited support for the inclusion of symbology data. TAB (MapInfo - Pitney Bowes) format files are able to store symbology data specifying line thickness or fill colour for example, but they lack the ability to associate timestamps to individual geographic objects.

A full description of the KML 2.2 syntax is not included here for brevity. Interested readers are directed to the Open Geospatial Consortium webpage (http://web.opengeospatial.org) for access to standards documents.

Descriptions of specific KML elements used

MARVIN used a variety of KML elements to describe the spatio-temporal datasets extracted from the database. Listed below are brief descriptions of the important KML elements used as part of this research, and the functionality they provided.

<Model> element

The <Model> element provides a mechanism to describe the position of a 3D model of an object, in both space and (optionally) time. The 3D position, along with the scale, heading, roll and tilt of the model can be specified. The path to a COLLADA (https://collada.org) format model needs to be specified, allowing the Virtual Globe browser to access the model as required. Figure 3.6 shows some of the models of real world objects utilised by MARVIN.

A COLLADA model is an XML encoded text file format defining the vertices, facets, textures and colours of a 3D model of an object. The file format makes the exchange of 3D models between packages which generate 3D models, such as Google Sketch Up (http://sketchup.google.com) and Autodesk 3D Studio Max

(http://usa.autodesk.com), possible via an open-source standard (Wernecke 2009). The <Model> element was used extensively in MARVIN for positioning models of the vessel and deployed equipments. The ability to change the scale of the model as displayed in the Virtual Globe browser, allowed the same model to be shown at multiple scales, making small objects in a large ocean easier to locate in Google Earth.

Figure 3.6 Examples of simple COLLADA models of a vessel (left) and water sampling equipment (right) usable in MARVIN.

<ScreenOverlay> element

The <ScreenOverlay> element allows the overlay of an image file on the Google Earth screen. The path to the image file to be overlaid and its position can be specified. The position can be expressed in pixels or as a fraction of the Google Earth screen width, accommodating varying desktop sizes for clients.

The <ScreenOverlay> element was used in MARVIN to embed images showing time- series graphs of underway datasets, small vessel-centred planimetric charts, and images of real-time and historic textual data, such as UTC time and vessel location. <TimeSpan> element

KML’s ability to accommodate the time component of spatial data is provided by the <TimeSpan> element. This simple element allows the specification of the valid start and end times for an object to exist in a location. Time is specified using the ISO8601 convention, and can be specified using reduced formats.

(http://www.iso.org/iso/date_and_time_format#what-iso-8601-covers)

For example, an object can be specified to exist in 3D space between two times, such as 2009-01-01T00:00:00+00 and 2009-01-02T00:00:00+00. This forces Google Earth to only show the object when the time selector is set to a time during the 1st of January 2009. The ability within KML to exactly specify time periods for which the 3D location of an object is valid is a key reason for its suitability for use within spatio- temporal data exploration techniques.

The <TimeSpan> element was used extensively in MARVIN to accommodate the varying positions versus time of the vessel and deployed instruments. Hence, a

timestamp was associated with each position in the KML datastreams. This allowed the replay of historic data, which in turn allowed the positioning of models of the vessel and deployed instruments according to a user determined epoch.