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