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. This allows updating an Event:
each EventEach Event will be first encoded as a BASELINE TimeSlice, for which a PERMDELTA may also be provided
;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.
| Warning | ||
|---|---|---|
| ||
Wolfgang Scheucher Could examples be provided for NOTAM C and NOTAM R scenarios. What values will the Event validTime and featureLifetime get? François Germain Comment above to be dealt with consistently with comments in confluence here: |
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..
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.
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.
