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:

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:

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] .

These include:

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] .

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.

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.

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] .

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.