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