Page Comparison

...

The UML model that defines the Event class and its main properties is shown in the following diagram.

The main element is the "Event" feature, defined as “an operational situation that results in the temporary or permanent change of the properties of one or more aeronautical information features” with the following attributes:
name - “a title by which the event is known to people involved in aeronautical operations”;
designator - “a code by which the event is identified in applications and systems used in aeronautical operations”
digital - “an indication that the information is provided as digital data, to the full extent permitted by the coding rules and by the current data model, as opposed to free text annotations”;
scenario - “the identifier of a pre-defined scenario that provides the data encoding rules for a specific operational situation”. Together with the version attribute (see below), this allows identifying the set of data verification rules that may be applied in order to check the correctness of the coding.
version - “the version of the pre-defined coding scenario (usually the version of the document that contains the scenario)”;
estimatedValidity - “for Events that have an indeterminate end of life, it indicates a date and time by which the event is expected to end.” If the estimated end of life is reached without any other update of the Event data, the Event is considered to be still valid.
activity - “a short indication of the type of activity or operational situation that makes the event”
summary - “a descriptive summary of the event, with the possibility to include maps, diagrams and formatted text”.
An Event may be associated with one or more AirportHeliport and/or one or more Airspace. The purpose of these associations is to identify the locations that are operationally concerned by the event. This is derived from the current pre-flight information bulletin practice, in which information is organised by airport/FIR. In many cases the airspace or airport concerned may be identified automatically. However, there are situations, such as remote training areas used by military flights, where identifying the airport concerned might require human expertise.
In some particular situations, it might be interesting to also associate the Event with a smaller area, such as an area used for military training. This allows the identification of events that need to be included in the pre-flight information briefing for a military flight inside the area concerned.
The Event also has a "self-association" that allows encoding event dependencies, in which one event is the cause of other events. For example, the temporary displacement of a runway threshold could trigger changes in approach and departure procedures, which could be encoded as separate events.
A second self-association allows encoding groups of events, which are part of the same operational project, but which are not mandatory the consequence of each other. For example, the data about a large military exercise, seen as the root event, can be organised in sub-events such as airspace reservation, route closures, airport usages, etc. Usage rules for these self-associations are provided further in this specification.
The information about the actual change brought by the Event to the properties of the affected AIXM features is encoded as TimeSlices of the relevant AIXM features. This is the real digital Event encoding part of the schema. 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 in an association from the feature TimeSlice towards the Event class, as shown in the Event UML class diagram.
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 Event may also be associated with the Unit that is the provider of the Event information. This information is required by the ICAO PANS-AIM as part of the minimal metadata to be provided with the digital AIS data sets. A direct association between Event and Unit allows to avoid using the much more complex ISO 19139 metadata schema for such small digital data sets as is the case for Digital NOTAM.

XML Schema

Usage and applications