Note for reviewers
Open comments are still available at: https://docs.google.com/document/d/1L3vn2cD2P5C6_r3yQWw_HqwzqCUUU7eu
xOeTG998X4o/edit#heading=h.5bj3m9gsrk34
Scenario is work in progress.
Definition
The activation or deactivation of published (pre-existing) CTR, CTA, TMA or similar airspaces.
Notes:
- the term "Published ATS Airspace" is used to encompass CTR, CTA, TMA or other airspaces of similar nature;
- this scenario includes both the temporary activation and the temporary deactivation of pre-existing ATS Airspace;
- this scenario includes the possibility to provide an activation schedule, but only "ACTIVE" times will be translated into NOTAM text;
- this scenario does not include the temporary modification of the ATS Airspace classification;
- this scenario does not include temporary modification of vertical limits of published ATS Airspace nor the activation beyond these vertical limits;
- this scenario does not include temporary modification of horizontal limits of published ATS Airspace nor the activation beyond these horizontal limits;
- this scenario does not include the permanent modification of activity status of published ATS Airspace;
- this scenario does support the activation through a single NOTAM of the sectors/parts of one ATS airspace.
Event data
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).
Data item | Description | AIXM mapping |
|---|---|---|
type | The type of airspace concerned. Typical examples are CTR and TMA. | Airspace.type with this list of values CodeAirspaceType. Not to be encoded, just used to identify the airspace concerned. |
designator | The published designator of the airspace concerned. If not provided, then the airspace is identified by its name. | Airspace.designator. Not to be encoded, just used to identify the airspace concerned. |
name | The published name of the area. | Airspace.name. Not to be encoded, just used to identify the airspace concerned. |
activation status | The activation/de-activation status. | Airspace/AirspaceActivation.status with the list of values CodeStatusAirspaceType |
start time | The effective date & time when the activation/de-activation starts. 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 activation/de-activation ends. It might be an estimated value, if the exact end of activation is unknown. | Airspace/AirspaceTimeSlice/TimePeriod.endPosition and Event/EventTimeSlice.featureLifetime/endPosition also applying the rules for {{Events with estimated termination}} |
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}} |
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” |
Notes:
- It is recommended that data input applications allow the operator to visualise graphically the horizontal shape and the vertical extent of the ATS airspace activation, in the context of the overall airspace structure of the region. If a schedule is used, the graphical interface should also have a "time slider" that allows the operator to see when the airspace is actually active.
Assumptions for baseline data
- It is assumed that information about the area already exists in the form of an Airspace Baseline, which contains as a minimum the horizontal shape of the airspace, its vertical limits, its name and its type;
- If the Baseline data includes a schedule associated with the AirspaceActivation, then this should not leave any gaps. If any gaps exist, then the status of the AirspaceActivation at the levels/times concerned is considered "undefined". See the AIXM Temporality Concept (versions 1.0) sections 3.4 and 3.5;
- If an area has sectors, it is assumed that each sector was encoded separately, as an airspace with its own designator, so that it can be activated individually. The collapsed area should not exist as a Baseline airspace, just the sectors. If the area becomes active, the digital data encoding should activate the individual sectors as part of one event;
- If the Airspace concerned has BASELINE type=CLASS, then it is assumed that it contains a single AirspaceLayerClass child element. Otherwise, the algorithm for the automatic generation of the item E will not work properly.
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. The compliance with some of these encoding rules can be checked with automatic data validation rules.
Identifier | Data encoding rule |
ER-01 | The activation of an airspace shall be encoded as:
|
ER-02 | The Airspace TEMPDELTA should use the values "FLOOR, uom=OTHER" for lowerLimit and "CEILING, uom=OTHER" for the upperLimit of the AirspaceLayer property associated with the AirspaceActivation. |
ER-03 | If the area activation/de-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 rules for {{Schedules}}. 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-04 | In accordance with the AIXM Temporality Concept (see sections 3.4 and 3.5 in version 1.0), the AirspaceActivation associated with the TEMPDELTA completely replaces all the BASELINE AirspaceActivation information, during the TEMPDELTA time of applicability. Therefore, if the activation/deactivation only concerns certain times, then the other times (when the airspace eventually remains with the same status as in the Baseline data) shall be explicitly included in the TEMPDELTA. 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 copied 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. It is recommended that the input interface provides a "calendar/level" view of the airspace activity, enabling the operator to graphically check the status of the airspace at different times and levels, such as in the example below:
In the calendar view, the Baseline information that remains valid during the Event validity time shall be visibly identified from the information that is specific to the Event, for example by using a different colour fill pattern. |
Examples
...