Message organization

Separating features

Depending on the contents of a data source, decoded data can hold a variety of AIXM 5.1 features. For example, a single file representing an AIXM 5.1 Abstract Message can contain both navaids, airports, taxiways, runways, or any other feature type that occurs in AIXM 5.1.

The API offers functionality to split a decoded model into multiple models that each contain features that belong to a single feature type. Through the method separateFeatureTypes(TLcdAIXM51AbstractAIXMMessage) in TLcdAIXM51MessageUtil, an object representing an Abstract Message can be split up into models of the same feature type. Each generated model has a TLcdAIXM51ModelDescriptor that gives access to the feature type stored in the model.

Merging unique features

In some data sources, multiple time slices belonging to one feature are not necessarily stored in the same feature definition. For example, a data source can contain two feature definitions that refer to the same feature entity, specifying two different time slice s:


The decoder generates a model that is an exact mapping of the source data in XML, so this is also reflected in the decoded data. Through the method mergeUniqueFeatures(TLcdAIXM51AbstractAIXMMessage) in TLcdAIXM51MessageUtil, these features are merged into the same object, resulting in a set of unique features that each contain all the associated time slice s. The merge operation uses the gml:identifier element to identify feature entities, as this element needs to be unique throughout an AIXM 5.1 dataset.

Temporal support

Sorting time slices

An AIXM 5.1 feature can contain a variety of time slice s, with different interpretations, sequence numbers, and correction numbers. Through the method sortMessage(TLcdAIXM51AbstractAIXMMessage) an ordering can be applied onto an Abstract Message that orders the time slices within a feature according to the following rules:

  • Baseline < Permdelta < Tempdelta

  • Sequence numbers for time slices with the same interpretation are ordered using ≤

  • Correction numbers for time slices with the same interpretation and sequence number are ordered using ≤

The AIXM 5.1 specification does not allow time slices within one feature to be equal with respect to these rules.

Generating a snapshot

As discussed in AIXM5 domain object modeling, various time slice interpretations are used to specify the different states of aeronautical features. To describe the state of a feature at one time instant, a snapshot time slice is used. Through the method generateSnapshot(TLcdAIXM51AbstractAIXMMessage, Date), a snapshot can be generated for a given message and time instant. The resulting message contains exactly one time slice for each feature. This time slice is generated by merging the time slices from the original feature into a snapshot time slice, which is valid at the given time instant. The merging of time slices into a snapshot follows the rules specified in the AIXM 5.1 specification:

  • Each time slice will have its interpretation set to SNAPSHOT.

  • If a feature does not contain time slices that are valid at the given date, it is omitted from the resulting message.

Mapping of AIXM 5.1 types to Luciad shape types


Some AIXM 5.1 types implement existing LuciadLightspeed interfaces. This enables the developer to use existing LuciadLightspeed painters to visualize and manipulate these types.

Table 1. Mapping between AIXM 5.1 types and LuciadLightspeed classes/interfaces

AIXM 5.1 types

Mapping in LuciadLightspeed





















Figure 1, “Overview of mapping between LuciadLightspeed interfaces and some AIXM 5.1 types” gives a conceptual overview of the base classes in the domain model, and the mapping between some of the AIXM 5.1 types and LuciadLightspeed interfaces.

Figure 1. Overview of mapping between LuciadLightspeed interfaces and some AIXM 5.1 types

Messages, features, and time slices

The AIXM 5.1 schema consists of three basic building blocks: messages, features, and time slices. A message can contain one or more features, where each feature corresponds to a uniquely defined entity, like an airport. Each feature consists of a set of time slices, and a time slice contains the actual properties of that feature, together with information about the validity of those properties over time.

AIXM 5.1 messages

Decoding an AIXM 5.1 XML file containing a Basic Message or Digital NOTAM results in an object which extends the TLcdAIXM51AbstractAIXMMessage type. This type implements the ILcd2DBoundsIndexedModel interface and the ILcdIntegerIndexedModel interface. The elements of the ILcdModel are the AIXM 5.1 features contained in the XML file. Any type which has AIXMAbstractMessage as its base type can be decoded.

AIXM 5.1 features

Every AIXM 5.1 feature that has AbstractAIXMFeatureType as its base type implements ILcdShapeList . The shapes in this list are the time slices that will be visualized. A filter determines which time slices are added to the list. By default, a filter is set which allows only BASELINE and SNAPSHOT time slices.

You can request a List of all the time slices in the feature through the getTimeSlices() method in TLcdAIXM51AbstractAIXMFeature . This list can be used to add time slices to and remove time slices from the feature. The shapes returned by the ILcdShapeList methods will be updated consistently.

The base class for all abstract AIXM 5.1 feature types is TLcdAIXM51AbstractAIXMFeature . This class provides a basic ILcdShapeList implementation and some useful methods.

AIXM 5.1 time slices

Every time slice type also implements ILcdShapeList . The default implementation recursively searches through all properties of the time slice for all objects implementing ILcdShape and adds them to the list of shapes. This behavior can be changed by creating a custom implementation. In general, the best approach is to only add shapes that actually need to be painted to the list. This makes the implementation of the painters more straightforward.

The base class for all time slice types is TLcdAIXM51AbstractAIXMTimeSlice .

Specialized time slice implementations


Airspaces can contain a single airspace volume, or they can be built up from other aggregated airspaces. This is reflected in the shapes returned by the ILcdShapeList of airspace time slices. When an airspace contains a single airspace volume, the ILcdShapeList contains an ILcdExtrudedShape which represents this volume. Aggregated airspaces contain an ILcdComplexPolygon , which is the result of merging the individual airspaces into a single shape.

Special geometry types

Elevated geometry types

Although the elevated geometry types ElevatedCurveType and ElevatedSurfaceType have a height associated with them, this is not reflected in the LuciadLightspeed interfaces. This means that they behave exactly the same as their non-elevated counterparts from which they are derived. Custom 3D painter implementations are available which take the elevation into account.

The ElevatedPointType does provide a correct Z value, but it cannot be edited with the methods from the ILcd3DEditablePoint interface.


A vertical structure part is a shape which has a given height, and a base shape which is either an AIXM 5.1 elevated point, an AIXM 5.1 elevated curve, or an AIXM 5.1 elevated surface. This is mapped to an ILcdExtrudedShape with the following properties:

  • the base shape corresponds to the base shape of the part

  • the minimum z corresponds to the elevation of the elevated base shape. This elevation is converted to meters, and added to the geoidal undulation if available.

  • the maximum z is computed by adding the height of the part (converted into meters) to the minimum z


An airspace volume is a volume modeled by a lower limit, an upper limit, and a horizontal projection surface. This volume is mapped to an ILcdExtrudedShape with a minimum z corresponding to the lower limit, converted to meters, and a maximum z corresponding to the upper limit, converted to meters.

The base shape is either an object of type ILcd2DEditableGeoBuffer with a base shape set to the center line of the airspace volume, or the horizontal projection of the airspace volume, which is an AIXM 5.1 surface.

Using XPath expressions

XPath expressions can be used to easily retrieve data from the domain model. They are easy to use because they require very little knowledge about the Java domain model, and usually result in shorter code than explicitly traversing the domain model. The only downside is that they can take a little more time to evaluate, but the actual impact of this difference depends on the use case.

The standard class javax.xml.xpath.XPathExpression should be used to create and evaluate an expression. This gives you the flexibility to use your own custom functions and namespaces. More information can be found in the javadoc of this class.

The AIXM 5.1 component also provides a shortcut to create an XPath expression from a String, the TLcdAIXM51XPathFactory . This factory supports a predefined set of namespaces and custom functions which are documented in the javadoc.

The XPath expressions that can be used are limited to the ones supported by the Java SDK. This means that not all valid XPath expressions will give the desired result. In such a case, you can usually work around this by writing a custom XPath function.

AIXM 5.1 uses XLinks extensively to create associations between different features. These XLinks can link to features within the same AIXM 5.1 message, within a different AIXM 5.1 message, or even located on a remote server. LuciadLightspeed provides out-of-the-box resolving of XLinks within the same AIXM 5.1 message, and an API to customize this process and resolve any possible XLink .

In LuciadLightspeed, an XLink is modeled by the domain object TLcdXLinkSimpleLink. The interpretation of the XLink is handled by the interface ILcdXLinkExpressionFactory. While an AIXM 5.1 message is being decoded, ILcdXLinkExpression objects are created for each TLcdXLinkSimpleLink encountered. These objects have a property actuate, which indicates when the expression should be resolved:

  • AfterDecoding, indicating that the expression should be resolved immediately after decoding

  • Manual, indicating that the expression should be resolved only when the application explicitly invokes resolve

  • OnRequest, indicating that the expression should be resolved when its value is requested for the first time

By default, the AIXM 5.1 decoder creates ILcdXLinkExpression objects with actuate value AfterDecoding. After the message is decoded, all these objects are evaluated and the resolved objects are stored as linked objects in the ILcdDataObject that contained the XLink . The linked object is stored in a property with name linkedObject.

For actuate values Manual and OnRequest, ILcdXLinkExpression objects are not evaluated but stored in the TLcdXLinkSimpleLink object. This enables applications to resolve the XLink manually afterwards.

You can customize the XLink interpretation process by supplying a custom ILcdXLinkExpressionFactory implementation when creating a TLcdAIXM51ModelDecoder. For an example implementation of ILcdXLinkExpressionFactory, see How to link AIXM 5.1 features stored in separate files.

Dealing with AIXM extensions

The AIXM 5.1 model is an extensible model that allows third parties to expand the model and to add new features and additional properties for a local application. The LuciadLightspeed AIXM 5.1 component provides support for handling AIXM extension schemas.

When the AIXM 5.1 model decoder encounters a schema that it does not yet know, it will map the schema to a TLcdDataModel. The decoder will then configure itself with that data model such that it can properly decode all of the extension elements defined in the schema. This all happens automatically. One issue that occurs commonly when dealing with such extensions is that the decoder is not able to locate the XML schemas for the extensions. In that case, the decoder has not enough information and will not be able to parse the document. You can solve this by setting an entity resolver on the decoder’s mapping that knows where to find the schemas.

If you know up front which AIXM 5.1 extensions are needed, you can better create the data models for the extensions yourself. This makes sure that not every decoder has to create them over and over. In addition, given the data models, you can easily create new instances of the types defined by the extension. The following snippet shows this in code.

Program: Dealing with AIXM extensions
TLcdXMLDataModelBuilder builder = new TLcdXMLDataModelBuilder( TLcdAIXM51DataTypes.getDataModel() );
TLcdDataModel extension = builder.createDataModel( "", "aixm-extension.xsd" );
// create a new decoder configured with the extension
TLcdAIXM51ModelDecoder decoder = new TLcdAIXM51ModelDecoder( extension );
// creating new instances of the extension types
TLcdAIXM51AbstractAIXMFeature f = (TLcdAIXM51AbstractAIXMFeature) extension.getDataType( "MyFeatureType" ).newInstance();

You can find a more detailed explanation on data models and the binding of XML schema to a data model in Data formats: XML.

Limitations of the current implementation

Only a limited set of features have specific icons or line and fill styles. These feature types will be shown with a default fall-back style. Nevertheless, it is still possible to create your own custom style using the SLD styling mechanism. Predefined styles will be added for more feature types as data for these types becomes available.