The following diagram identifies the information items that are usually provided by a data originator for this kind of event.
The table below provides more details about each information item contained in the diagram. It also provided the mapping of each information item within the AIXM 5.1 structure. The name of the variable (first column) is recommended for use as label of the data field in human-machine interfaces (HMI).
The type of area, although this is not always explicit; it may be implicit, due to the kind of activity taking place. Typical examples are D (danger), R (restricted), P (prohibited), D-OTHER (other activity of dangerous nature).
Airspace.type with the list of values CodeAirspaceType. To be consistent with the scenario scope and purpose, only the following types shall be used: P, D, R, TSA, TRA, W, A, D-OTHER, PROTECT, OTHER
A designator allocated to the area. It is unlikely that such designators are provided by the data originator. It is more likely that the designator will be allocated by the publication office.
The name of a geographical feature or location, which is also used for identifying the area
The kind of activity that takes place in the area
Airspace/AirspaceActivation.activity with the limitations on the list of values CodeAirspaceActivityType defined further below.
|The activation status. The typical term is "active", occasionally could be "intermittent". Systems that provide tactical status data might also use the term "in use", when the airspace is effectively used for the activity for which it was reserved.
A free text note that indicates the location of the area in relation with relevant geographical or aeronautical features, such as "North of SJAELLANDS", "10NM east Kirn VOR KIR", "Inside Donlon TMA", etc.
Airspace.annotation with propertyName='geometryComponent' and purpose='REMARK'
The effective date & time when the area becomes established and active. This might be further detailed in a "schedule".
Airspace/AirspaceTimeSlice.featureLifetime/beginPosition, Airspace/AirspaceTimeSlice/validTime/beginPosition, Event/EventTimeSlice.validTime/beginPosition and Event/EventTimeSlice.featureLifetime/beginPosition
The end date & time when the area ceases to exist. It might be an estimated value, if the exact end of activation is unknown. It may also be indeterminate for a permanent area.
Airspace/AirspaceTimeSlice.featureLifetime/endPosition, Airspace/AirspaceTimeSlice/validTime/endPosition, Event/EventTimeSlice.validTime/endPosition and Event/EventTimeSlice.featureLifetime/endPosition also following the rules for Events with estimated end time, if applicable
A schedule might be provided in case the area is only active according to a regular timetable, within the overall period when it exists.
Airspace/AirspaceActivation/Timesheet/... according to the rules for Schedules
The horizontal shape of the area or of one of its composing volumes (if the area is an aggregation of different volumes with different vertical limits).
Airspace/AirspaceVolume.horizontalProjection following the rules for encoding for encoding Geometrical and geographical data. Only geometries of type Polygon, Circle or Corridor are allowed in this scenario.
A reference (type, designator, name) to one or more airspace that are excluded (subtracted) from the volume described by the aggregation of the horizontal limits specified for the area; for example: "Excluding the Heathrow CTR".
The lower limit (value, unit of measurement and vertical reference) of the area.
Airspace/AirspaceVolume.lowerLimit and Airspace/AirspaceVolume.lowerLimitReference
The upper limit (value, unit of measurement and vertical reference) of the area.
Airspace/AirspaceVolume.upperLimit and Airspace/AirspaceVolume.upperLimitReference
A free text note that provides information about the unit or service that controls the area or that can authorize the penetration of the area or indicating further instructions concerning the special activity area, such as about possible future changes to the area, detailed description of the reason that led to the area establishment, etc.
Airspace/AirspaceActivation.annotation with purpose='REMARK', according to the rules for encoding annotations
|A reference (name, designator) to one or more airports/heliports for which the establishment of the area has an operational relevance and needs to be notified to the users thereof (if such information is known to the data originator)
A reference (type, designator) to one or more neighboring airspace of type FIR, for which the establishment of the area has an operational relevance and needs to be notified (if such information is known to the data originator).
Note: the FIR(s) within which the area is physically situated do not need to be provided by the data originator. They will be automatically identified by the application that enables the coding of the Event.
It is recommended that data input applications allow the operator to visualise graphically the horizontal shape and the vertical extent of the special activity area. If a schedule is used, the graphical interface should also have a "time slider" that allows the operator to see when the area is actually active.
Assumptions for baseline data
It is assumed that no baseline data exists for this area.
Data encoding rules
The applicable AIP Data Set coding rules for Airspace shall be followed in order to ensure the harmonisation of the digital encodings provided by different sources. In addition, the following coding rules are specified for this particular scenario:
Data encoding rule
The special activity area shall be encoded as:
The Airspace BASELINE shall contain one AirspaceActivation object with status='ACTIVE', 'IN_USE' or 'INTERMITTENT' (as appropriate) which shall also include the "activity" data and the values 'FLOOR' for lowerLimit (no uom value) and 'CEILING' (no uom value) for the upperLimit of the associated AirspaceLayer.
If the area activity is limited to a discrete schedule within the overall time period between the "start time" and the "end time", then this shall be encoded using as many as necessary timeInterval/Timesheet properties for the AirspaceActivation with status ACTIVE/IN_USE/INTERMITTENT of the BASELINE Timeslice. See also the rules for Event Schedules.
If a schedule is provided, then the Airspace BASELINE shall contain a second AirspaceActivation object with status='INACTIVE', which shall explicitly specify the times not covered by the activity schedule.
This could be done automatically by the system and should not be visible to the operator.
It is recommended that the HMI of a data provider application allows to provide a schedule only in relation with active times, because only these will be translated into NOTAM text.
If one or more "exclude airspace" are specified, each shall be encoded as an AirspaceGeometryComponent with operation='SUBTR', operationSequence as dictated by the order of the element, contributorAirspace/AirspaceVolumeDependency.dependency='FULL_GEOMETRY' and pointing to the airspace concerned. See the Geometry of Airspace coding rules for further details.
Note: in this case, it is important that the geometryComponent parent of the AirspaceVolume created with the horizontalLimit data has operation='BASE' and operationSequence='1'.
The activity types that do not match a pre-defined value in the CodeAirspaceActivityType, but for which exists a dedicated NOTAM selection code, shall be encoded as follows:
Note: all other activities, which do not match either a pre-defined value in the CodeAirspaceActivityType or one of the above additional OTHER:... values, should be encoded as follows:
If the type is not provided by the data originator, then the following encoding rules shall be applied in order to give a value to "type" attribute of the Airspace BASELINE TimeSlice:
It is recommended that an alphanumeric designator is allocated to a temporary area, in order to facilitate its identification on graphical representations (such as airspace activity maps) and verbal communication. The composition rule is derived from the rules for P, D, R area designators: CCLnnnn-yy, where:
The system shall automatically identify the FIR(s) intersected by the horizontal projection of the area. They shall be coded as corresponding concernedAirspace property(ies) in the Event
If any different "affected FIR" from the one(s) determined above is(are) provided by the data originator, then corresponding concernedAirspace property(ies) shall be coded in the Event.
|If an "affected aerodrome" is provided by the data originator, then a corresponding concernedAirportHeliport property shall be coded in the Event.
Following coding examples can be found on GitHub (links attached):