PANS-AIM does not require the type of traffic permitted to be part of the minimum/conditional AIP data set, but it is listed in the PANS-AIM Appendix 1 (Aeronautical Data Catalogue).
However, at least the indication if IFR and/or VFR flights are permitted at the aerodrome/heliport may be important for data provider organisations.
In order to allow the encoding of this minimal information about the traffic permitted, some general rules for the coding of airport/heliport availability are provided first.
The diagram below shows the AIXM classes, including the relevant data types and code lists, needed to encode that information.
The AirportHeliportAvailability class is used to define the operational status of the airport/heliport and any reason for caution when operating at the airport/heliport.The baseline information shall be encoded with operationalStatus equal-to 'NORMAL', meaning that the facility operates with nominal parameters. It is possible that more than one instance of AirportHeliportAvailability is necessary in case that the usage permissions/restrictions depend on a schedule. This is supported by the fact that the AirportHeliportAvailability is derived from the general PropertiesWithSchedule class.
- If there exist more than one AirportHeliportAvailability associated with the same AirportHeliport, each must have a different applicability schedule. The union of all these schedules shall not leave any gaps. If gaps exist, then the status of the airport/heliport availability at the times concerned is considered "undefined". See the AIXM Temporality Concept (versions 1.0) sections 3.4 and 3.5.
Then, each particular kind of operation (such as landing, take-off, etc.) and its associated usage permission/restriction shall be encoded as an AirportHeliportUsage with the corresponding operation and (UsageCondition.)type, associated with the appropriate AirportHeliportAvailability (including its eventual applicability schedule).
Some allowable values of the operation attribute (such as 'AIRSHOW') are not expected to occur for baseline data. They are typically used for temporary events.
AIXM 5.2 Improvements
A change proposal (AIXM-531) for the next AIXM 5.2 version has been approved by the AIXM Change Control Board, which adds additional status values to CodeStatusServiceBaseType and CodeStatusAirportBaseType.
The coding guidelines provided here are aligned with forward/backward conversion rules contained in the AIXM-531 Change Proposal.
The code list CodeUsageLimitationBaseType provides the following values for the (UsageCondition.)type:
|'PERMIT'||for operations that are explicitly permitted|
|'CONDITIONAL'||for operations that are permitted, but only when complying with additional instructions (such as a prior permission requirement). Failure to comply with the additional instructions invalidates the permission.|
|'FORBID'||for operations that are explicitly forbidden|
|'RESERV'||if the airport is exclusively reserved for certain operations (exclusive usage)|
Other should not be used!
In principle, a single AirportHeliportUsage shall be applicable for a particular flight. However, sometimes that might require encoding a more complex combination of usages. Therefore, the following interpretation rules shall be applied in case of conflicts:
- the usages of type FORBID take precedence over usages of type PERMIT or RESERVE;
- the usages of type PERMIT take precedence over the usages of type RESERVE
The ConditionCombination class has to be used in case a combination of flight characteristics and/or aircraft characteristics and/or meteorological conditions shall be defined for the airport/heliport usage.
The ConditionalCombination.logicalOperator has to be used correspondingly, e.g. equal-to 'NONE' for a single operation.
The corresponding code list CodeLogicalOperatorBaseType provides additionally the following values:
|'AND'||The result is true only when all operands are true.|
|'OR'||The result is true if any operand is true.|
|'NOT'||The result is the opposite of the operands true/false state (it applies to a single operand).|
|'NONE'||No operation (used for single conditions).|
Other should not be used!
Traffic permitted - IFR/VFR
This section indicates how to encode the minimal information considered for the AIP data set - IFR/VFR traffic permitted.
In an AIP, this information is published in
- AD 1.3 and
- AD 2.2
In order to code that VFR or IFR or both traffic is permitted, the AirportHeliportUsage.type attribute will be equal-to 'PERMIT'.
In order to code that only VFR or IFR (or both) types of traffic is(are) permitted, the AirportHeliportUsage.type attribute will be equal-to 'PERMIT'.
When IFR or VFR traffic is only allowed under certain conditions, then 'CONDITIONAL' shall be used with a Note explaining the conditions.
The AirportHeliportUsage.operation attribute will be equal-to 'ALL', except when IFR or VFR is not allowed for certain operations such as training, touch and go, etc. In that case, more than one AiportHeliportUsage have to be coded. One for each operation for which IFR or VFR traffic is allowed (e.g. one for 'LANDING' and one for 'TAKEOFF').
Finally, the FlightCharacteristic.type will be coded equal-to 'IFR', or 'VFR' or 'ALL'. The latter only in case all the availability parameters specified apply for both, IFR and VFR traffic.
AIXM 5.2 Improvements
A change proposal (AIXM-407) for the next AIXM 5.2 version has been approved by the AIXM Change Control Board, which adds a new code list value MEDEVAC to the CodeFlightStatusBaseType.
The coding guidelines provided here are aligned with forward/backward conversion rules contained in the AIXM-407 Change Proposal.
The example below shows an encoding of IFR/VFR without any additional conditions.
Below you find two examples in tabular format, one for the most simply encoding of IFR traffic permitted and a more complex one.
No limitations to the IFR operation at the airport/heliport, also VFR is permitted without limitations:
AirportHeliportAvailability AirportHeliportUsage ConditionalCombination. FlightCharacteristic operationalStatus type operation logicalOperator type 'NORMAL' 'PERMIT' 'ALL' NA 'ALL'
IFR operations neither allowed for training nor touch and go, for all other operations IFR and VFR is allowed.
AirportHeliportAvailability AirportHeliportUsage ConditionalCombination FlightCharacteristic operationalStatus type operation logicalOperator type 'NORMAL' 'PERMIT' 'LANDING' NA 'ALL' 'PERMIT' 'TAKEOFF' NA 'ALL' 'FORBID' 'TRAIN_APPROACH' NA 'IFR' 'FORBID' 'TOUCHGO' NA 'IFR'
ICAO Annex 2,defines an additional category, called "special VFR" which is permitted in low visibility. This should be coded as type equal-to 'OTHER:SPECIAL_VFR' .
Coding examples can be found in the AIP Data Set - Specimen (DONLON):
Type of Traffic Permitted - IFR/VFR
|AHP-EX-02||Type of Traffic Permitted - VFR||//aixm:AirportHeliportTimeSlice[@gml:id='AHP_EADH']/aixm:availability|