Copyright © 2010 Open Geospatial Consortium, Inc.
115
Figure 41: Revision of the Event Model package that defines core event types
The XML Schema implementation of the revised Event Model is provided in
Annex E
–
XML Schema for Event Model Revision
.
12.2.5 OM
OM is a GML application schema. It is currently available as an OGC standard in version 1.0 which is based on GML 3.1.1, a version based on GML 3.2.1 1.0.1 is
available as discussion paper and can be used in order to be compatible to other information models using GML 3.2.1. As for many other SWE standards version 2.0 is
currently under development.
OM is used to encode an observation or measurement as a feature. Besides the measured result also the observed feature e.g. a lake, the observed property e.g. the pH
value, the observation procedure e.g. a pH sensor description and the sampling time must be available. Because the result time in an OM measurement provides the time
when the observation actually produced the result, that is
when the result generation happened
, an OM observation is an event according to the definition of the Event Architecture the result time being the event’s event time.
116
Copyright © 2010 Open Geospatial Consortium, Inc.
Also spatial filtering via the observed feature feature of interest or on metadata properties observed property and procedure can be performed. Filtering on the
measured value itself may become problematic as the encoding for the measurement result is not defined in the OM specification.
12.2.6 SWE Common
SWE Common defines common data types for the use in SWE. These types are derived from the GML Abstract Type but do not reuse the types defined in GML like
gml:Quantity. The SWE Common data types are newly defined instead having some important differences making them incompatible to the GML types. One instance of this
difference is the optionality of the actual value. This allows using the SWE Common types as a template for values instead of having to include a specific value itself. More
information on the differences between SWE Common and GML can be found in the OWS-6 SWE Information Model Harmonization ER 09-031r1.
Similar to OM, SWE Common relies on GML 3.1.1 in its 1.0 version. A Discussion Paper for a GML 3.2.1 support is available, too and the 2.0 version will support GML
3.2.1 directly. Another important difference between version 2.0 and the previous versions is that SWE Common will be extracted from the SensorML specification and
released as an independent standard.
SWE Common alone is not well suited as an event encoding as it just defines data types. However it can be embedded in other encoding like OM and serve as encoding for the
measurement result. It is also possible to define a complex SWE Common data type including mandatory temporal properties and use this as event encoding.
12.2.7 AIXM
The Aeronautical Information Exchange Model is an XML based encoding for aeronautical features like runways, navaids and many more. It is developed by the
Federal Aviation Administration FAA and Eurocontrol. Since version 5.0 it is based on GML 3.2.1 and represents the aeronautical features as extensions of GML features. With
respect to the continuous changes to feature properties e.g. runway closure, … the AIXM features are extended with a temporal validity model based on time slices. Besides
the basic information it is possible to encode temporal and permanent changes to the data and keep track of these changes.
The support of event encoding is one important aspect in AIXM as one function of AIXM shall be the enablement of digital NOTAMs Notice To AirMen. A NOTAM is a
notification for pilots to inform them about changed conditions for instance at an airport. AIXM includes specific elements for the encoding of the NOTAMs which also can serve
as encoding for aeronautical events. More information on the use of AIXM and eventing aspects can be found in the OWS-6 and -7 Aviation Engineering Reports 09-
050r1 and 10-079.
Copyright © 2010 Open Geospatial Consortium, Inc.
117
12.2.8 WXXM
The Weather Information Exchange Model is also based on XML. It is used to encode weather observations current observations and forecasts. These are represented as an
extension of OM observations. In version 1.1 it uses OM version 1.0.1 to be compatible to the AIXM which relies on GML 3.2.1. It is usable in the same way as
OM for the encoding of events but adds additional properties that help to filter on properties that are of special interest in the aviation domain.
12.2.9 Common Alert Protocol
12.2.9.1 Introduction
The Common Alert Protocol CAP is a message format for encoding alert or notification messages.
The main idea of CAP is to normalize the expression of alert messages arising from various sources. Such normalization then allows these messages to be aggregated and
compared to aid situational awareness and pattern detection.
To that end, the CAP standard describes a document object model that defines the structure of an alert or notification messages and a protocol that describes how CAP
messages should be constructed, used and related to each other. The CAP standard also describes a concrete implementation of its document model using XML and expressed in
XML-Schema.
A limited amount of testing was done by CubeWerx Inc during the OWS-7 test bed with CAP v1.1 and the Geosynchronization service. That work involved generating CAP
messages as notification messages sent to subscribers. So rather than sending subscribers ATOM entries, the format used in the GSS specification, CAP messages were generated
and sent instead. Unfortunately, it was not possible in the time frame of the project to also test filtering of CAP message using the Filter encoding specification as was done with
ATOM entries so any discussion about using FES with CAP is purely notional.
12.2.9.2 Document object model
Figure 42 illustrates the UML definition of a CAP message.
