Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 23 Next »

Introduction

Note

Many terms used in this  are based on the Temporality Concept version 1.1. It is strongly recommended to read and understand it before reading further.

Event as notification mechanism

The provision of coded Event features serves two main purpose: identify a data change scenario and identify the AIXM features and their TimeSlices that actually describe the change. The Event is primarily a change notification mechanism. The lifetime of an Event is dictated by both its genuine duration and its intended use for data change notification, for example in a pre-flight information product or service:

  • in the case of a temporary change, the Event will have a lifetime equal to the time extent of the situation. If the temporary situation is extended or shortened, the Event lifetime will also be extended or shortened.
  • in the case of a permanent change, the Event will have a lifetime that starts with the effective date/time of the change and ends after a pre-defined period of time. By similarity to the current Trigger NOTAM validity rules, a 14 days period of validity is pre-defined for the Events that contain only permanent changes.

Event TimeSlices

The Event is a regular AIXM feature, therefore it has TimeSlices. Each Event will be first encoded as a 'BASELINE' TimeSlice, for which a 'PERMDELTA' may also be provided. An eventual change in the Event information can be encoded with additional Event TimeSlice, applying the same temporality rules as for any other feature.

No use case has been identified for temporarily updating an Event with a 'TEMPDELTA' TimeSlice, therefore TEMPDELTA Timeslices are not expected to be used for Event.

Relation with AIXM Feature TimeSlices

In order to relate the AIXM feature TimeSlices with the Event to which they belong, an extension for each AIXM feature is declared in the "event" namespace. This consists of an association from the feature TimeSlice towards the Event class, as shown in the UML class diagram to the right

  • Most temporary events will need a single AIXM Feature TimeSlice to be provided. For example, the activation of a temporary restricted area will require a single Airspace TimeSlice of type TEMPDELTA
  • More complex events might require several TimeSlices to be encoded in several different features. For example, the establishment of a new obstacle (temporary or permanent) requires two AIXM features to be encoded or modified:
    • first, a new VerticalStructure needs to be encoded;
    • second, associations between the affected ObstacleArea(s) and the new VerticalStructure might need to be established.

The lifetime of the event is related to the lifetime of the associated AIXM Feature TimeSlices.  The lifetime of the Event needs to encompass the lifetime of all AIXM feature TEMPDELTA TimeSlice that associated with the Event.



Coding rules

Start of event

The start of the event lifetime shall always be equal to the start of validity of the earliest associated feature TimeSlice.

Note:  It could be argued that the Event start of validity could anticipate the applicability time of a change in the aeronautical data, while not interfering with it since each feature TimeSlice that is related to the Event will have anyhow its own valid time. However, this would make it more difficult to identify the changes that are already active, since the validTime of each associated feature TimeSlice would have to be verified.

Therefore, the featureLifetime.beginPosition of an Event (and implicitly the start of validity of its first TimeSlice) shall be equal to the earliest validTime.beginPosition between all the TimeSlice that refer to the Event, through the ‘belongsTo” association.

End of event - temporary changes

For temporary events, the featureLifetime.endPosition of an Event (and implicitly the end of validity of its last TimeSlice) shall be equal to the latest validTime.endPosition between all the TimeSlice that refer to the Event, through the ‘belongsTo” association.

Example

In the following diagram, it is assumed that:

  • Feature A and Feature B existed (as baseline) before the event. During the event, they are affected by a temporary change, which is coded as a TEMPDELTA. For example, Feature A could be a Runway which is temporarily shortened because some work in progress on its surface.
  • Feature C is a temporary feature, which appears with the event. According to the current AIXM temporality concept, it is coded with a new BASELINE. For example, this could be a temporary lighting pole on the runway, which is coded as VerticalStructure,


End of event lifetime - permanent changes

For events that include only permanent changes, the featureLifetime.endPosition of an Event (and implicitly the end of validity of its last TimeSlice) two aspects need to be considered:

  • the Event should remain valid for a certain time, in order to ensures that the Event can be retrieved and included in pre-flight briefing products;
  • the Event should cease its validity/lifetime at a certain moment in order to no longer appear as a "on going event" forever;

Thus, it is recommended that such Events have a default lifetime of 14 days after the effective date, unless the data provider decides on a different duration and unless the Event is associated with a PERM NOTAM. which is discussed below. 

However, if the Event is initially promulgated through a NOTAM PERM, it will initially have an indeterminate end of validity. Once the change is incorporated in the static data AIS Products, such as AIP, charts and data sets, the Event will also get an end of validity. An additional "event closing" BASELINE needs to be coded in order to indicate the changes in the association with the AIS Products. 

Estimated end time - temporary changes

An event, such as work planned at an airport or the outage of a navaid, may sometimes have an estimated end. Its duration depends on external factors, which cannot be controlled or known with sufficient precision in advance.

An estimated end of validity is supported in AIXM through the use of the attribute indeterminatePosition for the gml:endPosition element. In addition, the estimated end of validity of the Event is coded using its Event.estimatedValidity property. This attribute actually makes the distinction between permanent changes and temporary changes with an estimated end of validity.

Note that the allowable values for indeterminatePosition also include the values "before" and "after", which enable the provision of a more detailed estimation. For example, if an event is estimated to end at maximum at 09:00 on 15 APR 2010, this could be theoretically coded as follows: <gml:endPosition indeterminatePosition="before">2010-04-15T09:00:00</gml:endPosition>. The usage of the values "before" and "after" is not recommended in the current version of this specification. A future version might include rules for the usage of these values, if the operational need is confirmed.

Update before reaching the estimated end of validity

According to PANS-AIM, NOTAM Format, "any NOTAM which includes an 'EST' shall be cancelled or replaced before the date-time specified in Item C)". Therefore, events that have an estimated end of validity shall be updated before that time is reached. The OPADD document makes some recommendations, which can also be applied to digital data encoding:

The data management system shall ensure that a reminder is provided before the "estimated" end of validity, to produce an update of the Event. Individual parameters can be installed, depending upon the type of information, and the operational possibilities of the organisation. The following parameters are indicative, depending on the duration calculated by subtracting the validTime.TimePeriod.begin.Position from the Event.estimatedValidity :

  • up to 1 day : 6 hours before reaching the indeterminate (estimated) time;
  • more than 1 day and up to 1 month : 1 day before reaching the indeterminate (estimated) time;
  • more than 1 month and up to 3 months : 3 days before reaching the indeterminate (estimated) time.

It is a serious safety hazard if an Event with an estimated end of validity is not updated before that estimated time is reached. Not being able to update the information about estimated events in time, for example because of recurrent difficulties to obtain updated information from their originators, is a serious handicap for NOTAM offices that wish to implement this specification.

AIXM coding example
...
<gml:validTime>
  <gml:TimePeriod gml:id="CY01_TS02_TP01">
    <gml:beginPosition>2010-04-07T09:00:00</gml:beginPosition>
    <gml:endPosition indeterminatePosition="unknown"/>
  </gml:TimePeriod>
 </gml:validTime>
 <aixm:interpretation>TEMPDELTA</aixm:interpretation>
 <aixm:sequenceNumber>13</aixm:sequenceNumber>
 <estimatedValidity>2010-05-06T17:00:00</estimatedValidity>
...
  • No labels