Application of the Aeronautical Information Exchange Model: The Ohrid Area Case ()
1. Introduction
According to the International Civil Aviation Organization (ICAO), Annex 15, the object of the Aeronautical Information Services (AIS) is to ensure the flow of aeronautical data and aeronautical information necessary for global Air Traffic Management (ATM) system safety, regularity, economy and efficiency in an environmentally sustainable manner [1]. For decades, aeronautical information was disseminated through products, including Aeronautical Information Publications (AIPs), AIP Amendments, AIP Supplements, charts, and Notices to Airmen (NOTAMs), which supported the operational requirements of the aviation community in a paper-based environment. The role and importance of aeronautical data and aeronautical information changed significantly with the implementation of area navigation (RNAV), performance-based navigation (PBN), airborne computer-based navigation systems, performance-based communication (PBC), performance-based surveillance (PBS), data link systems and satellite voice communications (SATVOICE). Corrupt, erroneous, late or missing aeronautical data and aeronautical information can potentially affect the safety of air navigation [1]. With the growing demand for real-time, accurate, and interoperable aeronautical data, the limitations of the traditional AIS approach have become evident. Aeronautical information is continuously evolving, encompassing updates to airspace structures, flight routes, navigation aids, and runway or taxiway configurations. To ensure both operational efficiency and safety, it is essential that all stakeholders have access to accurate data.
The objective of AIS can be effectively achieved by transitioning to a more digital environment , as demonstrated by the implementation of the European Aeronautical Information Services Database (EAD). In response to evolving operational and data requirements, the concept of Aeronautical Information Management (AIM) has emerged. AIM represents a shift toward a digital, data-centric approach, emphasizing the management of quality-assured data rather than the production of static documents. This modern concept enables aeronautical information to flow seamlessly between stakeholders, enhancing safety, efficiency, and coordination within increasingly complex airspace systems. The EAD system, as the world’s largest Aeronautical Information System, serves as a centralized reference database of quality-assured aeronautical information and a fully integrated, state-of-the-art AIS solution [2]. At its core lies the Aeronautical Information Exchange Model (AIXM), designed to facilitate the management of AIS data in digital format [1] [3] [4].
Conventional navigation is based on ground-referenced infrastructure, primarily VORs and NDBs, which constrain aircraft to fixed airways. The system lacks the flexibility required for trajectory-based operations, does not support dynamic airspace usage, and results in longer routings with higher fuel consumption. To address the inefficiencies of conventional routing, the aviation industry has adopted PBN, a modern operational framework that relies on digital data infrastructures such as AIXM and EAD. PBN enables aircraft to follow flexible, performance-driven trajectories based on onboard navigation capabilities, rather than fixed ground-based aids. By enabling real-time data exchange and automation, PBN significantly improves airspace capacity, safety, and operational efficiency.
The delegated portion of Albanian airspace, designated as the Ohrid Area, has an essential operational function in supporting safe and continuous Instrument Approach Procedures (IAP) for Ohrid Airport. In the absence of such coordination, flight operations at the airport would be subject to procedural constraints and potential safety limitations. From a data exchange perspective, accurate modeling of this delegated airspace is operationally significant, as it guarantees consistent representation of service responsibilities within the EAD and ensures interoperability between Albanian and North Macedonian systems.
2. Methodology
In brief, the study was conducted as follows: (1) the data collection phase involved acquiring validated source data, including defined airspace boundaries and operational constraints, from authorized sources; (2) during the modeling phase, the data was structured using the AIXM 5.1 format, specifically applying BASELINE Time Slices, which describe the feature’s full state, the complete set of its properties, as a result of a permanent change, and TEMPDELTA Time Slices, which represent the overlay of a feature’s state during a temporary event; (3) the dataset was validated through EAD’s Static Data Operations platform, where schema compliance and logical consistency were verified; (4) the data was encoded in machine-readable XML format, ensuring compatibility with downstream systems; (5) the dataset was published in alignment with the AIRAC cycle, making it operationally usable and queryable within the EAD system. Further details are provided in each corresponding section below.
3. Aeronautical Information Exchange Model
The AIXM, developed by EUROCONTROL and the FAA, is a standardized XML-based schema for the structured exchange, validation, and storage of aeronautical data. Within this architecture, the EAD, fully AIXM-compliant, functions as a centralized repository where data is ingested, validated, and maintained using the SDO/SDD [5].
Figure 1 presents the relationship between the AIXM and aeronautical information products, emphasizing its role in the structured exchange and distribution of aeronautical data. Inputs may be entered via system interfaces, while validated outputs support downstream applications such as eAIP publication, NOTAM issuance, aeronautical charting and system-to-system data integration. This centralized model ensures data consistency, eliminates redundancy and supports interoperability across the ATM network.
Figure 1. Relation between AIXM and aeronautical information products.
It is based on technologies such as:
XML (Extensible Markup Language) for structure;
UML (Unified Modeling Language) for conceptual modeling;
GML (Geography Markup Language) for geospatial encoding;
ISO standards for metadata and interoperability [6].
AIXM represents both static elements, such as permanent airspace structures and dynamic data, including temporary activity areas and time-dependent changes.
4. Evolution of AIXM Implementations
The origins of the draft AIXM date back to the 90s of the last century and the model’s improvement continues [7]. Figure 2 provides a comprehensive overview that integrates AIXM 3.3, 4.5, and 5.1, highlighting their differences and illustrating the evolution of each version.
Figure 2. Progression of AIXM Implementations.
AIXM 3.3 was foundational, but constrained: it supported only small datasets, lacked geospatial capabilities, and offered minimal validation or system integration. Version 4.5 introduced improved structure and data constraints, enhancing consistency. However, it remained static, with limited metadata support and only partial interoperability. Temporality was still modeled externally as a message attribute rather than embedded in the data model. AIXM 5.1 represents a significant advancement. Fully GML-based, it supports both static and dynamic datasets, real-time updates, including Digital NOTAM reports, and models temporality as an intrinsic property of each feature via Time Slices such as BASELINE and TEMPDELTA. It is fully scalable and interoperable and it enables direct integration with System-Wide Information Management (SWIM) environments. This evolution positions AIXM 5.1 as the technical backbone of digital Aeronautical Information Management, facilitating the structured, quality-assured and temporally-aware exchange of aeronautical data across globally interoperable airspace systems.
5. Typical Implementation of the AIXM Model
5.1. AIXM UML Airspace Feature Diagram
According to ICAO Annex 11, ATS airspaces are airspaces of defined dimensions, alphabetically designated, within which specific types of flights may operate and for which air traffic services and rules of operation are specified [8]. The class diagram in Figure 3 shows the properties of the Airspace feature, its geometry, and its potential dependency on the geometry of other airspaces [5].
The main class Airspace contains attributes that describe its high-level characteristics, such as name, designator, type, and other identifying properties. The Airspace feature represents the conceptual or operational entity, for example, a Flight Information Region (FIR), Terminal Control Area (TMA), or Restricted Area. It carries the identification, classification, and usage information related to that portion of airspace. Its spatial extent is described through one or more AirspaceVolume components. Each AirspaceVolume defines the three-dimensional portion of space, with its vertical limits and horizontal boundaries, that belongs to the airspace. Most airspaces consist of a single AirspaceVolume, but when multiple volumes are used, they can be combined or related through the AirspaceGeometryComponent class to form more complex geometries [5] [9].
An individual AirspaceVolume defines vertical limits and a horizontal projection of type Surface, as shown in Figure 4. The term “horizontal projection” in this context refers to the two-dimensional plan view footprint of the airspace on the Earth’s surface. This surface defines the lateral boundaries of the airspace and is encoded in GML to ensure spatial interoperability. The model allows both the preservation of this original information and the provision of the resulting horizontal projection as a derived Surface.
Occasionally, the shape of one airspace is defined in relation to another. For example, a smaller area might share the same boundaries as a larger airspace, or it might cover only part of it. In AIXM 5, this relationship is described using the dependsOn association. The dependsOn link indicates that the geometry of one airspace is based on another’s. This association is managed through the AirspaceVolumeDependency class, which defines how the link operates. There are two possible cases:
The airspace uses the entire 3D shape of another airspace.
It uses only the horizontal outline, the 2D footprint.
This dependency applies only to the geometry and does not imply that the airspace also inherits other information, such as its classification, activation schedule, or services. The purpose is to avoid redrawing or redefining the same geometry twice while keeping all airspace data consistent and connected.
The AIXM 5 Airspace Conceptual Model is a generic model designed to describe various types of airspaces, including ICAO regions, areas, zones, sectors, and other airspace partitions. It models the geometry of airspace structures such as:
Figure 3. Logical view of AIXM UML airspace feature diagram.
Figure 4. Airspace representation in plan and profile views.
Flight Information Regions (FIRs);
Upper Information Regions (UIRs);
Terminal Control Areas (TMAs);
Restricted, Prohibited, Danger areas, and other [5].
In addition to its geometry, the AIXM 5 model defines several key attributes that describe an airspace and its operational characteristics. Figure 5 shows how the airspace feature data elements of the Ohrid Area are represented in the AIP [10].
Figure 5. Publication of the airspace in the AIP based on AIXM data.
These include:
Type: The general category of the airspace, such as FIR or TMA.
Designator: A unique identifier assigned to the airspace, for example LAAA for Tirana FIR or LAAADLG for the Ohrid Area.
Class: The airspace classification, encoded using the AirspaceLayerClass object.
Activation times: Periods during which the airspace is active.
Services provided: Air traffic or other services available within the airspace.
Other operational characteristics: Additional information relevant to the airspace’s use or restrictions.
The geographical and geometrical extent of an Airspace is modeled using the AirspaceVolume class. In AIXM 5, there are two main methods for describing the geometry of each airspace volume:
1. Explicit geometry definition—by providing a horizontal projection (typically a surface or border) along with vertical limits. This represents an airspace defined directly by its borders.
2. Derived geometry definition—by specifying composition rules, where the geometry is defined as a series of operations (e.g., addition, subtraction, or intersection) based on the geometries of other airspaces.
The AirspaceVolume class is associated with a Surface geometry, which is coded in GML. The Lateral limits can be defined as simple geodesic lines, references to state boundaries, or arcs defined by center points. The vertical limits of an airspace, such as the upper limit, lower limit, and any minimum or maximum limits, are defined using the corresponding attributes of the AirspaceVolume class [5].
The class of an airspace, is encoded using the AirspaceLayerClass object. Figure 6 shows the airspace structure of Albania, including the new ATS zone, the Ohrid Area, which is designated as Class D airspace. An Airspace class may be defined for the whole airspace or layers of the airspace [5] [9].
Figure 6. Airspace classification.
5.2. Encoding and XML Implementation of Ohrid Airspace Data
The AIXM is codified as a series of XML schemas. There is a direct link between the AIXM Conceptual Model and the AIXM XML Schema. XML has unique advantages in various computer languages. It is a markup language promoted by W3C (World Wide Web Consortium). It can be applied to different underlying modules of development platforms to facilitate the development and transmission of subsequent data. The core purpose of building AIXM is to achieve data sharing and exchange. Consistent XML Schema requirement rules are applied across different fields. Only data structures constructed under the same XML Schema model can be identified and applied to each other on different platforms and departments. AIXM is an XML Schema for encoding aeronautical data, reflecting the logical relationships between data elements. Implementing AIXM requires conversion to XML Schema based on the Aeronautical Information Conceptual Model (AICM) [11]. During the implementation of AIXM for the Ohrid Area, some technical challenges were encountered. There are relatively few tools that provide full support for AIXM, and while existing validation tools, such as Eurocontrol’s AIXM Validator, effectively verify structural compliance with the schema, their capability to assess semantic or business-rule consistency remains limited.
In this study, XML is used to encode airspace data according to the AIXM specification, transforming UML-defined aeronautical structures into a machine-readable, schema-compliant format, as presented in Figure 7. The Ohrid Area is encoded as an AIXM feature, referencing the official AIXM schema to ensure full compliance. Key metadata fields include the airspace type (SECTOR), designator (LAAAADLG), name (OHRID AREA), control type (CIVIL), and classification (Class D). The feature is linked to elements defining vertical limits and reference systems (e.g., SFC and MSL), with the geometry encoded using the Geography Markup Language (GML). All elements are uniquely identified using UUIDs, ensuring traceability, version control, and integration within EAD.
Figure 7. Encoded AIXM 5.1 dataset for the Ohrid Area.
This encoding exemplifies AIXM’s role in enabling structured, interoperable aeronautical data publication aligned with AIM standards. This example demonstrates AIXM’s capability to convert conceptual aeronautical information into validated XML, suitable for storage, querying, and dissemination aligned with global Aeronautical Information Management standards. Figure 8 and Figure 9 illustrate the operational visualization of the Ohrid Dataset within the Luciad AIXM 5 Viewer. The Ohrid Area is presented as a digitally instantiated 2D/3D airspace object, incorporating metadata and geospatial geometry.
Figure 8. 2D visualization of the Ohrid Area dataset in the Luciad AIXM 5 Viewer.
Figure 9. 3D visualization of the Ohrid Area dataset in the Luciad AIXM 5 viewer.
5.3. Data Validation and Integration with EAD
After encoding the Ohrid Area in AIXM XML, the dataset underwent processing within the EAD system to ensure compliance with schema rules, AIRAC timelines, and spatial consistency. The EAD applications involved in this process include Workflow Management (WFM), Static Data Operations (SDO), AIP Software, and Chart Software [12].
The Static Data Operations (SDO) service, which forms part of the central aeronautical data repository within the EAD, facilitates seamless access to, updating, consultation, and downloading of stored data in multiple formats by authorized data providers. The Ohrid Area is defined by six coordinates and a segment along the North Macedonian-Albanian border, as illustrated in Figure 10 [2] [10]. The planimetric metadata coordinates are expressed in a geographic coordinate system (latitude and longitude) using decimal degrees. According to ICAO Annex 15, all “published aeronautical geographical coordinates (indicating latitude and longitude) shall be expressed in terms of the WGS-84 geodetic reference datum” [1] [12] [13].
The Graphical Validation application facilitates the validation of complex static data changes by visualizing and checking information prior to publication. It functions as a logical extension of the SDO, offering a graphical representation of both pending and committed data within the database. Specifically, users can visually compare and edit pending SDO data against previously committed records stored in the system [2] [12].
The EAD software supports the storage and dissemination of data in the electronic AIP (eAIP) format, in full compliance with EUROCONTROL’s eAIP specifications. These specifications conform to ICAO requirements for AIP content and structure, as outlined in ICAO Annex 15 and PANS-AIM (ICAO Doc 10066) [1] [2] [14].
Figure 10. Static data maintenance and validation of the Ohrid Area within the European AIS Database (EAD).
5.4. Implementation Outcomes
The Ohrid Area dataset was modeled and validated in AIXM, capturing its structural, geometric, and temporal properties in a standards-compliant digital format. It has been integrated into the EAD system, published in accordance with the AIRAC cycle, as illustrated in Figure 11, and is operationally accessible via eAIP, NOTAM, and flight planning systems [10]. This implementation reflects compliance with current AIM requirements and readiness for SWIM-enabled information exchange.
The definition of the Ohrid Area addressed critical operational gaps in a previously unstructured airspace lacking formal ATS and digital visibility. It enhances safety, improves access to Ohrid Airport, and supports cross-border coordination. Through AIXM encoding and EAD publication, the dataset is digitally integrated into the European AIM infrastructure, ensuring data integrity, interoperability, and automation of services such as flight planning, NOTAM issuance, and alerting. It also enables more effective seasonal traffic management and balanced ATC workload distribution. Together, these factors underscore the need to align technical modernization with operational strategy.
Figure 11. Publication of the Ohrid Area.
6. Next Step: SWIM (System-Wide Information Management)
System-Wide Information Management (SWIM) represents the next step in the digital transformation of aviation data and has been identified as a key enabler for the evolution of future ATM systems. SWIM transitions the ATM information architecture from traditional point-to-point data exchanges toward a system-wide, service-oriented interoperability framework. Its technical infrastructure enables the implementation of standardized interfaces between systems, supporting secure, high-performance, and reliable information exchange [15]-[17].
7. Conclusion
The establishment of the Ohrid Area provides safe and efficient instrument approach procedures for an airport located near an international border, thereby avoiding complex or steep approach paths. It ensures continuity of service, enhances safety and situational awareness for pilots and air traffic controllers, reduces workload, and enables more efficient traffic management. Airline operators benefit from cost savings, reduced delays, and more predictable operations. The AIXM-coded airspace facilitates a standardized digital representation of the Ohrid Area, supporting procedure validation, accurate data exchange, and consistent management within ATM systems. Overall, the airspace structure contributes to increased capacity, regional harmonization, and reduced environmental impact through optimized routing. Looking ahead, it is anticipated that aeronautical data will be exchanged throughout the entire ATM community via SWIM, a network-oriented method for data sharing.