Model decoder usage

The TLcdAIXMModelDecoder is an implementation of ILcdModelDecoder for decoding AIXM data. It offers support for handling AIXM-Snapshot and AIXM-Update data.

Decoding AIXM-Snapshot data

To check whether a given dataset represents AIXM-Snapshot data, the method canDecodeSource(String) can be used. The check includes a test to see whether the supplied data file represents XML data, and whether the root element corresponds to the AIXM-Snapshot root element defined by the AIXM specification. It does not validate the data using the AIXM XML Schema.

An AIXM-Snapshot file can be decoded by passing it to the decode(String) method in the decoder. The TLcdAIXMModelDecoder doesn’t decode the data itself: for each AIXM domain object, like an aerodrome or an airspace, the decoder delegates to an ILcdAIXMHandler that knows how to decode the domain object. These handlers must be registered on the decoder to decode the data.

By default, all handlers are registered. Once you add your own handler, the default handlers will not be used.

Before decoding any data, one or more handlers must therefore be registered.

The following ILcdAIXMHandler implementations are provided in the com.luciad.format.aixm.decoder package:

Table 1. Default ILcdAIXMHandler implementations.

Name

Decoded objects

TLcdAIXMAerodromeHandler

Airports and Heliports

TLcdAIXMAirspaceHandler

Airspace Borders, Corridors, and Associations

TLcdAIXMVORHandler

VOR Navaids

TLcdAIXMDMEHandler

DME Navaids

TLcdAIXMTACANHandler

TACAN Navaids

TLcdAIXMNDBHandler

NDB Navaids

TLcdAIXMILSHandler

ILS (Instrument Landing System) with Localizer/Glide Slope

TLcdAIXMMarkerHandler

Markers (part of an ILS)

TLcdAIXMDesignatedPointHandler

Designated Points (waypoints)

TLcdAIXMObstacleHandler

Obstacles

TLcdAIXMRouteHandler

Routes

TLcdAIXMRunwayHandler

Runways and Runway Directions

TLcdAIXMGeoborderHandler

Geographical Borders

TLcdAIXMProcedureHandler

Procedures (SID, STAR, IAP)

Each ILcdAIXMHandler implementation decodes its domain objects into a separate ILcdModel with a specific model descriptor. If more than one handler is registered on the decoder, the returned model is a model list that combines the individual models of the handlers. If desired, the individual model of each handler can be retrieved from the model list.

Decoding AIXM-Update data

Updating a decoded AIXM model with AIXM-Update data an is very similar to the process of decoding AIXM-Snapshot data. To check whether a given dataset represents AIXM-Update data, the method canUpdateFromSource(String) can be used. Like canDecodeSource(String), the check includes a test to see whether the supplied data file represents XML data, and whether the root element corresponds to the AIXM-Update root element defined by the AIXM specification. It does not validate the data using the AIXM XML Schema.

To update an AIXM model with AIXM-Update data, both the model and the AIXM-Update file need to be passed to the update(String, ILcdModel) method of the decoder. The ILcdModel argument can be a single model or a model list (TLcdModelList). The decoder will automatically link models with different AIXM data contained in one model list with their corresponding ILcdAIXMHandler.

To get notified of which objects in the model or model list are updated during the update process, you can register an ILcdModelListener on the ILcdModel, before invoking updateSFCT(String, ILcdModel). Through a set of TLcdModelChangedEvent objects, implementations are notified of the objects that are updated, removed or added.

Model decoder configuration parameters

Filtering domain objects

AIXM data can be filtered in two different ways:

  • by specifying decoding bounds,

  • by specifying a model filter.

Decoding bounds

Decoding bounds can be used to limit the spatial extent of the model to be decoded. When using decoding bounds, objects are only decoded if their bounds interact with the specified bounds. This can result in a performance improvement, as well as lower memory usage. They can be specified either by setting bounds on the decoder or on a handler, via the setBoundsToFilterOn method. If set on the decoder, all registered handlers are configured with the decoding bounds. Handlers that are registered afterwards will not take into account decoding bounds of the decoder. Each handler can also be configured with separate decoding bounds.

Model filter

A model filter can be used to filter objects based upon their properties or attributes. For example, a filter can be defined that only accepts Terminal Control Area (TMA) airspaces, DME navaids that use a certain frequency band, runways that have a minimum length, etc. Because the bounds of an object is also one of its properties, a decoding bounds filter can be seen as a special case of a model filter.

A model filter must be defined by implementing the interface ILcdAIXMModelFilter , an extension of the general LuciadLightspeed filter ILcdFilter . It can be set on a handler, to allow only objects in the resulting model that passes through the filter. An example implementation that filters objects based upon an attribute is available in the sample class samples.decoder.aixm.AIXMModelFeatureFilter.

Filtering attributes

Each ILcdAIXMHandler implementation provided in the AIXM API maintains a default list of attributes that are decoded for each domain object. This list is documented in the reference documentation, and can also be retrieved programmatically as a String array. It is also possible to change the list of attributes to be decoded. For example, the attributes decoded for each DME domain object can be retrieved through the method getDMEFeatureNamesToBeDecoded() in TLcdAIXMDMEHandler . By calling the method setDMEFeatureNamesToBeDecoded(String[]), the list of attributes to be decoded can be configured.