Introduction
| Tip | ||
|---|---|---|
| ||
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. |
The lifetime of an Event is dictated by both its genuine duration and its intended use as notification mechanism. The Event needs to remain valid as long as it might need to be selected for entry in a pre-flight information bulletin.
- in the case of a temporary situation, the Event will have a lifetime equal to the time extent of the situation.
- 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 when the changed information is integrated in the reference AIS digital data set (such as the AIP data set) or pre-formatted product (such as the AIP).
Coding rules
It shall be noted that 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.
Most events will need a single feature TimeSlice to be provided. For example, the activation of a temporary restricted area will require a single Airspace TimeSlice of type TEMPDELTA. However, there might exist events that 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.
An eventual change in the Event information (the equivalent of a NOTAM Replacement or Cancellation) 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.
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: 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.
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) shall be dictated by the date/time when the feature TimeSlices that refer to the Event are incorporated in static AIS products (AIP, digital data sets), if applicable. If the Event data is directly related to a static data product, then the “Trigger NOTAM” principle is applied - the Event will have a lifetime of 14 days. This ensures that the Event can be easily retrieved and included in pre-flight briefing products.
Estimated end time
An event, in particular when published as NOTAM or AIP Supplement, may have an estimated end of validity. Although the digital data is expected to be more precise than the NOTAM text messages, there are still situations where the end of an activity cannot be 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.
| Code Block | ||||
|---|---|---|---|---|
| ||||
...
<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>
...
|
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.
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) shall be dictated by the date/time when the feature TimeSlices that refer to the Event are incorporated in static AIS products (AIP, digital data sets), if applicable. If the Event data is directly related to a static data product, then the “Trigger NOTAM” principle is applied - the Event will have a lifetime of 14 days. This ensures that the Event can be easily retrieved and included in pre-flight briefing products.
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,
| Warning | ||
|---|---|---|
| ||
Add a diagram with a BASELINE/PERMDELTA and showing the Event lifetime being 14 days after the start of the event. |