The basic information unit in an AIXM 5.1 dataset is a feature. A feature corresponds to a real object in the aeronautical environment, such as an aerodrome, runway, navaid, route, and so on.
Each AIXM 5.1 feature consists of one or more time slice s that describe the state of the feature during a certain time period. To obtain a precise representation of the various states of aeronautical features, an exhaustive temporality model differentiates between various kinds of time slice s:
Baseline: A baseline time slice includes the values of all feature properties that are defined for the time of validity of the time slice.
Temporary or tempdelta: A tempdelta time slice includes the values of temporarily changed feature properties.
Permanent or permdelta: A permdelta time slice includes the values of permanently changed feature properties.
Snapshot: A snapshot time slice describes the state of feature properties at one time instant.
A feature can be stored in three different ways:
Inside a Basic Message, which represents a collection of features with focus on baseline data
Inside a Digital NOTAM, which represents a collection of features with focus on temporal or permanent changes to baseline data
More detailed information on the format and its temporality model can be found on the AIXM website http://www.aixm.aero.
format.aixm51 package and its subpackages provide the LuciadLightspeed API for AIXM 5.1.
format.aixm51.model package is concerned with representing the AIXM 5.1 model as defined by the AIXM 5.1 UML diagrams. The following list gives
a short overview of the main classes:
All AIXM 5.1 feature types are represented by the
TLcdAIXM51AbstractAIXMFeatureclass. This class is a parameterized class that takes a type parameter corresponding to the time slice type. Time slice types are represented by domain classes that extend from
TLcdAIXM51AbstractAIXMTimeSlice. Take the airspace type, for example. This type is represented by
TLcdAIXM51AirspaceTimeSliceclass represents the time slice of an airspace and has as such accessors for the designator, activation, protected route, …​
AIXM 5.1 object types are represented by subclasses of
All AIXM 5.1 codes are represented by subclasses of
ALcdAIXM51Code. These subclasses provide public constants for the well-known codes.
The design of the AIXM 5.1 model poses an additional difficulty when trying to represent features. A feature does not contain any attributes directly but contains a list of time slices instead. These time slices can either contain all properties of the feature in case of a BASELINE time slice, or they can contain only properties that are relevant for a specific time period. This means that anyone who wants to show a representation of a feature needs to select the right time slice based on a given feature.
Selecting a suitable time slice for a given feature is delegated to an
ILcdAIXM51TimeSliceProvider . This class encapsulates the strategy to select a time slice from a feature, and its consistent use ensures that you can
easily switch the desired strategy at runtime.
There are two ways to work with an
ILcdAIXM51TimeSliceProvider . The easiest option is to use the
setDefaultTimeSliceProvider method, available on
TLcdAIXM51AbstractAIXMFeature . This ensures that there is a provider
available whenever it might be needed because it is stored in the feature directly. The drawback of this approach is that
does not allow you to use more than one time slice provider for the same feature concurrently. Therefore all relevant AIXM
5.1 classes such as painters and XPath factories can also be configured with an
ILcdAIXM51TimeSliceProvider that overrides the default one. This makes it possible for an application to have for instance two painters that paint the
same feature for different time instants.
There are two time slice provider implementations that implement the most common strategies. The first one,
TLcdAIXM51TimeSliceProvider, returns one
of the time slices in the list of time slices in the feature. Normally this will be a baseline time slice, assuming
that it is available. The second one,
TLcdAIXM51SnapshotTimeSliceProvider , can be configured with a date, and will return a snapshot time slice that is valid for
that date, or no time slice if the feature does not have valid time slices for that date.
All domain classes in the
format.aixm51 package implement the
ILcdDataObject interface. The
TLcdAIXM51DataTypes class defines public constants for the
TLcdDataType instances that represent the AIXM 5.1 types and provides access to the AIXM 5.1
TLcdDataModel. For detailed information on
Models: Working with domain object properties.
ILcdDataObject provides an alternative API to access AIXM 5.1 data. This API is independent of the domain classes. An important difference
with the domain object API is that this API presents a more detailed view. To better understand this, you need to understand
how the AIXM 5.1 model is defined.
The AIXM 5.1 model is originally defined in UML. This UML model is then transformed into an XML schema using a set of rules. For more detailed information about this transformation, see the AIXM website. Because of those rules, the XML schema is not a direct representation of the UML model. The XML schema model in fact contains more information. The UML model is a kind of simplification. Figure 1, “Association classes in AIXM - UML versus XML schema” shows this for the AirportHeliportTimeSlice type. In the UML model, AirportHeliportTimeSlice has a CodeAirportHeliport attribute called 'type'. The XML schema adds a 'nilReason' property that enables you to add a reason why the type of an airportheliport is not filled in. This turns the link between AirportHeliportTimeSlice and CodeAirportHeliport into an association class with a 'nilReason' attribute. In the same vein, association classes are introduced in the association with AbstractExtension and the AltimeterSource feature. The figure shows this for three properties; in reality this happens for practically all properties defined on time slice types. This makes the XML schema much more complex than the UML model. Note that the only exception to this rule are the TLcdAIXM51Val* classes where the nilReason property is directly added to the class itself.
The LuciadLightspeed AIXM 5.1 model is internally structured according to the XML schema model. This is required because the
model needs to keep track of all possible information that can be stored in an AIXM 5.1 XML document. The API provided by
the domain classes provides a simplified UML-like view on this. All association classes are filtered from this API. This makes
the domain classes more straightforward to use. The generic API provided by
ILcdDataObject gives direct access to the internal structure. This API keeps all association classes (such as
Program: Accessing AIXM 5.1 data first uses the domain object API to set the type of an AirportHeliportTimeSlice to AD. Then it does the same using the generic API. In the latter case the nilReason property is also filled in. Note how
newInstance() method is used to easily create a new
TLcdAIXM51AirportHeliportTimeSlice ts = ...; // AIXM 5.1 domain object API ts.setType( TLcdAIXM51CodeAirportHeliport.AD ); // Unified domain object API TLcdAIXM51Optional<TLcdAIXM51CodeAirportHeliport> type = (TLcdAIXM51Optional<TLcdAIXM51CodeAirportHeliport>) TLcdAIXM51AirportHeliportTimeSlice.TYPE_PROPERTY.newInstance(); type.setValueObject( TLcdAIXM51CodeAirportHeliport.AD ); type.setNilReason( "This property has a valid value" ); ts.setValueObject( TLcdAIXM51AirportHeliportTimeSlice.TYPE_PROPERTY, type );
AIXM 5.1 data can also be accessed through the use of XPath expressions. This allows developers to extract the data in a LuciadLightspeed
independent manner. Anyone who is familiar with XPath and the AIXM 5.1 schema can use the
TLcdAIXM51XPathFactory to generate XPath expression objects from strings which can then be used in the application to extract the desired data.
More information can be found in Using XPath expressions.