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:

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:



Assumptions for baseline data

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:

  • a new Event with a BASELINE TimeSlice (encoding=”DIGITAL”, scenario=”ATSA.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; the TEMPDELTA shall contain one or more AirspaceActivation objects.

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

...