ASTERIX data decoding

In the com.luciad.format.asterix package two decoders are available. Use the TLcdASTERIXModelDecoder to decode ASTERIX data from file and the TLcdASTERIXLiveDecoder to decode ASTERIX data from a live stream of data.

The TLcdASTERIXModelDecoder is an ILcdModelDecoder. The decode method produces an ILcdModel which is in fact a TLcdModelList containing an ILcdModel for every combination of category and User Application Profile (UAP) encountered. You can also use the decodeSource method of its ILcdModelDecoder interface to decode multiple ASTERIX files at once. Using this method, a trajectory that is split across multiple files can still be decoded as a single trajectory.

The TLcdASTERIXLiveDecoder on the other hand is not an ILcdModelDecoder. It has a method decodeSFCT(InputStream aInputStream, int aFireEventMode, TLcdModelList aModelSFCT), which must be called to start reading data from a live stream. Here you must create a ILcdModelContainer yourself and pass it as an argument to the decodeSFCT method. During the decode an ILcdModel is added for every combination of category and UAP encountered. The aInputStream argument of the decodeSFCT method specifies the stream from which data is read. For the TLcdASTERIXLiveDecoder the reading must be started from a dedicated thread. It can then be stopped by calling the interrupt method on the thread.

TLcdASTERIXLiveModelDecoder offers the functionality if the TLcdASTERIXLiveDecoder as an ILcdModelDecoder. This is useful when your application uses the TLcdServiceLoader to find all model decoders, or when you have another centralized list of model decoders. Since there are no standard protocols for live ASTERIX data, you need to set your own ILcdInputStreamFactory on the TLcdASTERIXLiveModelDecoder that can create an InputStream based on your needs.

The decoders group data of one category and UAP into one ILcdModel. The objects of the individual models are domain objects that reflect the type of data the category or more specific the UAP represents. The objects also depend on the type of decoder : TLcdASTERIXModelDecoder and TLcdASTERIXLive(Model)Decoder will create different domain objects, each containing the same UAP data, but in another representation. The following table describes which type of domain objects are contained in which model, and also mentions the data item that is used as ID for the domain objects:

The model descriptors of the individual models depend on the type of domain object in the model. They can be used to check the type of domain object in the model. Refer to Model descriptors for more information on model descriptors.

The decoders can be configured in several ways:

In the ASTERIX specification, each UAP of each category contains a number of data items. Refer to ASTERIX domain object modeling for more information on the ASTERIX data structure.

Data items in ASTERIX are mapped to values of properties (represented by ILcdDataObject) of ASTERIX tracks or plots in LuciadLightspeed . This is visualized in the diagram shown in Figure 1, “Mapping of data items to the LuciadLightspeed data object interface”. Note that ILcdDataObject is mentioned twice to simplify the diagram layout.

A data record for a category can contain information for all or part of the data items. Data items that are not present in the data records are returned as null values.

A data item can be described by a data field, but can also have a more complex structure. Depending on its structure a data item can be mapped to a property in different ways:

All trajectories have at least an 'ID' property.

Depending on the UAP of the data, trajectories may have more properties. These extra properties represent the track properties that usually remain the same for the entire trajectory. For instance, trajectories of category 30 have a property 'Departure Airport' as each track of a trajectory usually describes the same departure airport.

The actual value of the trajectory property is the last track-value that is not null, or null if all track-values are null.

This is the list of available trajectory properties per category and UAP:

The TLcdDataType of a trajectory describes which properties are available. These TLcdDataType instances are available as Java constants in the TLcdASTERIXDataTypes class. The constants for the trajectory data types all end in *TrajectoryType. You can inspect the trajectory-related TLcdDataType instances for each UAP with the datamodelviewer sample.

The TLcdDataType of the weather picture contains the following properties :

The TLcdDataType for precipitation zone contains only one property : Intensity, which is the intensity of the precipitation.

Like the TLcdDataType of trajectory, you can inspect the TLcdDataType of the weather picture with the datamodelviewer sample.

The TLcdDataType of the radar service message contains these properties amongst others:

Like the TLcdDataType of trajectory, you can inspect the TLcdDataType of the radar service message with the datamodelviewer sample.

Category data items are mapped to properties of tracks or plots in LuciadLightspeed . You can inspect which properties are available by running the datamodelviewer sample.

The data type for each of the categories can be retrieved through the TLcdASTERIXDataTypes.getTrackModelElementDataType(ALcdASTERIXUserApplicationProfile) method. This method takes a UAP as an argument to determine the data type used by the elements of any given ASTERIX track or plot model.

The data models for the different tracks can be obtained through the TLcdASTERIXDataTypes.getDataModel(ALcdASTERIXUserApplicationProfile aUserApplicationProfile) method.

The data type used by TLcdASTERIXTrajectory domain objects can be retrieved using the static TLcdASTERIXDataTypes.getTrajectoryDataType(ALcdASTERIXUserApplicationProfile) method. To retrieve the data model, use the same method, and call the getDataModel() on the resulting TLcdDataType.

The object type determines whether you can change the value of the object properties:

This is the list of track and plot properties that can be changed:

You can change the value of the properties by calling the setValue method on the domain object. This method is part of the ILcdDataObject interface. See the Working with domain object properties page for more information.

Note that you cannot change the geometry or the timing information of a trajectory, track or plot.

Since LuciadLightspeed V10.1, the ILcdDataObject interface is used to represent the data of a domain object in ASTERIX. This interface contains all the information of the previous ILcdFeatured interface and more. The older ILcdFeatured interface is still supported for reasons of backward compatibility, but it is advised that you use ILcdDataObject where possible.

For more information on how to use the ILcdFeatured interface, consult the API documentation of the ALcdASTERIXModelDescriptor class.

Following information is always available through the interfaces and methods implemented by the class ALcdASTERIXModelDescriptor:

With the exception of category 240, which will be discussed below, all ASTERIX domain objects have a shape which allows to visualize them on a map. The points that define the shape are extracted from the data items that represent coordinates. The models containing the ASTERIX domain objects must be assigned an ILcdModelReference which corresponds to the ASTERIX coordinates. Two things must be considered here:

This implies that the coordinates of the ASTERIX data items must be transformed to express WGS84 geodetic coordinates. That’s where the ALcdASTERIXTransformationProvider comes in: it handles the coordinate transformations between the decoded ASTERIX coordinates and WGS84. An ASTERIX decoder can be assigned an ALcdASTERIXTransformationProvider that it then uses for the necessary transformations. (Refer to ASTERIX Transformation Provider.)

The ALcdASTERIXTransformationProvider is an abstract class. Make an extension of it and implement the provideModelModelTransformation(int aSacSic, ILcdModel aModel, Object aObject) method to provide the correct ILcdModelModelTransformation for the data you want to decode. The argument aSacSic represents the System Area Code (SAC) and System Identification Code (SIC). These codes define which radar surveillance system is used. The aModel argument can be used to retrieve the data category or UAP the data belongs to, so you can use it to implement a transformation per radar system and per data category.

For instance, for locations specified relative to the radar location, you need to know the position of the radar and also the exact definition of the radar-dependent grid reference. This extra information is not present in the data. You must therefore provide it by implementing a ALcdASTERIXTransformationProvider.

As mentioned above, ASTERIX category 240 is an exception to the rule that all model elements must be transformed to a WGS84 geodetic reference. For category 240 data, the decoder uses an ALcdASTERIXReferenceProvider to assign a model reference to the model. As a consequence, category 240 data cannot be decoded into a single TLcdModelList together with other data categories. Use a TLcdModelTreeNode instead of a TLcdModelList if you expect to decode category 240 data as well as other categories.

ALcdASTERIXReferenceProvider must return a model reference that encapsulates the position and orientation of the radar platform. Typically, this is an azimuthal equidistant reference. Its origin is the position of the radar and its rotation is the orientation of the radar platform. TLcdASTERIXReferenceProvider can be used for static radar platforms, where the model reference never needs to change. If the radar is on a moving platform such as a ship, however, the provider should return a model reference that reflects the current position and heading of the ship.

The sample class samples.decoder.asterix.file.MainPanel demonstrates how to use ASTERIX data with the Real-Time Engine option for two types of models: ASTERIX trajectory models and ASTERIX weather models. In both cases, a samples.decoder.asterix.ASTERIXTrackSimulatorModelFactory first tries to create an instance of ILcdSimulatorModel for the ASTERIX model.

For trajectory models, the implementation of ILcdSimulatorModel creates and keeps track models that hold the simulated trajectory data. This data changes dynamically, in function of the time set by the simulator. The sample class samples.decoder.asterix.SimulatorGXYLayerFactory creates a layer for such dynamic models.

The ILcdSimulatorModel treats weather data differently. Instead of making track models, it filters the layer created from the weather model: only the weather pictures that are active for the given time are displayed. If there are no active weather pictures, the most recent previous weather pictures are shown.

It is also possible to replay the data from files in ASTERIX Final format or PCAP format as if it came from a live stream of data.

For this purpose, a class TLcdASTERIXFinalReplayInputStream is introduced. It reads an .astfin file in the ASTERIX Final Format or a .pcap file in the PCAP format, and uses the time information in the headers to replay the data: the data is only made available after the time between 2 headers has passed.

Using the TLcdASTERIXLiveDecoder with a TLcdASTERIXFinalReplayInputStream allows to replay ASTERIX data.

The TLcdASTERIXFinalReplayInputStream can be configured through the following classes and methods: