[2.0] [SAA.NEW] Ad-hoc special activity area - creation

Owned by Andreea Perca (Deactivated)
Last updated: 2024 Mar 15 by POROSNICU Eduard

Definition

The establishment of a new restricted, dangerous, prohibited, etc. area or navigation warning, which did not exist as a published (static data) airspace.

Notes:

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

  • this scenario does not include the establishment of temporary ATS airspace (such as a temporary CTR or airspace with a specified class); see the dedicated scenario “Ad-hoc ATS airspace - creation [ATSA.NEW]”;

  • the creation of a permanent D or R area by NOTAM shall be an exceptional situation, as such events are expected to be managed as static data amendments. However, this is supported in this scenario as the same data requirements and rules apply and it helps ensuring that all the airspace created by NOTAM are made available digitally, not only the temporary ones;

  • this scenario does not cover the encoding of mobile airspace reservations, such as for aerial refuelling areas that move along a specified trajectory.

  • this scenario does not support the creation of airspace with conditional lower/upper limit, such as “6000 FT AMSL, but at least 1000 FT AGL”.

Event data

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

EBNF Code 
input = [type] [designator] [name] [activity] "activation status" ["location note"] \n
"start time" "end time" [schedule] \n
("polygon" | "circle" | ("corridor centreline" "width")) {"excluded airspace"} "lower limit" "upper limit" \n
[note] {"affected aerodrome"} {"affected FIR"}.


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

Data item

Description

AIXM mapping

type

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

designator

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.

Airspace.designator

name

The name of a geographical feature or location, which is also used for identifying the area

Airspace.name

activity

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.

activation statusThe 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.Airspace/AirspaceActivation.status

location note

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'

start time

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

end time

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

schedule

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

polygon

A polygon representing the horizontal shape of the area (before considering, if present, the airspace exclusions specified as "excluded airspace").

Airspace/AirspaceVolume.horizontalProjection following the rules for encoding for encoding polygons as specified in the Geometrical and geographical data. 

circle

A circle representing the horizontal shape of the area (before considering, if present, the airspace exclusions specified as "excluded airspace").

Airspace/AirspaceVolume.horizontalProjection  following the rules for encoding for encoding circles as specified in the Geometrical and geographical data. 

corridor centreline

The centreline of a corridor representing the horizontal shape of the area (before considering, if present, the airspace exclusions specified as "excluded airspace").

Airspace/AirspaceVolume.centreline following the rules for encoding for encoding curves as specified in the Geometrical and geographical data. 

width

The width of the corridor representing the horizontal shape of the area.

Note that the current NOTAM practice is to indicate the "half-width" (either side of the centreline) while in AIXM the full width is coded.

Airspace/AirspaceVolume.width

excluded airspace

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

Airspace/AirspaceVolume.contributorAirspace

lower limit

The lower limit (value, unit of measurement and vertical reference) of the area.

Airspace/AirspaceVolume.lowerLimit and Airspace/AirspaceVolume.lowerLimitReference

upper limit

The upper limit (value, unit of measurement and vertical reference) of the area.

Airspace/AirspaceVolume.upperLimit and Airspace/AirspaceVolume.upperLimitReference

note

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

affected aerodromeA 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)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

Note:

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

Identifier

Data encoding rule

ER-01

The special activity area shall be encoded as:

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

  • a new Airspace BASELINE TimeSlice for which a PERMDELTA TimeSlice may also be provided; the property "event:theEvent" of the Airspace TimeSlices shall refer to the Event mentioned above.

ER-02

The Airspace BASELINE shall contain one AirspaceActivation object with status='ACTIVE', 'IN_USE' or 'INTERMITTENT' (as appropriate) which shall also include the "activity" data (if provided) and the values 'FLOOR' for lowerLimit (no uom value) and 'CEILING' (no uom value) for the upperLimit of the associated AirspaceLayer.

ER-03

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.

ER-04

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.

ER-05

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

ER-06

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:

  • 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

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:

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

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:

  • if the notes encoded for the area indicate that the area is "prohibited", "compulsory bypass", "no fly zone" or equivalent for certain flights or aircraft, partially or totally, then the type "P" shall be allocated;

  • if the notes encoded for the area indicate that the area may be crossed following approval from a specified authority, then type "R" shall be allocated;

  • if the activity encoded is one of the following, then the type "D-OTHER" shall be allocated: AERIAL_WORK, FIRE_FIGHTING, NAVAL_EXER, BIRD, LASER, HI_RADIO, SPORT, AEROBATICS, TRAINING, REFUEL, GLIDING, BLASTING, BALLOON, TOWING, MISSILES, AIR_GUN, ARTILLERY, FIREWORK, SPACE_FLIGHT, PARACHUTE, PARAGLIDER, HANGGLIDING, CHEMICAL, NUCLEAR, GAS, UAV, OTHER:DEMOLITION, OTHER:CAPTIVE_BALLOON, OTHER:KITE, OTHER:ACFT_MASS_MOVEMENT, OTHER:ACFT_FORMATION, OTHER:MODEL, OTHER:VOLCANO, OTHER:SKY_LANTERN;

  • if the activity encoded is one of the following, then the type "PROTECT" shall be allocated: ACCIDENT, VIP.

ER-08

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:

  • CC is the Country Code; this could be expanded into a full FIR identifier if necessary to have a finer granularity of the airspace reference;

  • L is a letter that corresponds to the area type;

  • nnnn is a number, unduplicated during the same year, within the State or territory concerned;

  • yy are the last two digits of the year date when the area becomes effective.

ER-09

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-10If 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):