Airspace Data AIXM Mapping#

Required roles: AIS Navigation Data via Cloud — Roles
Base endpoint: none
Reference documents: AIXM 5.2 schema set (aixm.aero) · RFC 7946 The GeoJSON Format
Attribution: show ibonav.aero wherever this data is displayed
Data sources: none
Last updated: 18 OCT 2026

How the airspace data in AIXM maps to the columns of the Airspace GeoPackage. Every AIXM property of Airspace has a column or a place in a JSON column; a column can be empty when no source provides that property.

For the extension elements (ibosoftais:*) see AIXM Schema Extension; for coding rules (provenance, geometry) see Data Coding Policies. The naming rules and the common column families are the same as in the ATS Data AIXM Mapping.

Layer#

The layer also has id (INTEGER primary key) and geom. Each airspace is one row: an airspace with several classes or several geometry components is not split into rows.

Naming rules#

JSON keeps the whole AIXM subtree: an element with xlink:href becomes {"href": "<uuid>"}, a value with a unit becomes {"value": …, "uom": …}; only technical attributes such as gml:id are left out.

Columns#

Airspace#

class and activation are kept as full JSON arrays and are not reduced to single columns: an airspace can have several classes (each for its own levels) and several activations.

Example airspaces_class of an FIR with a class C layer:

[{"classification": "C",
  "associatedLevels": {"AirspaceLayer": {
      "upperLimit": {"uom": "FL", "value": "660"}, "upperLimitReference": "STD",
      "lowerLimit": {"uom": "FL", "value": "305"}, "lowerLimitReference": "STD"}}}]

Annotation columns and separators work as in the ATS Data AIXM Mapping › Annotation.

Geometry component and volume#

airspaces_geometryComponent holds all components as a JSON array: operation, operationSequence, annotation and theAirspaceVolume with all its fields. The geometries are not repeated in the JSON: horizontalProjection is in geom, centreline in airspaces_centreline.

The volume fields of the BASE component are also in single columns (the fields of the other components are only in the JSON):

Vertical limits are TEXT. An AIXM limit is a number or a text value such as UNL, GND, FLOOR or CEILING, and both occur in the data. A numeric column would turn the text values into NULL, and the reference column cannot tell UNL apart. The value is carried as written in AIXM.

Extension, provenance, identity#

Region values are as published by the source; see AIXM Schema Extension › Airspace. Provenance coding: Data Coding Policies › Provenance.

TimeSlice and feature base#

The begin of gml:validTime is unknown: the sources give the effectivity of the data set, not of each airspace. The data set effectivity is in data_effectivity.

Derived: airspaceLabeling_*#

For filters and labels. The full class information with levels is in airspaces_class. The list is not sorted by level: the level references of class bands can be mixed (FT MSL / FL) and cannot be compared without conversion.

Geometry#

geom is calculated from the geometry components:

1. Components are ordered by operationSequence.
2. The first component must be the only BASE.
3. The polygon of each component is read from horizontalProjection (PolygonPatch exterior ring and interior holes).
4. Starting from BASE, the operations are applied: UNION union, SUBTR difference, INTERS intersection.
5. The result is a MultiPolygon split at ±180° (antimeridian).
6. Ring orientation follows RFC 7946 §3.1.6: exterior counter-clockwise, holes clockwise (see Data Coding Policies › Area Geometry Coding).

A component without a polygon (only centreline/width, or contributorAirspace) cannot be calculated; no polygon is invented for it, and such an airspace is not in the layer.

Values in the data#

Indexes#

Changes from the previous airspace schema#