Purpose and Scope
These pages contain the coding guidelines for the minimum and conditional data for the airspace subjects as defined in PANS-AIM, for both ATS Airspace and Special Activity Airspace.
In PANS-AIM only ATS airspace is defined:
Airspaces of defined dimensions, alphabetically designated, within which specific types of flights may operate and for which air traffic services and rules of operation are specified (PANS-AIM, Appendix 1 Aeronautical Data Catalogue).
According PANS-AIM the follwing types of airspaces are considerd as ATS airspaces:
- FIR/UIR
- CTA
- TMA
- CTR
In an AIP all of them are published in section ENR 2.1, except CTR which is published in AD 2.17.
For all of them the AIXM data type codeAirspaceType provides a corresponding value.
According PANS-AIM, the following types of airspaces are considerd Special Activity Airspaces:
- Prohibited Area
- Restricted Area
- Danger Area
- Military Execise Area
- Military Training Area
- Air Defence Identification Zone (ADIZ)
- Other
In an AIP these types of airspaces are published in the following sections:
- ENR 5.1 Prohibited, restricted and danger areas
ENR 5.2 Military exercise and training areas and air defence identification zone (ADIZ)
- ENR 5.3.1 Other activities of a dangerous nature
- ENR 5.5 Aerial sporting and recreational activities
For Prohibited Area, Prohibited Area, Prohibited Area and Air Defence Identification Zone (ADIZ) the AIXM data type codeAirspaceType provides corresponding values. Other airspaces may be encoded as described in page Basic Data of Airspace.
Lateral Limits
There are two main ways to describe the geometry of airspace volumes in AIXM:
- by providing a horizontal border and vertical limits;
- by providing a composition rule by which the airspace is defined as a series of unions, intersections, subtractions of other Airspace, such as in the following examples:
- Airspace of type CTR defined as a “circle of 50 NM from which the portion of airspace situated in a neighboring FIR is subtracted”;
- Airspace of type UIR that has “the same horizontal projection as an FIR”, but different vertical limits;
- Airspace of type CTA which is the result of aggregating some Airspace of type SECTOR;
- etc.
The AirspaceVolume class of the AIXM 5 model was designed in order to support the encoding of such aggregated Airspace. Note that the “operation” property of the AirspaceGeometryComponent is used.
The model gives the possibility for using several approaches for the encoding of airspace aggregations/dependencies. The use of a particular method, from the ones described further in this section, depends on the intended use of the data. Details encoding description of the GML elements used by AIXM 5 can be found in OGC® document: 12-028r1 "Use of Geography Markup Language (GML) for Aviation Data".
Airspace geometry by horizontal border
Airspace geometry - One AirspaceVolume
Airspace geometry by composition (more than one AirspaceVolume)
Types for Airspace Geometry Components
AirspaceGeometryComponent.operation
'UNON'
'SUBSTR'
'INTERS'
More than one AirspaceVolume
Option 1a: coping geometry
Option 1b: “pure geometry components”
Option 2: referencing
Geoborder & Significant Point
Geoborder
Airspace boundaries may be based on national borders or on other geographical features, such as shorelines, rivers, etc.
A particularity of this situation is that official definitions of the airspace, as provided in the Aeronautical Information Publication (AIP) or in NOTAM messages, do not include the actual geometry of the referenced geographical border. It is left for the end users to derive the actual geometry of the airspace by using a source of geographical border data.
The UML model of AIXM shows a “dependency” association between Surface and GeoBorder in order to cater for such situations
The encoding is possible in two ways: either with a simple annotation (and copy of all necessary points) or by reference. See the AIXM GML Guidelines for details.
Significant Point
Coding rules for lateral limits
Identifier | Data Encoding Rule | Justification | Data Verification Rule (UID) | Remarks |
---|---|---|---|---|
ASE-410 | An AIRSPACE instance, which has a geometry defined by aggregation (the related AIRSPACE_DERIV_GEOMETRY is related to one or more instances of AIRSPACE_AGGREG_COMP), cannot have any value specified for VAL_DIST_VER_LOWER, VAL_DIST_VER_UPPER, VAL_DIST_VER_MNM and VAL_DIST_VER_MAX. | |||
An AIRSPACE for which the lower and upper limit are not specified, must be the child in at least one AIRSPACE_ASSOCIATION having CODE_TYPE = 'BOM' (Bill Of Material). | ||||
If CODE_TYPE='PART', then the airspace must be the parent in one or more associations of type 'BOM' (relationship 'the parent in AIRSPACE_ASSOC_M' is mandatory, the related AIRSPACE_ASSOC_M must have CODE_TYPE='BOM'). | ||||
If CODE_TYPE is 'ICAO', 'ECAC', 'CFMU', 'IFPS', 'FIR', 'FIR-P', 'UIR', 'UIR-P', 'CTA', 'CTA-P', 'OCA', 'OCA-T', 'UTA', 'UTA-P', 'TMA', 'TMA-P', 'NO-FIR', then the airspace may not be part of an AIRSPACE_ASSOCIATIONS of type 'TIME-DIST'. | ||||
Adjacent airspace of type FIR or UIR should be contiguous (no gaps, no overlapping). | ||||
An AIRSPACE for which the lower and upper limit are not specified, must be the child in at least one AIRSPACE_ASSOCIATION having CODE_TYPE = 'BOM' (Bill Of Material). | ||||
An AIRSPACE that is not related to any AIRSPACE_BORDER must be the child in one or more AIRSPACE_ASSOCIACTION having CODE_TYPE = 'BOM' or 'ABOVE_BELOW'. | ||||
If CODE_OPR = 'BASE', then NO_SEQ must be '1' (first). | ||||
Child Airspace in Airspace Association type BOM cannot have duplicate operation numbers. | ||||
There must exist at least two related AIRSPACE_AGGREG_COMP. | ||||
In any set of AIRSPACE_ASSOCIATION occurences with CODE_TYPE = 'BOM' and having the same child AIRSPACE, there must exist one and only one occurence with CODE_OPR = 'BASE'. | ||||
AIRSPACE with CODE_TYPE='FIR' cannot appear as child in an AIRSPACE_ASSOCIATION of type 'BOM' or 'ABOVE-BELOW'. | ||||
All parent airspace in an association of type 'BOM' must have the same authority. | ||||
ATS Unit providing Service
Restriction & Activation
Hours of applicability / Hours of Service / Time of acitivity
In PANS-AIM different data items are defined for Schedules which are relevant for an airspace or a unit providing service within an airspace.
For ATS airspace, Appendix 1 of PANS-AIM (Aeronautical Data Catalogue) defines the "Hours of applicabiliy" for the airspace and in addtion the "Hours of Service", which are "the operational hours of the station serving the unit".
However, in an AIP the first item is only published for ATS airspaces of section AD 2.17, whereas the latter is only published for ATS airspaces listed in section ENR 2.1.
For Special activity airspaces the "Time of activity" is defined as "Time interval when the special activity takes place".
In the following only those coding rules specfic to the airspace subjects will be discussed.
For the general coding guidelines for the Timesheet refer to Schedule.
Hours of applicabiliy
This information is required for ATS airspaces usually published in "AD 2.17 Air traffic services airspace":
6) hours of applicability;
In AIXM this information will be encoded as Airspace.activation.
Identifier | Data Encoding Rule | Justification | Data Verification Rule (UID) | Remarks |
---|---|---|---|---|
ASE-310 | AirspaceActivation.activity ="ATS" | NA | ||
ASE-320 | AirspaceActivation.status ="ACTIVE" | NA | TBD: is it necessary to code the status? or is this just for DNOTAM |
Hours of Service
This information is required for ATS airspaces usually published in "ENR 2.1 FIR, UIR, TMA AND CTA":
3) call sign of aeronautical station serving the unit and language(s) used, specifying the area and conditions, when and where to be used, if applicable;
In AIXM this information will be encoded as Service.availability.
Identifier | Data Encoding Rule | Justification | Data Verification Rule (UID) | Remarks |
---|---|---|---|---|
ASE-360 | ServiceOperationalStatus.operationalStatus ="NORMAL" | NA | TBD: Is it necessary to code the operational status? Or jsut for DNOTAM | |
If CODE_TYPE is 'ICAO', 'ECAC', 'FIR', 'UIR', then CODE_WORK_HR must have the value 'H24'. |
Time of activity
This information is required for Sepecial activity airspaces usually published section in "ENR 5":
In AIXM this information will be encoded as Airspace.activation.
Identifier | Data Encoding Rule | Justification | Data Verification Rule (UID) | Remarks |
---|---|---|---|---|
ASE-370 | AirspaceActivation.activity is mandatory | NA | As appropriate. | |
ASE-380 | AirspaceActivation.status is madatory | NA | As appropriate,TBD: is it necessary to code the status? or is this just for DNOTAM TBD how to encode will be announced by NOTAM |
Coding Rules for
Identifier | Data Encoding Rule | Justification | Data Verification Rule (UID) | Remarks |
---|---|---|---|---|
ASE-370 | AirspaceActivation.activity is mandatory | NA | As appropriate. | |
ASE-380 | AirspaceActivation.status is madatory | NA | As appropriate,TBD: is it necessary to code the status? or is this just for DNOTAM TBD how to encode will be announced by NOTAM |
Coding Examples
Additional Illustrated Coding Examples
Example: Sand Springs
Note