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
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.
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:
<aixm:Navaid> <gml:identifier>NAVAID_001</gml:identifier> <aixm:timeSlice> <aixm:NavaidTimeSlice> <aixm:interpretation>BASELINE</aixm:interpretation> ... </aixm:NavaidTimeSlice> </aixm:timeSlice> </aixm:Navaid> .. <aixm:Navaid> <gml:identifier>NAVAID_001</gml:identifier> <aixm:timeSlice> <aixm:NavaidTimeSlice> <aixm:interpretation>TEMPDELTA</aixm:interpretation> <aixm:operationalStatus>UNSERVICEABLE</aixm:operationalStatus> ... </aixm:NavaidTimeSlice> </aixm:timeSlice> </aixm:Navaid>
The decoder generates a model that is an exact mapping of the source data in XML, so this is also reflected in the decoded
Through the method
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.
An AIXM 5.1 feature can contain a variety of time slice s, with different interpretations, sequence numbers, and correction
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.
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
the original feature into a snapshot time slice, which is valid at the given time instant. The merging of time slices into
follows the rules specified in the AIXM 5.1 specification:
Each time slice will have its interpretation set to
If a feature does not contain time slices that are valid at the given date, it is omitted from the resulting message.
Some AIXM 5.1 types implement existing LuciadLightspeed interfaces. This enables the developer to use existing LuciadLightspeed painters to visualize and manipulate these types.
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.
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.
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.
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
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.
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
The base class for all time slice types is
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.
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
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.
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
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
After the message is decoded, all these objects are evaluated and the resolved objects are stored as linked objects in
ILcdDataObject that contained the XLink . The linked object is stored in a property with name
For actuate values
ILcdXLinkExpression objects are not evaluated but stored in the
TLcdXLinkSimpleLink object. This enables applications to resolve the XLink manually afterwards.
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
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.
TLcdXMLDataModelBuilder builder = new TLcdXMLDataModelBuilder( TLcdAIXM51DataTypes.getDataModel() ); TLcdDataModel extension = builder.createDataModel( "http://www.yournamespace.com/5.1/aixm-extension", "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.
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.