Introduction to the S-57 domain model

S-57 data is organized into cells. Each cell describes one specific geographical region. The contents of a cell are S-57 feature objects and spatial objects. An object represents one identifiable set of information. All objects have an identifier, attributes and may be related to other objects.

The com.luciad.format.s57 package provides a domain model and model decoders for S-57 data.

IHO S57
Figure 1. Summarized overview of the S-57 domain model

The object classes and their associated attributes are not part of the S-57 specification; they are defined in the product specifications for ENC, IENC, AML, and so on. The product specification additionally constrains the spatial object types that may be associated with each object class.

You can find a detailed description of the S-57 domain model in the S-57 IHO Transfer Standard for Digital Hydrographic Data, Part 2, "Theoretical data model".

Feature objects

Feature objects typically correspond to real-world entities, a buoy, a bridge or a fishing zone for example. They may be related to one or more spatial objects, but this is not required. Metadata objects often do not have geometry, for example.

Feature objects have an object class, defining the feature type, of the object, for example, a buoy type. With each object class are associated a fixed number of attributes, defining the properties of the object, for example, the minimum depth of a depth area.

Spatial objects

Spatial objects are similar to feature objects, but also have geometry. See Figure 1, “Summarized overview of the S-57 domain model”.

There are three different spatial object types: nodes, edges and faces, as illustrated in Figure 1, “Summarized overview of the S-57 domain model”:

  • A node is defined by its coordinates.

  • An edge is defined by a begin and end node, and intermediate coordinates.

  • A face is defined by one or more edges defining the bounds of the face.

LuciadLightspeed S-57 domain model API

Model structure

Cell models

Each S-57 cell is decoded to a single ILcdModel. Its model descriptor is an instance of TLcdS57ModelDescriptor. The model’s elements are all S-57 feature objects of the cell.

The model is spatially indexed, and its spatial objects are accessible via the ILcd2DBoundsIndexedModel interface. Features without geometry are accessible via the model’s elements() method, which also includes features with geometry. Feature objects are not accessible via the spatial applyOnInteract() method, however.

Catalogue models

Each S-57 catalogue is decoded to a single model. The model descriptor is an instance of TLcdS57CatalogueModelDescriptor. The model is a model list that in turn contains a list of model lists, one for each navigational purpose. Each of these model lists contains all the individual S-57 cell models for that navigational purpose. The structure is summarized in Figure 2, “Model structure for a catalogue model”.

The model is also spatially indexed at each level, and is accessible via the ILcd2DBoundsIndexedModel interface. The contents of a leaf model (the cell models) and the contents of a cell model that has been decoded individually outside of the catalogue context, are identical.

Class Diagram  CatalogueModelStructure
Figure 2. Model structure for a catalogue model

Features

S-57 feature objects are modeled in LuciadLightspeed by the ILcdS57FeatureObject interface. This interface provides methods for retrieving:

  • The S-57 identifier of the feature

  • The geometry type (point, line, area or none)

  • The relationships in which the feature is involved

Features with geometry are modeled by the ILcdS57Object interface, which is an extension of ILcdS57FeatureObject additionally implementing ILcdShape.

The S-57 identifier contains all relevant S-57 specific information of the feature: it provides access to the feature’s object class and all of its attributes.

Depending on the associated spatial object, each S-57 feature object will be mapped onto a specific ILcdS57FeatureObject implementation, providing access to the spatial information. Table 1, “S-57 domain object classes” lists all spatial object types with their corresponding LuciadLightspeed feature representation. Thus, depending on the associated spatial object, features of the same S-57 object class may be mapped onto instances of different Java classes.

Table 1. S-57 domain object classes
S-57 spatial object type LuciadLightspeed domain class Shape implementation

point

TLcdS57Point

ILcdPoint

line

TLcdS57Line

ILcdPolyline

area

TLcdS57Area

ILcdComplexPolygon

sounding

TLcdS57SoundingPoint

ILcdPoint

non-geometric feature

TLcdS57FeatureObject

The ILcdPolyline and ILcdComplexPolygon interfaces of TLcdS57Line and TLcdS57Area hide the composite nature of the underlying geometry; you can use them without knowledge of the underlying edges and faces that define the lines and areas. The edges and faces are still accessible however through the getEdge(int) and getFace(int) methods of the domain objects. Edges and faces are modeled as TLcdS57Edge and TLcdS57Face objects, which are implementations of ILcdPolyline and ILcdPolygon respectively.

Edges may be shared among different S-57 line or area features, for example, two adjacent depth areas will share one or more edges. Whenever an edge is shared geographically between two features, the feature instances in memory should also share the same edge, that is, they should have a reference to the same edge instance. When decoding a model using the TLcdS57UnifiedModelDecoder, TLcdS57ModelDecoder or TLcdS57CatalogueModelDecoder, the decoder automatically takes care of this.

Figure 3, “UML model of the main S-57 domain classes” shows a UML diagram summarizing all important domain model classes and their relations.

LuciadLightspeed Domain Model
Figure 3. UML model of the main S-57 domain classes

Metadata

The TLcdS57ModelDescriptor provides access to most of the important global metadata in the S-57 cells. This includes information about the issue date and edition number, producing agency, geographic reference information and accuracy information.

The data itself may also contain metadata. For example, for the ENC product, all object classes with object class codes between 300 and 312 define meta object classes. These object classes can also have a geometry. An area of the object class M_ACCY, for example, provides information about the accuracy of the data within the geographical extent covered by that area. The TLcdS52DisplaySettings contain a flag, setDisplayMetadata, which can be used to enable or disable the metadata specifically for the ENC product. There is no product-independent mechanism, however, to detect whether an object class is a metadata class or not.

Unified Domain Model integration

The LuciadLightspeed S-57 domain model provides full support for LuciadLightspeed’s Unified Domain Model:

The S-57 domain model is mapped onto the Unified Domain Model as follows:

  • Each S-57 object class is mapped onto a data type.

  • Each S-57 attribute type is mapped onto a primitive data type.

  • Each attribute of an S-57 object class is mapped onto a data property.

  • The feature geometry is accessible through the domain object’s ILcdShape interface. The object class data types have a TLcdShapeAnnotation indicating which shape types are available for that data type.

Table Table 2, “S-57 domain object classes” lists all S-57 attribute types with their mapping on the corresponding LuciadLightspeed primitive data type.

Table 2. S-57 domain object classes
S-57 attribute type LuciadLightspeed data type

Enumerated

extension of TLcdS57DataTypes.EnumeratedType

List

extension of TLcdS57DataTypes.EnumeratedType (collection property)

Float

TLcdCoreDataTypes.FLOAT_TYPE

Integer

TLcdCoreDataTypes.INTEGER_TYPE

Coded String

TLcdCoreDataTypes.CodedStringType

Free Text

TLcdCoreDataTypes.STRING_TYPE

TLcdS57DataTypes.EnumeratedType is an extension of TLcdCoreDataTypes.INTEGER_TYPE. An S-57 data model has a data type for each S-57 enumerated attribute, extending EnumeratedType. The values of properties with an enumerated type are of type Integer. You can retrieve a human-readable equivalent name for each value via property.getType().getDisplayName(dataObject.getValue(property)).