Definition

The activation of a pre-existing (published) restricted, danger, prohibited, reserved or similar airspace.

Notes:

  • the term "special activity area" is used in order to encompass P, D, R and other areas of similar nature;

  • this scenario also supports the activation of an area with changed vertical limits (including beyond normal limits, e.g. below its baseline lower limit or above its baseline upper limit). However, this is only possible for Airspace geometries defined with their 'own' volumes. This scenario does not support the activation with changed vertical limits of an Airspace that has AirspaceVolumes that have a descendant contributorAirspace with dependency equal-to 'FULL_GEOMETRY';

  • this scenario does not support the change of the horizontal limits of an area that is normally active nor the activation beyond these horizontal limits;

  • this scenario does not support the permanent modification of the activation status of an area;

  • this scenario does not support the occasional de-activation of an area that is normally active;

  • if an airspace has several sectors (such as EAD21A and EAD21B) that may become active independently, then a separate SAA.ACT Event is encoded for each such sector;

  • this scenario does not support the activation/de-activation of CTR and other ATS airspace; see the dedicated scenario {{[ATSA.ACT]}}.

On this page

Event data

The following diagram identifies the information items that are usually provided  by a data originator for this kind of event.


ENBF Code 
input = [type] [designator] [name] "activation status" \n
"start time" "end time" [schedule]\n
["activity type"] \n
["lower limit" "upper limit"]\n
{note} {"affected aerodrome"} {"affected FIR"}.

The following table 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)


Data item

Description

AIXM mapping

type

The type of the airspace concerned by the activation. Typical examples are D (Danger), R (Restricted), D-OTHER (Other activity of Dangerous nature), TSA (Temporary Segregated Area), TRA (Temporary Reserved Area), A (Alert), W (Warning), etc.

The item is used in combination with other attributes in order to identify the area concerned.

Airspace.type with the list of values CodeAirspaceType. 

designator

The designator of the airspace concerned. The item is used in combination with other attributes in order to identify the area concerned.

Airspace.designator. 

name

The name of the airspace concerned. The item is used in combination with other attributes in order to identify the area concerned.

Airspace.name. 

activation status

The activation status. The typical term is "active". 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.

Airspace/AirspaceActivation.status

start time

The effective date & time when the airspace becomes active. This might be further detailed in a "schedule".

Airspace/AirspaceTimeSlice/TimePeriod.beginPosition, Event/EventTimeSlice.validTime/timePosition and Event/EventTimeSlice.featureLifetime/beginPosition

end time

The end date & time when the airspace activation ends. It might be an estimated value, if the exact end of the activation is unknown.

Airspace/AirspaceTimeSlice/TimePeriod.endPosition and Event/EventTimeSlice.featureLifetime/endPosition also applying the rules for {{Events with estimated end time}}

schedule

A schedule might be provided, in case the area is only active according to a regular timetable, within the period between the start time and the end time.

Airspace/AirspaceActivation/Timesheet/... according to the rules for {{Schedules}}

activity type

The kind of activity that takes place in the airspace

Airspace/AirspaceActivation.activity with the limitations on the list of values CodeAirspaceActivityType defined further below.

The data encoding rules indicate additional "'OTHER:...'" values for this data item.

lower limit

The vertical level above which and including that level the airspace becomes active; this may be different from the published lower limit of the airspace Baseline(i.e.: could be higher or lower)

Airspace/AirspaceActivation/AirspaceLayer.lowerLimit and Airspace/AirspaceActivation/AirspaceLayer.lowerLimitReference

Airspace/AirspaceGeometryComponent/AirspaceVolume.lowerLimit and Airspace/AirspaceGeometryComponent/AirspaceVolume.lowerLimitReference

upper limit

The vertical level below which and including that level the airspace becomes active; this may be different from the published upper limit of the airspace Baseline(i.e.: could be higher or lower)

Airspace/AirspaceActivation/AirspaceLayer.upperLimit and Airspace/AirspaceActivation/AirspaceLayer.upperLimitReference

Airspace/AirspaceGeometryComponent/AirspaceVolume.lowerLimit and Airspace/AirspaceGeometryComponent/AirspaceVolume.lowerLimitReference

note

A free text note that provides further instructions concerning the area activation, such as the authority to be contacted for further information, the possibility of crossing at ATC discretion, etc.

Airspace/AirspaceActivation.annotation with purpose=”'REMARK'”

affected aerodrome

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)

Note: a default list of 'affected airports' might need to be maintained in the application used for the Digital NOTAM coding.

Event.concernedAirportHeliport
affected FIR

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.

Event.concernedAirspace


Assumptions for baseline data

It is assumed that information about the area already exists in the form of Airspace BASELINE TimeSlice(s) covering the complete period of validity of the event, coded as specified in the Coding Guidelines for the (ICAO) AIP Data Set.

Note: Exceptionally, the activation could concern a temporary area, created with an SAA.NEW scenario. This does not need any special treatment in this scenario, the SAA.NEW scenario creates an Airspace BASELINE, which looks similar to a BASELINE contained in an AIP data set.

Data encoding rules

The data encoding rules provided in this section shall be followed in order to ensure the harmonisation of the digital encodings provided by different sources. To the maximum possible extent, the compliance with these encoding rules shall be verified with automatic data validation rules.


Identifier

Data encoding rule

ER-01

The activation of an airspace shall be encoded as:

  • a new Event with a BASELINE TimeSlice (scenario=”SAA.ACT”, version=”2.0”), for which a PERMDELTA TimeSlice may also be provided; and

  • a TimeSlice of type TEMPDELTA for the corresponding Airspace feature, for which the "event:theEvent" property points to the Event instance created above; 

ER-02The TEMPDELTA shall contain at least one AirspaceActivation object with status equal-to 'ACTIVE', 'IN_USE' or 'INTERMITTENT' (as appropriate).

ER-03

If the whole airspace becomes active, from floor to ceiling, then the Airspace TEMPDELTA should use the the values 'FLOOR' for lowerLimit (no uom value) and 'CEILING' (no uom value) for the upperLimit of the AirspaceLayer associated with the AirspaceActivation.

ER-04

If the airspace becomes active below its nominal lower limit or above its nominal upper limit (as defined in the Airspace BASELINE), then the Airspace TEMPDELTA TimeSlice shall include both:

  • the actual upper/lower limit values of the activation, coded inside the AirspaceLayer associated with the AirspaceActivation, and

  • the AirspaceGeometryComponents with the modified upper and/or lower limits. Note the scenario limitation - this is applicable only to AirspaceVolume that have their own upperLimit and lowerLimit. Such AirspaceVolume cannot have a contributorAirspace with dependency equal-to 'FULL_GEOMETRY'.

ER-05

If the area activation 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 of the Airspace TEMPDELTA Timeslice. See the encoding rules for Schedules [PWS].

ER-06

In accordance with the AIXM Temporality Concept, the AirspaceActivation associated with the TEMPDELTA completely replaces all the BASELINE AirspaceActivation information, during the TEMPDELTA time of applicability. Therefore, if the activation only concerns certain times and/or levels, the other times and/or levels, when the airspace eventually remains with the same status as in the Baseline data (including the times when the area is 'INACTIVE') shall be explicitly included in the TEMPDELTA, as explained in the general rules for coding schedules.

The calculation of the necessary additional AirspaceActivation elements to be included in the TEMPDELTA shall be automatically done by the applications implementing this specification. All AirspaceActivation elements that are calculated from the BASELINE data for completeness sake shall get an associated Note with purpose=REMARK and the text="Baseline data copy. Not included in the NOTAM text generation". This is based on the current NOTAM practice which consists of including in the NOTAM only the changed information and not explicitly including the static data that remains valid during the NOTAM applicability.

ER-07

The activity types that do not match a pre-defined value in the CodeAirspaceActivityType, but for which exists a dedicated NOTAM selection criteria, shall be encoded as follows:

  • captive balloon → activity=OTHER:CAPTIVE_BALLOON

  • kite → activity=OTHER:KITE

  • demolition using explosives → activity=OTHER:DEMOLITION

  • mass movement of aircraft → activity=OTHER:ACFT_MASS_MOVEMENT

  • formation flight → activity=OTHER:ACFT_FORMATION

  • significant volcanic activity → activity=OTHER:VOLCANO

  • model flying → activity=OTHER:MODEL

  • search and rescue → activity=OTHER: SAR

  • ascent of sky lanterns → activity=OTHER:SKY_LANTERN

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:

  • activity='OTHER', unless a relatively similar coded value is available and can be used;
  • in addition, activity information may be provided as part of the general note element.
ER-08

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. 

ER-09If an "affected aerodrome" is provided by the data originator, then a corresponding concernedAirportHeliport property shall be coded in the Event.

Examples

Following coding examples can be found on GitHub (links attached):



  • No labels