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.
Airport/Heliport availability
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).
Info
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.
The code list CodeUsageLimitationBaseType provides the following values for the (UsageCondition.)type:
Value | Description |
---|---|
'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' | Other. Note Other should not be used! |
Info
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:
Value | Description |
---|---|
'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' | Other Note 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.
AIP context
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.
The example below shows an encoding of IFR/VFR without any additional conditions.
Open Question FlightCharacteristic.type
1.) If the AIP indicates only "IFR" for an airport, should this be assumed to implicitly mean that VFR is forbidden? Has a 'FORBID' to be coded for VFR, or is the 'PERMIT' 'IFR' sufficient? same for the other way round if only VFR, will IFR not be coded or is FORBID needed?
2. ) How to deal with AD Opening hours and VFR (i.e. opening hours are beyond VMC time window?) +weather also to be coded?
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'
Info
ICAO Annex 2defines an additional category, called "special VFR" which is permitted in low visibility. This should be coded as type equal-to 'OTHER:SPECIAL_VFR' .
Coding Rules for Type of Traffic Permitted - IFR/VFR
Identifier | Data Encoding Rules | Justification | Data Verification Rule (UID) | Remarks |
---|---|---|---|---|
AHP-201 | If a related FlightCharacteristic.type equal-to 'VFR' or 'ALL', then the AirportHeliport.landingDirectionIndicator attribute of the related aerodrome/heliport is mandatory. | EAD | TBD | Open Question LDI any real need for keep this rule? |
Coding Examples
Coding examples can be found in the Sample AIP Data Set (DONLON):
No. | Description | XPath Expression |
---|---|---|
AHP-EX-01 | Type of Traffic Permitted - IFR/VFR | //aixm:AirportHeliportTimeSlice[@gml:id='AHP_EADD']/aixm:availability |
AHP-EX-02 | Type of Traffic Permitted - VFR | //aixm:AirportHeliportTimeSlice[@gml:id='AHP_EADH']/aixm:availability |