Model overview

The Event class has two associations that enable coding an operational location of the event in relation with Airspace and/or AirportHeliport as shown in the diagram to the right. The main purpose of these associations is to enable a quick sorting/filtering of the Events that may have an operational impact on the airspace (typically an FIR) and/or the aerodrome/heliport concerned. This is derived from the current Pre-flight Information Bulletins (PIB) practice, where NOTAM are grouped in aerodrome and en-route sections.

In addition, some Events might required several NOTAM to be published. The reason is also related to how NOTAM are currently selected for inclusion in PIB, based on the item A (airport code or FIR code). It has to be assured that the NOTAM appear correctly in the relevant en-route and airport PIB and that duplication in PIB (e.g. in the FIR) are avoided. Typical events are:

  • airspace activities in the vicinity of several airports;
  • airspace activities affecting more than one FIR;
  • outages of navigation aids affecting serving several airports and/or FIR;
  • establishment of ATS airspace serving more than one airport;
  • obstacles in the vicinity of several airports;
  • etc.

Coding rules

Based on the current PIB practice:

  • the association Event concerns Airspace is mandatory in all Digital NOTAM scenarios and the associated Airspace must have type equal-to 'FIR'. For most scenarios, the concerned FIR can be automatically deduced by the system that supports the digital data coding, using spatial queries.

Important Note

According to OPADD 3.18.2.3 - Fictitious airspaces UUUU, ZBBB, KFDC, KICZ and KNMH are used by the originating NOF to cover/ imply the whole country. Instead of creating fictitious FIR airspace, this can be resolved by introducing the concept of 'group of FIR', coded as Airspace with type='OTHER:FIR_GROUP' and the appropriate designator ('KFDC', 'ZBBB', etc.) 

  • the association Event concerns AirportHeliport is mandatory for all Digital NOTAM scenarios that affect an airport/heliport or one of its infrastructure, services or facilities elements. For all such scenarios, the concerned airport/heliport can be automatically deduced by the system that supports the digital data coding, using feature associations. In addition, the data originator could explicitly identify one or more airports that might be operationally impacted and for which this association also needs to be coded.

For example:

  • in the RWY.CLS scenario the FIR and the airport/heliport concerned can be fully automatically be derived from the geographical location of the airport. 
  • in the SAA.NEW scenario, if the airspace reservation/restriction has an operational impact on some specific airports or on neighboring FIR, then all these additional Event - Airspace/AirportHeliport associations should be coded explicitly. 

For each scenario, an explicit statement is inserted in the coding rules indicating what needs to be coded in the associations between Event and Airspace and eventually AirportHeliport.

  • No labels