Print This Post

GeoWorld: Integrating Geography and Real-Time Sensor Data

GeoWorld Issue Date: May – 2005, Posted On: 5/1/2005

Integrating Geography and Real-Time Sensor Data-GML DEVELOPMENT

RON LAKE, president, Galdos Systems Inc.; e-mail: rlakeatgaldosincdotcom

Although many people now are familiar with the use of Geography Markup Language (GML) for vector geographic features, a smaller number are aware of the application of GML to real-time sensor data and the consequent ability to integrate geography and real-time sensor data within a single coherent framework.In a previous "Tech Time" column (see "Application Schemas Help Build the Geo-Web," GeoWorld, February 2005, page 54), I discussed the role of GML Application Schemas and how they build on core GML schema objects such as geometry, topology, time and features. In this column, I introduce further GML core objects of interest to real-time sensor data and the sensor web, clarifying the role of GML through a real-world example.

Observation Elements

In GML, an observation is a "model of the act of observing" and is a specialized type of GML feature. Observation features model the act of observing by providing:   

    * A "location" (where the observation took place)   

    * A "valid time" (when the observation took place)   

    * The "target" or "subject" of the observation   

    * A "resultOf" (what resulted from the observation)   

    * A "using" property that points to or describes what was used to carry out the observation

Observations can be used to represent a variety of things, including technical environmental measurements, GPS measurements, land surveys, and human-aided visual observations (e.g., "the road is paved").

Because observations are features in GML, they can be expected to appear in Web Feature Service (WFS) transactions and requests, although not all WFSs may support them. Nonetheless, the ability to request or record "gml:Observations" actually adds little that's new in terms of requirements for WFS support, and most WFSs should be able to support them fairly readily.

Enabling a Sensor Web

A WFS that supports GML observations within WFS insert or update transactions becomes a kind of "general-purpose data logger." In this way, a network of WFSs can readily enable a sensor web of interconnected WFSs, some being used in "push" mode and others in "pull" mode.

Note that to generate GML insert observation transactions from a native sensor output, some sort of gateway to the WFS must be written. This is usually quite straightforward.

Also, GML isn't used to describe the characteristics of a sensor, such as its accuracy, precision, dynamic range, model and manufacturer. Such information is best captured in a sensor description record referenced by the "gml:using" property of the "gml:Observation," with this description possibly written in OGC SensorML and residing in an OGC Web Registry Service.

GML observations provide a framework model. The actual data resulting from the observing is carried by the "gml:resultOf" property. This can be a GML "valueObject" (e.g., a sensor data packet), a geometry (e.g., point, line string, etc.) or a GML coverage (e.g., a remotely sensed image).

In the case of "valueObjects," GML provides a set of primitives for expressing various types of quantities, including physical quantities with units (scalar and composite), categories and counts. These provide the basic grammar for encoding almost any kind of sensor data packet.

Applying to a Problem

Now that the basic concepts have been introduced, let's see how they're applied in a real-world sensor application such as real-time traffic management. The following example is based on a project supported by the Ministry of Transport in Canada and carried out in cooperation with the University of Toronto's ITS R&D Center.

The architecture of the ITS Traffic Monitoring System illustrates the system's components.

The system consists of several Web Feature Servers, a Feature Portrayal Service (WMS), a set of sensors (mostly loop detectors) and a sensor gateway generating GML observation insert transactions.

 

The real-time fusion of data is displayed in a color-coded traffic congestion map.

The first WFS acts as an observation data logger, writing received observations "pushed" by the sensor gateway. This WFS can trigger a policy that "fires" on certain observation commits and generates an update transaction against a second WFS storing a real-time traffic model using GML dynamic features.

The traffic model maintains dynamic information about the occupancy (density) and mean speed of the vehicles within each traffic link in the highway system. A third WFS is used to store the more static road geography. Fewer WFSs could have been used, but the point of the architecture was to demonstrate real-time "plug and play" on a wide-area network. Each of the WFSs could reside in different organizations at different physical locations.

The Feature Portrayal Service dynamically requests data from the WFSs and applies styling rules to generate an SVG traffic-congestion map viewable in a standard Web browser. The map shows the link segments in the dynamic traffic model colored according to traffic volume, occupancy and mean speed. Data in the system are fed from approximately 300 sensors and updated every 150 seconds.

GML is being used for more than vector geography and images, and it's rapidly being deployed for real-time sensor data. With GML and WFS, the real-time fusion of data on a "plug and play" basis now is a practical reality. 

Read the article on their website: GeoWorld.