Copyright © 2013 Open Geospatial Consortium.
67
7.4.5.1 Problem Statement
As previously stated, the economic use of bandwidth plays an important role in Aviation- specific applications. Therefore, a client should be able to define a behavior on how and
how often to retrieve notification through an ES instance. This particularly applies to situations where an immediate update is not always required. If a client is able to define
intervals in which it would like to retrieve new data it would not be overextended with massive amounts of data and would be able to focus on the most relevant information.
7.4.5.2 Concept and Methods
Update Intervals are a specialized form of Notification dissemination to an Event Service client. They are used to define a time window in which an ES implementation collects all
Notifications which match a subscription. Depending on specified parameters it was decided that if only the latest event within this time window was forwarded to the client
or whether a data format batching notifications e.g. multiple TimeSlices for one feature would be applied. By defining these intervals, a client could benefit from reduced
bandwidth load. Update Intervals could be applied to any subscription made at an Event Service. Client software should make the decision on what subscriptions it would like to
receive information at specific rates.
7.4.5.2.1 Requirements
An Update Interval implementation must fulfill the following requirements.
When subscribing, the client software should be able to define if it is interested in receiving all messages batching or only the latest event of the specified time
window.
o
The latest event option has to be applied with great care. In the case of multiple new TimeSlices for one feature e.g. a Runway operational
status in the time window only the latest TimeSlice would be delivered to the client. If situations occur where another property besides the
operational status of that Runway has changed previously the latest event option will omit the dissemination of that TimeSlice and only
provide the information on the operational status. Client software should always be aware of this fact and therefore define subscription filters in a
way that such situations are not likely to occur.
o
Identifying duplicate events should be applied to the batching option. Examples of duplicate events include single service duplication error,
multiple service duplication e.g., AIM issues TFR for a presidential event and then a conflation service also publishes the same TFR – both services
are assumed to be consumed by the client, or multi-agency duplication e.g., both the military and the FAA maintain a set of NOTAMs and both
can be considered authoritative governance issue. If a client subscribes to both feeds it will receive multiple events. It is the decision of the ES
68
Copyright © 2013 Open Geospatial Consortium.
implementation on how to detect duplicate events. One approach could be the comparison of gml:identifiers but in some cases more complex
algorithms need to be applied.
o
The capability of a service to detect different features e.g. two different Airports within a time window should be specified in the service
capabilities. For OWS-9 an implementation will not be available and will be proposed for future work.
If no update has been received within the interval, an Update Interval implementation should provide a system message stating that no event has been
received.
An Update Interval cannot be changed after the subscription has been created. If a client wants to change it, it should cancel the existing subscription and create a
new one with the adjusted Update Interval.
7.4.5.2.2 Use Case