Version: 1.0

Date: 2011-11-17

Editor: Arne Bröring, 52°North

 

 

An Observation Model for the ArcGIS Server SOS Extension

This document presents a generic data model for serving spatio-temporal observations, in particular in form of near real time sensor data, with an extension for ArcGIS Server, named in the following ArcGIS Server Sensor Observation Service (SOS) Extension. This data model is aligned with the OGC specification “Observations & Measurements” (O&M). In future, the alignment with the O&M model will enable the ArcGIS Server SOS Extension to serve data conformant to the OGC Sensor Observation Service specification and the O&M encoding. For now, the ArcGIS Server SOS Extension provides the same functionality as the OGC SOS, but its interface follows the Geoservices REST API of the ArcGIS Server.

In the next section, an overview about OGC’s SOS and O&M specifications is given, laying the foundation for the development of a generic database schema for observations as described in Section 2. An implementation of this conceptual database schema as an ArcGIS Geodatabase is described in Section 3.

1. Background: OGC’s SOS and O&M

The interface of OGC’s Sensor Observation Service (SOS) supports access to heterogeneous sensor types, stationary as well as mobile sensors, which gather their data in-situ or remotely. The heterogeneous communication protocols and data formats of the associated sensors are hidden by the standardized interface (see Figure 1). To associate the SOS with a sensor, a description of this sensor is uploaded to the SOS via the RegisterSensor operation which can be accessed subsequently by calling the DescribeSensor operation. The Insert-Observation operation is responsible for the integration of newly measured data. Those uploaded observations can be requested by calling the GetObservation operation using a combination of temporal, spatial, and thematic filters.

Figure 1 - Overview of the interface of OGC’s SOS.

For the encoding of the data hosted by an SOS, basically three specifications are utilized. First, the Sensor Model Language (SensorML) is used to describe the sensor's metadata. SensorML specifies a model and encoding for processes - while process acts as super type for sensor systems and sensor related processes such as post processing procedures. Physical as well as logical sensors (e.g., simulations) can be modeled. A sensor can be described in detail, including its identification, classification, inputs, outputs, parameters, and characteristics such as a spatial or temporal description.

The two other specifications used by the SOS to encode data are the Geography Markup Language (GML) and its application profile O&M. Thereby, the O&M specification is most important, since it is used to model and encode observed sensor data.

O&M defines an observation as an act of observing a certain phenomenon. The basic observation model is shown in Figure 2. An observation has a relationship to a procedure representing the process which has performed the observation, e.g. a sensor, but may also be a human observer or a computation. The observed property points to a description of the phenomenon which is observed (e.g. 'water temperature' or 'salinity'). This phenomenon has to be a property of the feature of interest. The feature of interest is a real world entity that is the target of an observation. The observation provides a value for this observed property at a certain time, the phenomenon time. The observation value is contained in the result element. In the basic observation model, the result can be of any type, for example a numeric measurement (e.g., 23°C) or a nominal value (e.g., “warm”). Subtypes of the basic observation further define this result type. The result value can be associated with a result quality. This allows for example to define that the measurement of a thermometer has an error interval of 0.03°C.

The feature of interest is encoded in GML and can either be represented by a domain feature or by a sampling feature. A domain feature (e.g. ‘Gulf of Mexico’) is designed for a particular application domain. A sampling feature (e.g. 'Station', 'Trajectory', or 'Scene') is domain independent and purely an artifact of the sampling strategy to produce observations for a domain feature.

The sampling feature links to the domain feature which represents the spatially distributed real world entity. For example, when measuring the water temperature of the Gulf of Mexico at different depths, the concrete locations of the measurements are represented through three dimensional sampling points. Those sampling points reference the feature representation of the Norwegian Sea which carries the water temperature property. This shows that the observed property of an observation can either be a direct or transitive member property of the feature of interest. That means, if the feature of interest is a sampling feature, the observed property has to be either a member of the sampling feature or of the domain feature.

OaM_Overview

Figure 2 - Excerpt of the basic O&M observation model.

On service level, at the SOS, the observations are grouped by so-called ObservationOfferings. One such offering groups the observations produced by one particular procedure. The offering makes all metadata of this group of observations available. Such metadata are for example the begin- and end-time as well as the overall bounding box of all associated observations.

2. A Generic Database Schema for Observations

Based on the above described O&M model for representing observations, this section develops a database schema. This database schema is generic in a sense that it is not restricted to a particular use case of observation data. With the flexible O&M model as its foundation, this database schema can be applied to various domains, ranging from hydrology over oceanography to air quality monitoring.

Figure 3 depicts the designed database schema. To implement this schema, each box is mapped to a database table with the according columns.

Figure 3 - Generic database schema for observations.

The observation type is at the center of the schema. It carries a time stamp for storing the phenomenon time, a UCUM code to identify the unit of measure, and can have a text value OR a numeric value as its result. (Note that this OR relationship cannot be reflected in the schema but has be applied in the implementation.) Further, the observation has foreign keys to the associated observed property, the feature of interest, and the procedure. Also, the observation is grouped to an observation offering, and has therefore an according foreign key.

To state information about the quality of the result of an observation, the quality type is created. Besides a foreign key to the according observation, it carries the name, unit, type, and value of the quality.

Which data type has to be used to interpret the result is stored in the property type. This type also allows storing a description for the observed property. This can be a link to a more detailed description of the property / phenomenon observed by the sensor. The property type has n:m relationships to the offering, which hosts observations with this particular property, as well as to the procedure, which has this particular property as its output.

The feature of interest type stores the name, description, type, and geometry of the feature. It has n:m relationships with the offering to which it belongs and the procedure which it observes.

The procedure type represents the sensor and contains various metadata to describe a sensor. Besides a service-wide unique id, name, contact information to the responsible party, this type contains the current position of the sensor. Having such a spatial attribute for the feature of interest (geometry attribute) as well as for the procedure (position attribute) allows use cases of mobile sensors moving within the extent of a feature (e.g., a PM10 sensor on a bus driving around within the city of San Diego, or a CTD sensor attached to a marine drifter within the Gulf of Mexico). However, in cases of stationary sensors (e.g., thermometer and barometer attached to a weather station), the position of the procedure and of the feature are equivalent.

The procedure history type is associated with the procedure type to store the state of certain sensor attributes at certain time instants. For example, a moving sensor can reflect here its varying position over the course of time.

3. Implementation of the Database Schema in ArcGIS

The screenshot below (Figure 4) shows a the implementation of the database schema and a basic test instantiation in ArcMap. Not all schema types have been realized as tables, yet. This will be continued in version 2 of the Geodatabase implementation.

In the Catalog window on the right of the screenshot, the tables of the observation model can be seen. The feature (of interest) and procedure types have been realized as feature classes, since they have a spatial attribute. The types offering, observation, and property have been realized as tables. To reflect the associations between the observation type and the types offering, feature (of interest), procedure, and property, according relationship classes have been introduced.

In the Table window at the bottom of the screenshot, the table of the observation type is visible. The different attributes have been implemented as columns of the table.

In the middle of the screenshot, the Identify window is shown. After selecting a feature point with the Identify tool, this window displays the attribute values of a feature and its associated instances, e.g., the observations measured at that particular feature of interest.

 

Figure 4 - The Geodatabase for observations in ArcMap