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 12 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 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.

However, 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 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


  • 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.

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 TimeSlice that associated with the Event.

Event as notification mechanism

The lifetime of an Event is dictated by both its genuine duration and its intended use as notification mechanism. In addition to encompassing the lifetime of all associated AIXM Feature TimeSlice, the Event needs to remain valid as long as it might need to be selected for entry 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.
  • 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/charts).



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: 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) 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 - 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.

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