Requirements Concept and Methods

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