Copyright © 2010 Open Geospatial Consortium, Inc.
99 products support such a thing. The EML was therefore developed based upon concepts
that were identified to be common to multiple event processing languages. EML users should consider the language as a testing ground to improve the filtering and
processing functionality of standards based geospatial services and applications. The functionality provided is especially interesting for use cases where critical information
needs to be derived from the data produced by various sources and clients be informed about new information as soon as possible. The Sensor Web domain is an example where
Event Processing has already successfully been tested see the
OGC Sensor Event Service
Discussion Paper, OGC 08-133. Other domains can benefit from the technology as well, for example the transportation domain.
9.3 Spatial Filtering of Events
9.3.1 Spatial Filtering via Bounding Box
Filtering published events based upon spatial filter criteria is a common use case. Especially in the geospatial domain events usually have a spatial context, in addition to
their temporal context the event time.
Events that are encoded as GML features share a common property: the
boundedBy
property of type GM_Envelope see figure D.45 in OGC 07-036. The GML 3.2.1 schema currently allows the inclusion of a spatial or spatio-temporal envelope bounding
box of n dimensions as property value. In OWS-6 and OWS-7, the boundedBy property was used to perform spatial filtering of events. Several issues were identified with this
approach. They are described in the following.
First of all, filtering events using the boundedBy property is in most cases inexact. It depends upon the accuracy required as well as the extent of the two geometries that are
used for filtering whether this inexactness is relevant or not. Consider the following figure.
100
Copyright © 2010 Open Geospatial Consortium, Inc.
Figure 33: Spatial filtering using bounding boxes
The figure illustrates a use case in which all events that fall within a certain distance around the remaining flight path of an airplane are of interest. All other events shall be
removed using a filter with the
dwithin
spatial operator. In the upper box, the inexactness introduced when filtering using the bounding box of an event’s geometry is irrelevant
because the geometry itself is very small compared to the buffer implied by the spatial operator. In the lower box, the inexactness becomes relevant. Even though the event itself
– for example a weather observation or forecast thunderstorm, volcanic ash cloud etc. – is no longer of interest to the airplane, it will be reported to it. The event’s geometry is
not within distance to the remaining flight path – however, the bounding box computed
from the event’s geometry is. Apparently, it depends upon the use case and the geometries of the involved events whether the inexactness of using bounding boxes for
filtering is significant or not.
One way to solve the issue of inexact boundary information would be to allow more detailed geometries in the boundedBy property of a GML feature. A comparable solution
would be to add a common
spatialExtent
property to each event type used in a domain that is populated with the according geometry the revised Event Model defines such a
property - see section 12.2.4 for further information. One thing to keep in mind is that spatial filtering using simple bounding boxes is usually
faster compared to filtering where more complex geometries are used. This advantage may outweigh the issue when doing filtering using bounding boxes. However, additional
factors may be important as well, for example to keep the amount of irrelevant data that is transmitted to a client as low as possible e.g. important in networks with bandwidth
limitations. The priority of the various factors depend upon the given use case.
