Usage of the model decoders

The TLcdARINCModelDecoder is an implementation of ILcdModelDecoder for decoding ARINC data. To check whether a given dataset represents ARINC data, the method canDecodeSource(String) can be used. It performs a quick analysis of the data to see whether it represents ARINC data.

TLcdARINCModelDecoder decodes the complete dataset. To have more control over what is decoder, use TLcdARINCDecoder .

The TLcdARINCDecoder doesn’t decode the data itself: for each ARINC domain object, like an aerodrome or an airspace, the decoder delegates to an ILcdARINCHandler that knows how to decode the domain object. These handlers must be registered on the decoder to decode the data. By default, no handlers are registered. Before decoding any data, one or more handlers must therefore be registered.

Table 1, “Default ILcdARINCHandler implementations.” shows the ILcdARINCHandler implementations that are provided in the com.luciad.format.arinc.decoder package.

Table 1. Default ILcdARINCHandler implementations.

Name

Decoded objects

Record type

TLcdARINCAerodromeHandler

Airports

PA

TLcdARINCHeliportHandler

Heliports

HA

TLcdARINCControlledAirspaceHandler

Controlled Airspaces

UC

TLcdARINCRestrictiveAirspaceHandler

Restrictive Airspaces

UR

TLcdARINCFIRUIRHandler

FIR/UIR Airspaces

UF

TLcdARINCVORHandler

VOR VHF Navaids

DV

TLcdARINCDMEHandler

DME VHF Navaids

DD

TLcdARINCTACANHandler

TACAN VHF Navaids

DT

TLcdARINCNDBHandler

NDB Navaids and Terminal NDB

DB, PN

TLcdARINCLocalizerGlideSlopeHandler

Localizer/Glide Slope (ILS)

PI

TLcdARINCMarkerHandler

Localizer Marker

PM

TLcdARINCWaypointHandler

Enroute, Terminal Airport/Heliport Waypoints

EA, PC, HC

TLcdARINCEnrouteAirwayHandler

Airways and Routes

ER

TLcdARINCRunwayHandler

Runways

PG

TLcdARINCAirportCommunicationHandler

Airport Communications

PV

TLcdARINCHeliportCommunicationHandler

Heliport Communications

HV

TLcdARINCEnrouteCommunicationHandler

Enroute Communications

EV

TLcdARINCProcedureHandler

Airport SID, STAR, Approach Procedures

PD, PE, PF

TLcdARINCHoldingHandler

Enroute Holding Patterns

EP

TLcdARINCMORAHandler

Minimum Off-Route Altitudes

AS

The record type column shows the section and subsection code of the records decoded by each handler. Each ILcdARINCHandler 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.

Some of these handlers require that a number of models are set on the handler, before decoding can start. This is required for domain objects that depend on other domain objects for one of their properties or geometry. For instance, an ATS route uses a number of waypoints and navaids to define its geometry. These objects must be known during the decode process of the routes. The route handler, TLcdARINCEnrouteAirwayHandler, therefore requires a waypoint model and four navaid models (DME, VOR, TACAN, NDB) in order to define the correct objects referred to in routes. Please refer to the reference documentation for the exact dependencies of each handler on other models.

Configuration parameters

Filtering domain objects

ARINC 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 ILcdARINCModelFilter , 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.arinc.ARINCModelFeatureFilter.

Filtering attributes

Each ILcdARINCHandler implementation provided in the ARINC 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 TLcdARINCDMEHandler . By calling the method setDMEFeatureNamesToBeDecoded(String[]), the list of attributes to be decoded can be configured.

Note that feature names in the ARINC model do not necessarily correspond to property names. However, you can easily convert property names to feature names and back using the methods TLcdAISDataTypes.getProperty(TLcdDataType, String) and TLcdAISDataTypes.getFeatureName(TLcdDataProperty).