This guide contains general information about the Aeronautical Information System (AIS) functionality and concepts in LuciadLightspeed.

Each AIS format (Dafif, AIXM, ARINC, …​) has more format-specific documentation available as well.

Overview

This guide deals with the creation and handling of the aeronautical domain objects that are provided in AIS. In this overview, a number of general properties of AIS domain objects are explained. Subsequent sections give details about specific domain objects.

All AIS domain objects are located in the package com.luciad.ais.model and its sub-packages. In this overview, an aerodrome will be used as an example to demonstrate the general domain object modeling principles.

Program: This code creates a model with a single aerodrome inside. It demonstrates a number of general AIS domain object principles, which are discussed in this article. shows code to create a model with aerodromes. It is taken from the sample source file 'ais/model/ModelFactory.java'. It shows the use of (editable) interface, custom data types, model descriptors, and object factories as explained in subsequent sections.

Program: This code creates a model with a single aerodrome inside. It demonstrates a number of general AIS domain object principles, which are discussed in this article. (from samples/ais/model/ModelFactory) 
/**
 * Creates a model containing an aerodrome with a few features.
 *
 * @return a model containing an aerodrome with a few features.
 */
public ILcd2DBoundsIndexedModel createAerodromeModel() {
  TLcd2DBoundsIndexedModel aerodrome_model
      = new TLcd2DBoundsIndexedModel();

  // WGS 84 reference
  aerodrome_model.setModelReference(WGS_84);

  // Create a number of aerodromes with a custom type that is declared in our
  // own data model
  ILcdEditableAerodrome aerodrome = fObjectFactory.createAerodrome(CustomAISDataTypes.MyAerodromeType);
  aerodrome.move2D(4.5, 50.9);

  aerodrome.setValue(CustomAISDataTypes.MyAerodromeType.getProperty("Identification"), "EBBR");
  aerodrome.setValue(CustomAISDataTypes.MyAerodromeType.getProperty("Name"), "BRUSSELS NATIONAL");

  aerodrome_model.addElement(aerodrome, ILcdFireEventMode.NO_EVENT);

  // Create an aerodrome model descriptor that describes this model
  TLcdAerodromeModelDescriptor descriptor = new TLcdAerodromeModelDescriptor(
      "Hardcoded", "Aerodrome", "Aerodrome", CustomAISDataTypes.MyAerodromeType
  );
  aerodrome_model.setModelDescriptor(descriptor);

  return aerodrome_model;
}

Interfaces

All AIS domain objects are modeled using Java interfaces. One advantage of interfaces is that aeronautical objects already defined in an existing system, can be fitted into LuciadLightspeed by making them implement the corresponding AIS interface.

A basic aerodrome is defined in the ILcdAerodrome interface. This interface defines the geometry of the object: ILcdAerodrome is an extension of ILcdPoint, which means all aerodromes are represented by a point. Other methods defined in ILcdAerodrome determine attributes and relationships of an aerodrome.

In AIS, the number of attributes and relationships in the domain object interfaces is kept to a minimum. This is done to facilitate the use of the AIS domain objects in diverse applications. There is no need to implement lots of attributes if an application does not require these. When AIS domain objects do need extra attributes in an application, the domain objects can be extended easily by inheritance or, even easier, by using custom data types (see next section).

ILcdAerodrome defines the necessary geometry and properties of an aerodrome, but it cannot be edited. The ILcdEditableAerodrome interface extends ILcdAerodrome with editing functionality. It allows moving the location of the aerodrome, because it extends ILcd3DEditablePoint, and it also provided methods to change the attributes of an aerodrome (for example setAerodromeType).

Summarized, each AIS domain object is defined by an interface that specifies the geometry and a few important attributes or relationships. An editable interface is provided for most domain objects and allows changing the geometry or attributes of an object.

Custom data types

As mentioned in the previous section, AIS domain objects contain as few explicit attributes in their interfaces as possible.

The most common way to add attributes is through the use of custom data types. In LuciadLightspeed, data types are handled by the ILcdDataObject interface. Each object implementing this interface, defines a number of properties. A TLcdDataType defines names and classes of specific properties of an object. See the LuciadLightspeed developer’s guide for more information.

AIS allows the use of this standard data object mechanism. Custom data types can be easily created by extending a predefined type. A number of predefined types that are common between different AIS formats can be found in TLcdAISDataTypes. These types correspond to classes in the AIS domain model, as such these classes can only be used with extensions of these base types.

The sample class samples.ais.model.ModelFactory contains code which demonstrates the use of data types in AIS. Program: This code creates a model with a single aerodrome inside. It demonstrates a number of general AIS domain object principles, which are discussed in this article. shows the creation of an aerodrome with a few properties.

Implementations

AIS provides a number of standard implementations of the domain object interfaces.

ILcdFeatured versus ILcdDataObject based implementations

AIS provides generic access to the attributes of objects with two different mechanisms. For new applications, the use of the ILcdDataObject interface is recommended. Existing implementations can choose to keep on working with the ILcdFeatured interface but can also use the ILcdDataObject interface and still remain compatible with the ILcdFeatured interface.

The only thing to keep in mind when using API based on ILcdFeatured is that the predefined names of features do not map directly to the names of properties. The reason for this is that property names have certain restrictions like the fact that cannot contain spaces, while the feature names do contain spaces.

Whenever an API method has to be used that uses feature names instead of property names, you can easily convert property names to feature names and back using the methods TLcdAISDataTypes.getProperty(TLcdDataType, String) and TLcdAISDataTypes.getFeatureName(TLcdDataProperty).

Note that this only applies to feature names and properties that are predefined in the LuciadLightspeed domain models. When working with custom data types, you can define your own mapping to the featured interfaces.

Featured versus non-featured implementations

For each domain object in AIS, two implementations are provided, a non-featured and a featured implementation. For aerodromes, these classes are: TLcdAerodrome and TLcdFeaturedAerodrome.

The featured implementations allow you to set and add properties (or features). When no properties are required, the non-featured implementation is preferred, as it takes up less memory.

Note that the 'Featured' prefix comes from the use of the ILcdFeatured interface. This naming has been maintained for backwards compatibility but the classes should also be used for ILcdDataObject based applications.

Geodetic versus grid references

Most AIS domain object implementations can be configured for use in both grid (Cartesian) or geodetic references. LuciadLightspeed shapes, such as points and polylines, normally have both a Cartesian implementation (TLcdXYZPoint for example) and a geodetic implementation (TLcdLonLatHeightPoint). Doing the same for AIS, would require two versions of each domain object implementation, which would amount up to 4 implementation classes per domain object (Featured, non-featured and for both LonLatHeight and XYZ). To prevent an excessive number of classes, AIS domain object implementations delegate to a specific shape implementation.

For example, a TLcdAerodrome extends TLcdAISPoint, which allows to set the concrete implementation of the point to delegate to through the method setLocation. Creating a new TLcdAerodrome for use with a geodetic reference can be done in two steps: 

TLcdAerodrome aerodrome = new TLcdAerodrome();
aerodrome.setLocation(new TLcdLonLatHeightPoint(4.5, 50.9, 0) );

TLcdAISPoint and other AIS shapes that allow to set a delegate implementation are defined in the package com.luciad.ais.shape.

Models and model descriptors

Domain objects are typically put in ILcdModel instances. A model has a model reference and a model descriptor (an ILcdModelDescriptor implementation) that describes the contents of a model and its data objects.

In LuciadLightspeed, all elements in an ILcdModel must have the same geographical reference, called the model reference. All geometry of the elements in the model is specified with respect to this reference.

Model descriptors

In AIS, model descriptors are provided for most common domain objects. For aerodromes there is a TLcdAerodromeModelDescriptor which allows to define which data type the aerodromes in the model have. Layer factories often check the class type of the model descriptor, using an instanceof test, to determine whether they can handle a model.

The model descriptor used by AIS models also implement ILcdDataModelDescriptor and thus describe the types of the objects in the model. All objects should have one of the types returned by ILcdDataModelDescriptor.getModelElementTypes(). It is very common for AIS models to have only one type of element in a given model.

Domain object factories

A domain object factory is a class the can create a number of different domain objects. TLcdAISDataObjectFactory is an implementation of such a class that will create objects of specific types. Methods of this class can be overridden in case you want to change the class that is used when creating instances for certain data types.

This class delegates the creation of geometry to an instance of an ALcdAISGeometryFactory. This is an abstract class that can create geometries for use with specific types of model references. Two implementations are provided: TLcdAISLonLatHeightGeometryFactory for creating geometry with a geodetic reference, and TLcdAISXYZGeometryFactory for creating geometry for use in a grid reference.

Type safe enumerations

Often an attribute or feature of a domain object has a limited number of values. For example the type of an aerodrome can be an airport, a heliport or both. In AIS such enumerations are modeled using type safe enumerations, a common java design pattern. These enumerations are usually placed under a type sub-package. For example the TLcdAerodromeType is located in the com.luciad.ais.model.aerodrome.type package.

Conclusion

This section detailed some general design principles for AIS domain objects. The next sections will give details on specific domain objects, but the general principles explained here will not be repeated.

AIS Specific shapes: com.luciad.ais.shape

The geometry of domain objects is represented by shapes. This section details shapes specific for AIS.

Geo-Paths

Several domain objects in AIS are modeled using geo-paths. A geo-path is defined as a (circular) list of geo-path legs. Each geo-path leg is a point but has additional information on how to construct a path from the current leg to the next leg; this is determined by the type of the geo-path leg (defined in ILcdGeoPathLeg).

For example a geo-path leg of type GEODESIC_LINE indicates that a geodesic line must be constructed from the current leg to the next leg.

The main interfaces for geo-paths are: ILcdGeoPath, ILcdGeoPathLeg, ILcdEditableGeoPath, ILcdEditableGeoPathLeg. The main implementations are: TLcdGeoPath and TLcdGeoPathLeg.

AIS also provides support for the discretization of geo-paths. Currently this is only supported for geodetic references, through the class TLcdDiscretizedLonLatGeoPath.

Delegating shapes

AIS provides several shapes that delegate to a specific implementation. As mentioned before, this is to accommodate both geodetic and grid references with a single object.

Currently AIS provides: TLcdAISPoint, TLcdAISPolygon, TLcdAISPolyline. See the reference documentation for more information.

Aerodrome related objects: com.luciad.ais.model.aerodrome

The following aerodrome related objects are supported in AIS:

  • Aerodromes: The aerodromes, including both airports and heliports, themselves are modeled as a point and support a type and collocated aerodromes.

  • Runways: Runways are modeled as a polyline, which represents the centerline of the runway. The width of the runway is a required attribute. Together they determine the geometry of the runway. A runway can have two runway directions.

  • Runway directions: An ILcdRunwayDirection models some additional information of a runway direction such a the threshold point, and an arresting gear.

  • Helipads: the area of a helipad is modeled using a geo-path.

  • Arresting gear: An arresting gear or arresting device is modeled as a point.

Navaids and waypoints: com.luciad.ais.model.navaid

AIS supports the following navaids and related objects:

  • VOR, DME, TACAN, NDB: all are modeled as a point and support all possible collocations.

  • Waypoints: also modeled as a point

  • ILS: An ILcdILS is an instrument landing system that can contain a glide slope, a localizer and markers. All these are modeled as points.

Air spaces: com.luciad.ais.model.airspace

Air spaces are generally modeled as an ILcdShape, through the interface ILcdGenericAirspace. This interface is the basis of more specific air space interfaces that differ in the way they are constructed:

  • ILcdAirspace: this interface represents an air space as a polygon, constructed from a closed ILcdGeoPath. This is the way most air spaces are modeled in AIXM, ARINC, and DAFIF. Such an air space consists of a number of ILcdAirspaceSegment instances, which are individual legs of a geo-path with a sequence number added. These segments are combined into a polygon.

  • ILcdAirspaceCorridor: this interface represents an air space as a buffer, constructed from an axis and a width. The resulting shape is a polygon, that represents the contour of the buffer. The axis of the buffer is modeled as an open ILcdGeoPath: like ILcdAirspace, it also consists of a number of ILcdAirspaceSegment instances, which are individual legs of the geo-path. These segments are combined into a polyline, which is used as axis for the buffer. The width of the buffer can be specified separately. This type of airspaces is only used in AIXM, versions 4.0 and 4.5.

  • ILcdAssociationBasedAirspace: this interface represents an air space that is built up from other air spaces. These air spaces can be combined in several ways and are related to the association-based air space using an airspace association. An airspace association is modeled by the interface ILcdAirspaceAssociation, and consists of an air space, an association type and a sequence number. The geometry of an association-based air space is a shape list, where each of the shapes in the shape list is a polygon or a complex polygon. AIS provides support for the discretization of association-based airspaces, through the class TLcdAssociationBasedAirspace.

Note that any altitudes that may be part of an air space are not explicitly modeled. In the AIXM, ARINC and DAFIF decoders they are modeled using features.

Routes: com.luciad.ais.model.route

Routes or air ways are modeled using ILcdRouteSegment instances. Each route segment connects 2 points.

The geometry of a route is a shape list, where each of the shapes in the shape list must be a polyline. This is done to accommodate routes made up of separate parts, where each part is a polyline containing a set of segments. Most often, however, a route will contain just a single shape (a single polyline).

Several different types of routes are provided in AIS (ATS routes, military training routes). All of these are simply derived from ILcdRoute.

Procedures: com.luciad.ais.model.procedure

AIS provides comprehensive support for terminal procedures. Standard instrument departures (SID), Standard terminal arrival route (STAR) and instrument approach procedures (IAP).

The main domain object for procedure modeling is an ILcdProcedure. An ILcdProcedure models a SID, STAR, or IAP as a number of procedure legs according to the ARINC 424 standard. An ILcdProcedureLeg is the main interface for a procedure leg. It defines the main attributes of a leg, such as the leg type (for example: IF, TF, CA, CF, …​ ), a fix, the fix overfly type, and so on.

Note that an ILcdProcedure does not support branches. An example of a branched procedure is a SID that has two or more runway transitions (for instance starting at different runways) which are followed by a single common part, which in turn may be followed by one or more en-route transitions. Such a branched procedure does not define a single path from the start to the end of the procedure, and complicates generating trajectories from a procedure.

A procedure in AIS is a single sequence of procedure legs. Branches can be modeled easily as a number of separate procedures. Each transition can be seen as a separate procedure, or different combinations of in, common, and out transitions can be modeled as separate procedures (which is the way it is done in the ARINC and DAFIF decoders).

A procedure in itself does not define a unique trajectory, because that depends on a number of settings such as the aircraft performance (turn radius, speed, …​ ). In AIS a number of support classes are provided to compute a geometry (or a trajectory) from a procedure:

  • TLcdProcedureGeometryCalculator: this class can process a procedure and produce an actual geometry representing this procedure. It contains a lot of complex logic and geodetic computations to do so.

    The main method is calculateProcedureGeometry which requires an ILcdProcedure and an ILcdProcedureGeometryHandler as parameters.

    The geometry of the procedure is passed piece by piece to the ILcdProcedureGeometryHandler. The supplied handler can do anything it wants with the produced geometry: drawing, storing, computing statistics, …​

    The geometry calculator has set/getAircraftPerformanceSettings methods, which allow to query or specify the aircraft performance settings with which the geometry is computed.

    The geometry calculator does not require that all attributes of a procedure leg are filled in. The reference guide contains information on which attributes are required for which types of procedure legs.

  • TLcdProcedure3DGeometryCalculator: this extension of TLcdProcedureGeometryCalculator tries to compute a trajectory with more realistic altitudes along the procedure.

  • ILcdProcedureGeometryHandler: this interface defines the way procedure geometry is built by the calculator. A procedure geometry is built up of points (handlePoint), line segments (handleLine), and arcs (beginAngleArc, endAngleArc). Arc geometry is also passed in discretized form to the handleArcSegment method.

    Each geometry primitive passed to the handler has a type defined in TLcdProcedureGeometryType. This allows special handling of decorations, errors, and connector segments.

    The ILcdProcedureGeometryHandler is demonstrated in TLcdGXYProcedureTrajectoryLegLabelPainter, which is supplied with the sample source code of AIS under ais/view/gxy.

  • TLcdAircraftPerformanceSettings: this class defines a number of aircraft performance settings used by the procedure geometry calculators.

  • TLcdProcedureTrajectory: this is an AIS domain object that represents an actual procedure trajectory. It is related to a single ILcdProcedure that must be specified in its constructor. The trajectory has two properties, procedureGeometryCalculator and aircraftPerformanceSettings, which can be changed with a setter method. These properties determine how the procedure is turned into geometry.

    The geometry of the trajectory is a polyline (TLcdProcedureTrajectory implements ILcdPolyline). This geometry is cached in the object, which prevents costly re-computation of the procedure geometry. However, when the ILcdProcedure related to this trajectory is changed, the invalidate method must be called on the trajectory in order to have the geometry updated. The same holds when the aircraft performance settings are changed.

    The processProcedureGeometry(ILcdProcedureGeometryHandler aHandler) method allows to replay the procedure geometry to a geometry handler. This can be useful for special handling of decorations, errors or just to know which part of the trajectory corresponds to a specific leg in the procedure.

    It is recommended to always use TLcdProcedureTrajectory objects in ILcdModel instances instead of ILcdProcedure instances, because they have a defined geometry and defined bounds.

Program: This code creates a model with a single procedure inside. shows code to create a model with a single procedure. It is taken from the sample source file 'ais/model/ModelFactory.java'.

Program: This code creates a model with a single procedure inside. (from samples/ais/model/ModelFactory) 
/**
 * Creates a model containing a procedure. Fixes used in procedures can be any ILcdPoint instance.
 * In this sample, waypoints and aerodromes from the supplied models
 * are used, as well as on the fly created points.
 *
 * @param aAerodromeModel An aerodrome model.
 * @param aWayPointModel  A waypoint model.
 * @return a model containing a procedure.
 */
public ILcd2DBoundsIndexedModel createProcedureModel(
    ILcd2DBoundsIndexedModel aAerodromeModel,
    ILcd2DBoundsIndexedModel aWayPointModel
) {
  TLcd2DBoundsIndexedModel procedure_model =
      new TLcd2DBoundsIndexedModel();

  // WGS 84 reference
  procedure_model.setModelReference(WGS_84);

  /*
   * Find waypoints based on the identifier.
   */
  ILcd3DEditablePoint helen = null;
  Enumeration elements = aWayPointModel.elements();
  TLcdDataProperty identifierProperty = CustomAISDataTypes.MyWaypointType.getProperty("Identifier");
  while (elements.hasMoreElements()) {
    ILcdDataObject object = (ILcdDataObject) elements.nextElement();
    if ("HELEN".equals(object.getValue(identifierProperty))) {
      helen = (ILcd3DEditablePoint) object;
      break;
    }
  }

  if (helen == null) {
    System.out.println("Error: cannot find HELEN in waypoints model");
    return null;
  }

  // Find the EBBR aerodrome, but this time the model elements are enumerated explicitly
  Enumeration aerodromes = aAerodromeModel.elements();
  TLcdAerodromeModelDescriptor ad_descriptor =
      (TLcdAerodromeModelDescriptor) aAerodromeModel.getModelDescriptor();
  TLcdDataProperty aerodromeIdentifierProperty = ad_descriptor.getModelElementTypes().iterator().next().getProperty("Identification");
  ILcdAerodrome ebbr = null;
  while (ebbr == null && aerodromes.hasMoreElements()) {
    ILcdDataObject aerodrome = (ILcdDataObject) aerodromes.nextElement();
    String identification = (String) aerodrome.getValue(aerodromeIdentifierProperty);
    if (identification.equalsIgnoreCase("EBBR")) {
      ebbr = (ILcdAerodrome) aerodrome;
    }
  }

  if (ebbr == null) {
    System.out.println("Error: cannot find EBBR in aerodromes model");
    return null;
  }

  // Create a runway point on the fly
  TLcdLonLatHeightPoint runway_point = new TLcdLonLatHeightPoint(4.51, 50.91, 0);

  // Create an intermediate fix on the fly
  TLcdLonLatHeightPoint nicky = new TLcdLonLatHeightPoint(4.15, 51.15, 0);
Program: Procedure creation (continued). (from samples/ais/model/ModelFactory) 
  // Create the procedure
  ILcdEditableProcedure procedure = fObjectFactory.createProcedure(CustomAISDataTypes.MyProcedureType);

  // Initial fix
  ILcdEditableProcedureLeg leg = fObjectFactory.createProcedureLeg(TLcdAISDataTypes.ProcedureLeg);
  leg.setType(TLcdProcedureLegType.IF);
  leg.setFix(runway_point);
  leg.setCourse(70);
  leg.setSequenceNumber(10);
  procedure.addLeg(leg);

  // Course to an altitude
  leg = fObjectFactory.createProcedureLeg(TLcdAISDataTypes.ProcedureLeg);
  leg.setType(TLcdProcedureLegType.CA);
  leg.setRho(133);
  leg.setCourse(66);
  leg.setSequenceNumber(20);
  procedure.addLeg(leg);

  // Direct to fix
  leg = fObjectFactory.createProcedureLeg(TLcdAISDataTypes.ProcedureLeg);
  leg.setType(TLcdProcedureLegType.DF);
  leg.setFix(nicky);
  leg.setSequenceNumber(30);
  procedure.addLeg(leg);

  // Track to fix
  leg = fObjectFactory.createProcedureLeg(TLcdAISDataTypes.ProcedureLeg);
  leg.setType(TLcdProcedureLegType.TF);
  leg.setFixOverflyType( TLcdProcedureLegFixOverflyType.FLY_OVER );
  leg.setFix(helen);
  leg.setSequenceNumber(40);
  procedure.addLeg(leg);

  // Track to fix
  leg = fObjectFactory.createProcedureLeg(TLcdAISDataTypes.ProcedureLeg);
  leg.setType(TLcdProcedureLegType.TF);
  leg.setFix(ebbr);
  leg.setSequenceNumber(50);
  procedure.addLeg(leg);

  // Create a procedure trajectory model descriptor that describes this model.
  TLcdProcedureTrajectoryModelDescriptor descriptor = new TLcdProcedureTrajectoryModelDescriptor(
      "Hardcoded", "Procedures", "Procedures",
      CustomAISDataTypes.MyProcedureType);

  procedure_model.setModelDescriptor(descriptor);

  // Add the procedure to a proceduretrajectory, set the designator value and add it to the model
  TLcdProcedureTrajectory trajectory = fObjectFactory.createProcedureTrajectory(procedure);
  trajectory.setValue(CustomAISDataTypes.MyProcedureType.getProperty("Designator"), "BE12345");
  procedure_model.addElement(trajectory, ILcdFireEventMode.NO_EVENT);

  return procedure_model;
}

Other domain objects

AIS also provides other domain objects, which are handled similarly to the previously described domain objects. Other domain objects in AIS are:

  • Geoborders (com.luciad.ais.model.geoborder): Geographical borders are modeled as polylines.

  • Services (com.luciad.ais.model.service): A general service is defined by the interface ILcdService and does not contain any geometry related information. This domain object can be used to model any kind of service that is provided by an AIS related domain object, such as an airport or a heliport. An extension of this interface exists, ILcdLocationBasedService, that models a service as a point. A common example of a location-based service is an Air Traffic Control service at an airport.

  • Area Minimum Altitudes (com.luciad.ais.model.ama): An area, usually a rectangle, for which a minimum safe flying altitude is defined. This type can be used to model any area-based, cell-based, or quadrangle-based minimum safety altitude, such as MORA (Minimum Off-Route Altitude), MEF (Maximum Elevation Figure) or AMA (Area Minimum Altitude). There is a specific sub-type ORTCA (com.luciad.ais.model.ortca) that models Off-route terrain clearance altitudes.

  • Obstacles (com.luciad.ais.model.obstacle): Obstacles are modeled as points.

  • Parachute jump areas (com.luciad.ais.model.parachutejumparea): these areas are modeled as a geo-path.

  • Refueling tracks (com.luciad.ais.model.refuelingtrack): Refueling tracks determine an air space and a route where refueling in air can take place. It is modeled after the DAFIF concept of refueling tracks.

  • VFR routes (com.luciad.ais.model.vfr): Visual Flight Rules routes and offset routes are modeled as polylines.