4.1  Overview of approach to implementing interoperability

Interoperability processing works in combination with regular portrayal processing (see IHO S-100 Part 9). Depending on the system architecture designed by developers of system software, it may for example function as a pre-processing or post-processing stage to regular portrayal processing.

An Interoperability Catalogue basically describes a transformation from an input stream of feature data to an output stream of prioritized feature data. The input stream consists of feature data from S-100 based datasets (either in the form of feature objects from the input data, or feature objects transformed to drawing instructions by portrayal processing). The output feature stream consists of feature data that may contain some input features in their original form; combine versions of other features; and remove other features from the stream altogether. Features in the output stream also have assigned (or revised) priorities in relation to other features, depending on feature type.

4.2  Overview of an Interoperability Catalogue

An Interoperability Catalogue is a collection of rulesets for filtering and/or combining feature objects from different input streams corresponding to different data products into feature objects in a combined output stream. The Interoperability Catalogue provides means of describing the conditions under which a ruleset is active — that is, each ruleset applies to a particular combination of products.

Within each ruleset, there may be rules whose antecedents specify the combinations of features from different products to which they apply, and what the result of applying the rule is; that is, given a particular combination of features in the input stream, what feature or features should be emitted into the output stream.

The interoperability processor applies the rules which are assigned to the loaded combination of data products, and outputs a stream of feature data which contains both original feature instances and any new instances, when applicable, which conform to new hybrid feature types that are defined in a Hybrid Feature Catalogue. The selection process is shown in Figure 4-1, and consists only of selecting the applicable predefined combination (PDC) that corresponds to the user or system settings and which lists exactly the currently loaded products. There should be only one applicable PDC after these steps; however, if there is a tie it must be broken by external tie-breaking methods such as allowing the user to select a combination based on the use conditions and description attributes of the PDC.

Figure 4-1 — Process for selecting rules

Product combinations are lists of data products. When associated with a ruleset or an individual rule, it means that the ruleset or single rule applies to the combinations of the data products listed. Each product combination may be assigned an interoperability level, if implemented, and descriptive attributes which indicate its purpose and applicability to the human end-user and catalogue developer. Levels are used to break up the functionality of the Interoperability Catalogue model into logical modules as appropriate for the use case. If the use case does not call for breaking up the functionality of the Interoperability Catalogue model only a single level 1 is required.

Display planes act as a means of layering features in the end-user’s display. Each feature in the output stream is assigned to a display plane. Each plane is assigned a display order relative to other planes. The Interoperability Catalogue uses display planes for interleaving features from different products, with features in higher priority planes overlying those in lower priority planes wherever they overlap. In the case of coincident or overlapping symbols, the implementer may use appropriate methods to avoid displaying partial symbols, or “grafting” part of lower-layer symbols onto symbols in upper layers.

The Interoperability Catalogue allows suppression of feature classes where the presence in one product of features of a given feature type causes the removal of all features of a specified feature type from another specified data product. This is supposed to be used when the two feature types represent the same kind of data but one data product is preferred over the other. For example, level of detail in the preferred data product, additional feature characteristics in the preferred product, etc.

The Interoperability Catalogue also allows suppression of feature instances whereby only feature instances meeting specified conditions are suppressed in favour of feature instances from a different product. The conditions are described in terms of specific characteristics such as attribute values or combinations of values of different attributes, or the use of specific classes of spatial primitives such as all point features of the specified type.

Advanced interoperability functionality includes hybridization of features. Hybridization consists of combining feature data from different products in the input stream into a new type in the output stream — new in the sense that the output feature type is not defined in any Feature Catalogue of the input products. Such combined types are intended for producing resultant features with enhanced characteristics, for example by enhancing the attribute set from one product with additional attributes derived from another data product.

The hybrid feature is defined in a hybrid Feature Catalogue (must comply with IHO S-100 Part 5) and its portrayal is defined in a hybrid Portrayal Catalogue (must comply with IHO S-100 Part 9) that is bundled with the Interoperability Catalogue in an exchange set.

4.3  Overview of processing

Interoperability processing can either precede or follow portrayal processing (except rendering, which converts feature data into graphics and is necessarily the step just before actual display). A mixed processing model, where interoperability processing is done both before and after portrayal processing, is also possible.

The two processing options described above are shown in Figure 4-2.

Figure 4-2 — Basic interoperability processing

In any level of processing except Level 0 (interoperability off), data products to be loaded are selected by the system according to the list in the predefined combination selected by the user selection from among those listed in the catalogue.

Feature data from products not listed in the Interoperability Catalogue are passed through to portrayal processing as described in IHO S-100 Part 9 (stage Portrayal Processing) without any intermediate stages in interoperability processing, and displayed by ordinary S-100 portrayal processing according to their individual Portrayal Catalogues.

4.4  Interoperability Catalogue Data Model

4.4.1  Introduction

The Interoperability Catalogue specifies the relative display prioritization of feature types and feature instances, as defined in individual Product Specifications, in relation to other feature types and feature instances, which may be defined in any of the data products declared to be within the scope of the Interoperability Catalogue.

An Interoperability Catalogue describes display planes, predefined combinations, feature instance and feature layer suppression rules.

The Interoperability Catalogue (IC) utilizes the ISO CT_Catalogue class defined in ISO/TS 19139 (implemented in ISO/TS 19115-3:2016) as a super-type for header information. The body of the Interoperability Catalogue consists of subsections encoding the rules for display planes, feature priorities, feature interleaving, and available predefined combinations:

• display planes, indicating order of planes, viewing group, and drawing priority;

• predefined combinations and operations on feature types or feature instances for each combination;

An Interoperability Catalogue must be an XML document which conforms to the Interoperability Catalogue Schema which can be downloaded from the IHO website. Figure 4-3 shows the Interoperability Catalogue model.

Figure 4-3 — Interoperability Catalogue Model

4.4.2  Interoperation conceptual types

The following clauses describe the different conceptual elements that may be used in an Interoperability Catalogue.

4.4.2.1  S100_IC_InteroperabilityCatalogue

An Interoperability Catalogue contains operations and rules for the interoperation of a set of S-100-based data products.

Table 4-1 — S100_IC_InteroperabilityCatalogue

Role Name	Name	Description	Mult	Type	Remarks
Class	S100_IC_InteroperabilityCatalogue	Class that holds header information about an Interoperability Catalogue	-	-	Specialization of CT_Catalogue (ISO/TS 19115-3:2016)
Attribute	description	Description of the catalogue	1	CharacterString
Attribute	comment	Any additional comments	0..1	CharacterString
Attribute	interoperabilityLevel	The highest level of interoperability functionality encoded within an instance of this type	0..1	Integer
Attribute	requirementType	The type of authority or requestor responsible for the specifications, rules, or requirements based on which this catalogue was prepared	1	Enumeration
Attribute	requirementDescription	Description of the source of the requirements or specifications upon which this catalogue is based. This might be the name of the country, company, OEM, port, pilot, etc	1	CharacterString
Attribute	productCovered	The products covered by this catalogue	2..*	dataProduct
Attribute	name	The name for the catalogue	1	CharacterString	Inherited from CT_Catalogue
Attribute	scope	Subject domain of the catalogue	1..*	CharacterString	Inherited from CT_Catalogue
Attribute	fieldOfApplication	Description of the use to which this catalogue may be put	0..*	CharacterString	Inherited from CT_Catalogue
Attribute	versionNumber	The version number of the Product Specification	1	CharacterString	Inherited from CT_Catalogue
Attribute	versionDate	The version date of the Product Specification	1	Date	Inherited from CT_Catalogue
Attribute	language	The language used for this catalogue	0..1	CharacterString	Inherited from CT_Catalogue
Attribute	locale	provides information about alternatively used localized character strings	0..1	PT_Locale (ISO 19115-1:2014)	Inherited from CT_Catalogue
Attribute	characterSet	Character set used in the catalogue	0..1	MD_CharacterSetCode (ISO 19115-1:2014)	Inherited from CT_Cataloguemust have value=utf8
Composition	displayPlanes	Container for one or more S100_IC_DisplayPlane elements	1..*	<sequence>S100_IC_DisplayPlane	Ordered list of one or more S100_IC_DisplayPlane elements
Composition	predefinedProductCombinations	Container for predefined product combinations and the interoperability operations for each	0..*	<sequence>S100_IC_PredefinedCombination	Sequence of S100_IC_PredefinedCombination elements
Composition	hybridizationRules	Container for hybridization rules	0..*	<sequence>S100_IC_HybridizationRule
Role	hybridFC	Reference to hybrid Feature Catalogue used by operations in this Interoperability Catalogue	0..*	CharacterString
Role	hybridPC	Reference to hybrid Portrayal Catalogue used by operations in this Interoperability Catalogue	0..*	CharacterString

4.4.2.2  S100_IC_DisplayPlane

A display plane element acts as a container for display information for specified feature classes. The display order for the plane as a whole is provided in the S100_IC_DisplayPlane element. All the types within an instance of S100_IC_DisplayPlane have the same display order (encoded in attribute order) relative to feature types in another instance of S100_IC_DisplayPlane. Instances of display plane can be characterized by interoperability level, which allows the encoding of different sets of operations depending on how tightly integrated the user desires the products to be on the resultant display.

Assigning feature types to display planes enables the interleaving of feature layers during portrayal by indicating the display plane, priority, and rendering order of the types assigned to a display plane. S100_IC_DisplayPlane assigns subsets of feature types to display planes and defines the viewing group, drawing priority, and significance for each feature type in the plane. An S100_IC_DisplayPlane element may include more than one feature type.

A feature type may be referenced in more than one S100_IC_DisplayPlane, but the entries in different display planes must be distinguished by different attribute-value combinations or spatial primitives so that the actual instances of features are partitioned unambiguously between different display planes.

The portrayal of feature types not mentioned in any S100_IC_DisplayPlane component is undefined until ordinary portrayal processing.

An instance of S100_IC_DisplayPlane must contain at least one instance of S100_IC_Feature or S100_IC_DrawingInstruction. An instance of S100_IC_DisplayPlane may contain both S100_IC_Feature and S100_IC_DrawingInstruction, subject to the constraint below.

For S100_IC_Feature and S100_IC_DrawingInstruction with the same combination of [featureCode, product, geometryType, and attributeCombination] and in the same S100_IC_DisplayPlane container:

• S100_IC_Feature.drawingPriority and S100_IC_DrawingInstruction.drawingPriority must have the same values.

• S100_IC_Feature.viewingGroup and S100_IC_DrawingInstruction.viewingGroup must have the same values.

Table 4-2 — S100_IC_DisplayPlane

Role Name	Name	Description	Mult	Type	Remarks
Class	S100_IC_DisplayPlane	Each display plane identifies all features and their drawing priority within the plane. The order in which display planes are rendered is also given.	-	-	Composition component of S100_IC_InteroperabilityCatalogue, container displayPlanes
Attribute	identifier	Unique identifier of the display plane	1	CharacterString	Must be unique
Attribute	name	Name of display plane	1	CharacterString	Under radar, over radar, etc.
Attribute	order	Used to sort the rendering order of display planes. Display planes with larger values are drawn above those with lower values.	1	Integer	Refer IHO S-100 Part 2b, Clause 2b-4.2.23 and IHO S-100 Part 9, Clause 9-11.1.5, IHO S-100 Part 9, Clause 9-13.3 and IHO S-100 Part 9, Clause 9-13.3.20 Positive: Above RADAR Zero: Reserved for RADAR Negative: Below RADAR
Attribute	description	description of the display plane	1	CharacterString
Attribute	interoperabilityLevel	The highest level of interoperability functionality encoded within an instance of this type	0..1	Integer
Composition	features	Container for S100_IC_Feature elements	0..*	<sequence>S100_IC_Feature	At least one S100_IC_Feature or S100_IC_DrawingInstruction element must be included in a display plane element
Composition	drawingInstructions	Container for S100_IC_DrawingInstruction elements	0..*	<sequence>S100_IC_DrawingInstruction	At least one S100_IC_Feature or S100_IC_DrawingInstruction element must be included in a display plane element

4.4.2.3  S100_IC_Feature

The S100_IC_Feature element describes the display parameters for all features of a specific feature type in a specific product. The S100_IC_Feature element determines the order of drawing the feature type identified by its featureCode attribute relative to other feature types in the same display plane. It also specifies the viewing group to which the feature is assigned. Its applicability can be optionally restricted to a subset of instances of the feature type by additional attributes that specify the type of spatial primitive and indicate specific values of thematic attributes.

The S100_IC_Feature element in Interoperability Catalogues is similar in operation to the layering and priority aspects of the DrawingInstruction element in Portrayal Catalogues (see IHO S-100 Part 9), and therefore has attributes that are equivalent to some of the attributes and roles of the Portrayal Catalogue element. Where there is an exact correspondence with a Portrayal Catalogue element, the element in the Interoperability Catalogue element supersedes the Portrayal Catalogue element. The correspondences are summarized in Table 5-1 at Section 5.

Table 4-3 — S100_IC_Feature

Role Name	Name	Description	Mult	Type	Remarks
Class	S100_IC_Feature	Information that guides the relative layering and drawing priority of feature types during portrayal	-	-
Attribute	identifier	Internal identifier of the catalogue element	1	CharacterString
Attribute	featureCode	The code assigned to the feature type in Feature Catalogue for the product indicated in the product attribute	1	CharacterString
Attribute	product	A data product	1	dataProduct
Attribute	geometryType	The type of spatial primitive that indicates the location	0..*	S100_FC_SpatialPrimitiveType
Attribute	attributeCombination	Describes attribute-value filters to be applied to the specified features	0..*	CharacterString	See Clause 4.4.3
Attribute	drawingPriority	Drawing priority of feature type in the display plane	1	Integer	Refer IHO S-100 Part 9, Clause 9-11.2.2
Attribute	viewingGroup	The viewing group of the feature type	1	Integer	Refer IHO S-100 Part 9, Clause 9-13.3
NOTE  S100_IC_Feature and S100_IC_DrawingInstruction elements operate in essentially the same way as far as assignment of drawing priority, and display planes is concerned. They differ in that S100_IC_DrawingInstruction provides an optional attribute to substitute the symbolization elements of the drawing instruction. S100_IC_Feature should be used for Interoperability Catalogues that are designed for systems where interoperability processing precedes the generation of drawing instructions. S100_IC_DrawingInstruction should be used for Interoperability Catalogues that are designed for systems where interoperability processing precedes the generation of drawing instructions. It should also be used in all catalogues where substitution of symbolization is necessary.

4.4.2.4  S100_IC_DrawingInstruction

Drawing instructions specify the display order used by the rendering engine in producing the portrayal output of a given feature type/geometric primitive type/attribute value combination. The S100_IC_DrawingInstruction element determines the order of drawing the feature type identified by its featureCode attribute relative to other feature types in the same display plane. The applicability of an S100_IC_DrawingInstruction to feature types can be further restricted by the type of spatial primitive and values of thematic attribute, using geometryType and attributeCombination attributes of the S100_IC_DrawingInstruction class.

The S100_IC_DrawingInstruction element in Interoperability Catalogues is similar in operation to the layering and priority aspects of the DrawingInstruction element in Portrayal Catalogues (see IHO S-100 Part 9), and therefore has attributes that are equivalent to some of the attributes and roles of the Portrayal Catalogue element. Where there is an exact correspondence with a Portrayal Catalogue element, the element in the Interoperability Catalogue element supersedes the Portrayal Catalogue element. The correspondences are summarized in Table 5-1 in Section 5. (Definitions of the Portrayal Catalogue attributes are provided in IHO S-100 Part 9).

The S100_IC_DrawingInstruction element contains the substituteSymbolization attribute that allows substitution of symbolization instructions generated by portrayal processing. Note that the display instruction XML elements defined in the presentation XML Schema IHO S-100 Part 9 (pointInstruction, lineInstruction, etc.) cannot be used directly because, being extensions of the base type DrawingInstruction in that Schema, they: (a) reference individual feature and spatial instances, and (b) contain viewing group, display plane, and drawing priority as mandatory elements, which would be redundant.

Table 4-4 — S100_IC_DrawingInstruction

Role Name	Name	Description	Mult	Type	Remarks
Class	S100_IC_DrawingInstruction	Information that guides the relative layering and drawing priority of drawing instruction during portrayal.	-	-
Attribute	identifier	Internal identifier of the instruction group	1	CharacterString
Attribute	featureCode	The code assigned to the feature type in Feature Catalogue for the product indicated in the product attribute	1	CharacterString	Corresponds to the feature reference for drawing instructions in IHO S-100 Part 9
Attribute	product	A data product	1	dataProduct
Attribute	geometryType	The type of spatial primitive that indicates the location	0..*	S100_FC_SpatialPrimitiveType
Attribute	attributeCombination	Describes attribute-value filters to be applied to the specified features	0..*	CharacterString	See Clause 4.4.3
Attribute	drawingPriority	The drawing priority of the group	1	Integer	Refer IHO S-100 Part 9, Clause 9-11.2.2
Attribute	viewingGroup	The viewing group of the feature type	1	Integer	Refer IHO S-100 Part 9, Clause 9-13.3
Attribute	substituteSymbolization	Substitute for the symbolization content of drawing instructions. This can be any element of the drawing instruction not defined in the abstract class DrawingInstruction defined in IHO S-100 Part 9, Clause 9-11.2, but defined in the relevant descendant of that class	0..1	CharacterString	The string must consist of one or more XML fragments constructed according to the Presentation Schema in IHO S-100 Part 9 or the equivalent in a non-XML syntax. A CDATA section may be used to avoid the explicit encoding of character entities for special characters
NOTE  Even if the Presentation Schema in IHO S-100 Part 9 is used, specific code may need to be provided to validate the content of the substituteSymbolization attribute instead of depending on purely XML Schema validation. The content of this attribute is not prescribed by this specification and may be a fragment of XML, or interpretable code or rules, etc., in a non-XML syntax. It may be enclosed in a <![CDATA[…​]]> section so that XML validators treat it as character data instead of XML. If the content is XML, it must be well-formed (for example have balanced opening and closing tags).

4.4.2.5  S100_IC_SuppressedFeatureLayer

Each instance of this element identifies a feature type in a specific data product.

Table 4-5 — S100_IC_SuppressedFeatureLayer

Role Name	Name	Description	Mult	Type	Remarks
Class	S100_IC_SuppressedFeatureLayer	Describes operations for suppressing all instances of a feature type in one product by features from another product	-	-
Attribute	identifier	Internal identifier of the catalogue element	1	CharacterString
Attribute	featureCode	Feature type code in the FC for the product mentioned in attribute product	1	CharacterString
Attribute	product	The data product for the type being replaced	1	dataProduct
Role	featureRef	References to replacement features’ display specifications in the display planes section of the Interoperability Catalogue	0..*	<reference>S100_IC_Feature	Replacement by multiple feature types is intended for associated feature types, for example different feature types that make up a traffic separation scheme.
Role	drawingInstructionRef	Reference to S100_DrawingInstruction element	0..*	<reference>S100_IC_DrawingInstruction
NOTE 1  Only one of featureRef or drawingInstructionRef can be used in an instance. NOTE 2  If both feature and drawing instruction references are empty, the type is suppressed without being replaced.

4.4.2.6  S100_IC_PredefinedCombination

A predefined combination element defines a collection of data products for which a common set of interoperability operations have been defined in the Interoperability Catalogue. Instances of predefined combinations can be characterized by interoperability level, which allows the segmentation of different sets of interoperability operations depending on how tightly integrated the user desires the products to be on the resultant display, see Section 8 for more details.

Predefined combination element can specify the following types of interaction between its listed products.

• Operations on selected instances of a feature type or conversion of input feature data into new feature data involving only thematic attributes.

• Operations involving operations on spatial attributes and possibly thematic attributes as well.

The simplest operations on instances are replacement of selected instances from one product by selected instances from another product. These are described by associated S100_IC_SuppressedFeatureInstance elements. More complex operations, including conversion of input feature instances into new features (hybridization) are described by associated S100_IC_HybridFeature elements. The replacement and hybridization rules are described in Section 6.

Predefined combinations can be linked to S100_IC_DisplayPlane elements by means of references in the S100_IC_PredefinedCombination elements.

Table 4-6 — S100_IC_PredefinedCombination

Role Name	Name	Description	Mult	Type	Remarks
Class	S100_IC_PredefinedCombination	Pre-defined combinations are identifiable pre-set collections of recommended and optional S-NNN data products which are expected to be loaded by the user under specific conditions or for specified tasks. Each pre-defined combination is basically a package of data products, display priorities, context parameters, user settings, Portrayal Catalogues, etc.	-	-	Composition component of S100_IC_InteroperabilityCatalogue
Attribute	identifier	Identifier of the predefined combination	1	CharacterString	For example, a sequence number, UUID or URN unique to the PDC in the catalogue. May be globally unique, but must be unique within the catalogue at least
Attribute	name	Name of combination	1	CharacterString
Attribute	description	Brief description of combination	1	CharacterString
Attribute	useConditions	Conditions for which the combination is designed	1	CharacterString
Attribute	interoperabilityLevel	The highest level of interoperability functionality encoded within an instance of this type	0..1	Integer
Attribute	includedProduct	Products loaded in this combination and referenced by operations and rules that apply to this combination	2..*	dataProduct	A combination must use at least 2 data products
Role	displayPlaneRef	Reference to an S100_IC_DisplayPlane element in this Interoperability Catalogue	0..*	<reference>S100_IC_DisplayPlane
Composition	derivedFeatures	Container for S100_IC_SuppressedFeatureInstance or S100_IC_HybridFeature elements (concrete specializations of S100_IC_FeatureDerivation)	0..*	<sequence> of sub-classes of S100_IC_FeatureDerivation
Composition	suppressedFeatureLayers	Container for S100_IC_SuppressedFeatureLayer	0..*	<sequence> S100_IC_SuppressedFeatureLayer
NOTE  A system can allow the user to initiate the loading of multiple data products and activate multiple parameter settings as a single action, by selecting from a list of pre-defined combinations, instead of loading and unloading individual data products.

4.4.2.7  S100_IC_FeatureDerivation

S100_IC_FeatureDerivation is an abstract super-class for different types of feature hybridization operations.Individual primary and secondary inputs are suppressed from being rendered and only the resulting derived feature is added to the data stack.

The resulting derived feature does not need to have any hybrid characteristics, that is, one restricted area replaced with another restricted area will use the regular PC/FC of the primary product. However, if the result feature needs to be supported by any custom FC or PC elements, they must be defined under hybrid FC and hybrid PC accordingly.

A rule for creating the feature must be described in the rules section

Table 4-7 — S100_IC_FeatureDerivation

Role Name	Name	Description	Mult	Type	Remarks
Class	S100_IC_FeatureDerivation	Derived features are created by consolidating features from 2 or more different products into one final view, so the changes can include geometry, attribution and/or portrayal (depending on the interoperability level)	-	-	Abstract class.
Attribute	identifier	Internal identifier of the catalogue element	1	CharacterString
Attribute	primaryProduct	One of the two interoperating data products	1	dataProduct
Attribute	primaryFeatureCode	Feature type code in the FC for the product mentioned in primaryProduct	1	CharacterString
Attribute	primarySelector	Selection expression for instances of the first feature type	0..1	FeatureSelector	If omitted, all instances of the type are included. Example 1: categoryOfObstruction = 5 Example 2: waterLevelEffect = 4 AND WITHIN(<primary>, <secondary>)
Attribute	secondaryProduct	The other interoperating data product	1	dataProduct
Attribute	secondaryFeatureCode	Feature type code in the FC for the product mentioned in secondaryProduct	1	CharacterString
Attribute	secondarySelector	Selection expression for instances of the second feature type	0..1	FeatureSelector	If omitted, all instances of the type are included. EXAMPLE 1 expositionOfSounding = 3 EXAMPLE 2 categoryOfPile = 2 AND WITHIN(<primary>, <secondary>)
Attribute	outputProduct	Data product of the resulting hybrid feature	1	dataProduct	Default value = HYBRID, to indicate the result is a hybrid feature. This is a default — it can be set to other allowed values from the dictionary in specific cases.
Attribute	outputFeatureCode	Feature type code in the hybrid FC	1	CharacterString
Role	featureRef	Reference to the output feature’s display specification in the display planes section of the Interoperability Catalogue	1	<reference>S100_IC_Feature

4.4.2.8  S100_IC_SuppressedFeatureInstance

S100_IC_SuppressedFeatureInstance is a class for suppressing feature instances according to attribute combinations in one product with features instances in another product. The primary product attribute combination specifies the feature instance(s) that will be replaced. The secondary product combination is the product to replace the suppressed instance(s) and should be identical to the output product attribute combination. If two different set of features instances are to be suppressed by one common set of feature instances, two instances of S100_IC_SuppressedFeatureInstance are needed.

Table 4-8 — S100_IC_SuppressedFeatureInstance

Role Name	Name	Description	Mult	Type	Remarks
Class	S100_IC_SuppressedFeatureInstance	Operations for replacement of feature instances in one product by instances in another product.	-	-	Sub-class of S100_IC_FeatureDerivation The “secondary” product replaces the “primary”.
Role	creationRule	Reference to a rule defined in the hybridization rules section of the catalogue	0..1	<reference>S100_IC_SimpleRule
NOTE  If attributes bindings of the output are the same as secondary product type, the outputProduct and outputFeatureCode should be the same as the secondaryProduct and secondaryFeatureCode. If the attribute bindings change in a way that is incompatible with the Feature Catalogue for the secondary product, S100_IC_HybridFeature must be used instead.

4.4.2.9  S100_IC_HybridFeature

S100_IC_HybridFeature is a class for selecting primary and secondary inputs that will be suppressed from being rendered and replaced by a feature derived from the inputs.

Table 4-9 — S100_IC_HybridFeature

Role Name	Name	Description	Mult	Type	Remarks
Class	S100_IC_HybridFeature	Class used to create a feature by combining feature types from two or more products for the purposes of an interoperable display	-	S100_IC_FeatureDerivation	Sub-class of S100_IC_FeatureDerivation
Role	creationRule	Reference to a rule defined in the hybridization rules section of the catalogue	0..1	<reference>S100_IC_CompleteRule
Role	creationRule	Reference to a rule defined in the hybridization rules section of the catalogue	0..1	<reference>S100_IC_ThematicRule
NOTE  Only one creationRule can be used in an instance.

4.4.2.10  S100_IC_HybridFeatureCreationRule

S100_IC_HybridFeatureCreationRule is an abstract super-class for different types of hybridization rules. This functionality needs to be worked out but OGC Filter seems to be the ideal option for defining data filtering logic. Overall, the output from execution of S100_IC_HybridFeatureCreationRule is a set of hybrid features for which predefined FC, PC and display plane definitions already exist so such feature will be suitable for passing to the portrayal engine for processing just like any other S-100 features. Instances of S100_IC_HybridFeatureCreationRule can be characterized by interoperability level, which allows the segmentation of different sets of interoperability operations depending on how tightly integrated the user desires the products to be on the resultant display, see Section 8 for more details.

Table 4-10 — S100_IC_HybridFeatureCreationRule

Role Name	Name	Description	Mult	Type	Remarks
Class	S100_IC_HybridFeatureCreationRule	Class to capture hybrid feature creation rule captures the entire data filtering logic (that is, finding all features to be operated on) as well as the entire processing logic.	-	-	Abstract class
Attribute	interoperabilityLevel	The highest level of interoperability functionality encoded within an instance of this type	0..1	Integer
Attribute	ruleIdentifier	Rule identifier	1	CharacterString	Mandatory unique ID used for references

4.4.2.11  S100_IC_CompleteRule

This class is used for rules describing how a set of feature instances is combined to create a hybrid feature type. Complete rules may operate on both thematic and spatial attributes.

Table 4-11 — S100_IC_CompleteRule

Role Name	Name	Description	Mult	Type	Remarks
Class	S100_IC_CompleteRule	Class to capture rule describing how a set of feature instances is combined to create a hybrid feature type.	-	-	Subclass of S100_IC_HybridFeatureCreationRule

4.4.2.12  S100_IC_ThematicRule

This class is used for rules describing how a set of feature instances is combined to create a hybrid feature type. Thematic rules may operate on only thematic attributes. The input features are required to have spatially equal geometry within a tolerance set by the system.

Table 4-12 — S100_IC_ThematicRule

Role Name	Name	Description	Mult	Type	Remarks
Class	S100_IC_ThematicRule	Rule describing how aset of feature instances is combined to create a hybrid feature type.	-	-	Subclass of S100_IC_HybridFeatureCreationRule

4.4.2.13  S100_IC_SimpleRule

This class is used for rules describing how a set of feature instances is combined to create a hybrid feature type. Simple rules may operate only on thematic attributes. Simple rules treat thematic attributes uniformly during hybridization and therefore do not mention specific attributes. Location/extent spatial attributes of all input features must be spatially equal.

Table 4-13 — S100_IC_SimpleRule

Role Name	Name	Description	Mult	Type	Remarks
Class	S100_IC_SimpleRule	Rule describing how a set of feature instances is combined to create a hybrid feature type	-	-	Subclass of S100_IC_HybridFeatureCreationRule

4.4.2.14  S100_IC_HybridFC

Class for holding reference to a Feature Catalogue defining any “hybrid feature types” that are created by combining feature types from two or more products for the purposes of an interoperable display.

Table 4-14 — S100_IC_HybridFC

Role Name	Name	Description	Mult	Type	Remarks
Class	S100_IC_HybridFC	Feature Catalogue defining any “hybrid feature types” that are created by combining feature types from two or more products for the purposes of an interoperable display.	-	S100_FC_FeatureCatalogue	The Interoperability Catalogue contains references to local resources (files) containing hybrid Feature Catalogues
Attributes and Roles	(See IHO S-100 Part 5)

4.4.2.15  S100_IC_HybridPC

Class for holding reference to a Portrayal Catalogue defining portrayal rules for the “hybrid feature types” defined in a Hybrid Features Catalogue.

Table 4-15 — S100_IC_HybridPC

Role Name	Name	Description	Mult	Type	Remarks
Class	S100_IC_HybridPC	Portrayal Catalogue defining portrayal rules for the “hybrid feature types” defined in a Hybrid Features Catalogue.	-	(IHO S-100 Part 9) PortrayalCatalog	The Interoperability Catalogue contains references to local resources (files or folders) defining hybrid PCs
Attributes and Roles	(See IHO S-100 Part 9)

4.4.2.16  FeatureSelector

A data type for holding a template, logical expression, or match condition that, given a feature instance as parameter, can be evaluated to produce a TRUE/FALSE result.

Table 4-16 — FeatureSelector

Type	Name	Description	Derivation	Remarks
datatype	FeatureSelector	A template, logical expression, or match condition that, given a feature instance as parameter, can be evaluated to produce a TRUE/FALSE result	subtype of CharacterString	Example: XSLT match condition
NOTE  Format and expression language must be defined in the implementation.

4.4.2.17  requirementType

A code list for sources of the Interoperability Catalogue or the person or party according to whose recommendations the catalogue was prepared.

Table 4-17 — requirementType

Item	Name	Description	Code	Remarks
S100_Codelist	requirementType	The source of the catalogue or the person or party according to whose recommendations the catalogue was prepared	-
Literal	IHO	Original IHO Interoperability Catalogue	1
Literal	OEM	Prepared according to requirements specified by OEM or systems integrator	2
Literal	national	Prepared according to requirements specified by a national government, group of national governments (for example the European Union), or governmental agency such as a national shipping authority or the Coast Guard.	3
Literal	local	Prepared according to requirements specified by a sub-national governmental authority such as a state, province, or county	4
Literal	port	Prepared according to requirements specified by a harbormaster’s office or port authority	5
Literal	company	Prepared according to requirements specified by the owner, charterer, or operator	6
Literal	pilot	Prepared according to requirements specified by the vessel’s master	7
Literal	master	Prepared according to requirements specified by a pilot	8
Literal	other	Other source	9

Codelist Type: open enumeration

Encoding for extra values: other: <CharacterString> (Format of <CharacterString>: ( [a-zA-Z0-9])* — See IHO S-100 Part 3, Clause 3-6.7).

4.4.2.18  dataProduct

A closed dictionary codelist of S-100 based products.

The allowed values are defined in the dictionary file, which is a component of individual interoperability specifications implementing this Part. If any operations or rules in an Interoperability Catalogue produce a hybrid feature, one of the entries in the dictionary must correspond to a notional “HYBRID” data product for such features.

Table 4-18 — dataProduct

Item	Name	Description	Code	Remarks
S100_Codelist	dataProduct	List of data products	-	Data products conforming to the Specification identified by the item name, in the IHO list of S-100 based Product Specifications. This is a closed dictionary codelist (see IHO S-100 Part 1, Clause 1-4.8, IHO S-100 Part 3, Clause 3-5.3.11, IHO S-100 Part 3, Clause 3-6.7).
Literal(s)	(see individual specifications)	…​	…​	…​

Codelist Type: closed dictionary, URI format: urn:mrn:…​

URI tags must be fully specified in the implementation specification. E.g. urn:mrn:iho:prod:s98:1:0:0:products for a master list of products that is specified in S-98 as being covered by S-98 Version 1.0.0 Interoperability Catalogues.

The dictionary format used in Interoperability Catalogues is the ISO/TS 19115-3:2016 “codelist catalogue” format. An example using this format is depicted in Figure 4-4. The whole data products codelist is contained in the CT_Codelist XML element, identified by the XML ID “urn.mrn.iho.prod.s98.1.0.0.products” (the id attribute of CT_Codelist). Individual data products are listed in codeEntry elements within the CT_Codelist, identified by their own id attributes. In the example, S-101 is identified by the XML ID “s101” in the expanded codeEntry element. Note that the “:” characters in the codelist URI are replaced by “.” in the corresponding XML id elements, due to XML syntax constraints. The combination of id values of CT_Codelist and CT_CodelistValue elements is sufficient to identify a data product within a given dictionary file. The name (or other identifier) of the dictionary file must be specified in the individual interoperability specification. The Product Specification must also describe how dictionary files are made available to individual end user systems.

Figure 4-4 — Example of data products dictionary entry

7.1  Geographic feature types

The relative prioritization for display purposes of geographic feature types is at the core of the Interoperability Catalogue Data Model. For the Interoperability Catalogue concept, feature types can be considered as the “domain” of the Data Model, just as feature concepts form the domain of an ordinary Product Specification.

Feature instances are not encoded in Interoperability Catalogues since an Interoperability Catalogue is a catalogue-based product that is functionally a collection of rules which adjust the display of information from feature datasets; an Interoperability Catalogue is not itself a feature-based data product.

References to feature types may appear as attribute values in Interoperability Catalogues. The reference will identify the Product Specification in which the feature type is defined. It may also identify the version of the Product Specification; if the version is not identified the reference is to the indicated feature type in all versions of the Product Specification.

A reference to a feature type must be interpreted as applying to all instances of the feature type in datasets conforming to the indicated Product Specification and version. (Additional conditions limiting applicability to subsets of feature instances may be encoded in other attributes.)

7.2  Meta feature types

The suppression, interleaving, and replacement operations in the Interoperability Catalogue do not affect meta features in individual Product Specifications. Display of meta features if requested by the mariner is as specified by individual Portrayal Catalogues.

7.3  Feature and Information associations

Feature and information associations are not directly used in an Interoperability Catalogue.

7.4  Information types

Information types are not directly used in an Interoperability Catalogue.

9.1  Simple hybridization rule

Simple rules treat thematic attributes uniformly, for example by binding the attributes of both primary and secondary input instances to the output instance, or preferring the attribute bindings of the primary instance to those of the secondary instance in case of a difference in the values of common attributes. Location/extent spatial attributes of all input instances must be spatially equal and are passed through unchanged.

9.2  Thematic hybridization rule

Thematic rules treat thematic attributes on an individual basis, for example, use specified attributes from the primary input instance and specified attributes from the secondary input instance. Combination operations on attribute values may be specified, for example, OutputFeature.depthValue = maximum(ProductA.FeatureX.depthValue, ProductB.FeatureY.depthValue. Location/extent spatial attributes of all input instances must be spatially equal and are passed through unchanged.

9.3  Complete hybridization rule

Complete rules allow selection of input sets using complex spatial queries as well as spatial equality and selector expressions on attribute values. The output can combine thematic attributes in any of the ways allowed by thematic hybridization rules. In addition, it may generate complex spatial objects from the input spatial primitives by applying selected spatial operations to the input instances. The allowed spatial operations will be identified in a future edition of this specification (tentatively, the spatial operations defined in S-58, Section 2).

9.4  Hybrid Feature and Portrayal Catalogues

Hybrid Feature and Portrayal Catalogues are physically separate files from the main Interoperability Catalogue, but the main Catalogue links to them by encoding the names of the hybrid catalogue files which are used by the feature creation rules defined in it. The hybrid Feature and Portrayal Catalogues conform to the structures required by IHO S-100 Part 5 and IHO S-100 Part 9 respectively. It is recommended that hybrid Feature and Portrayal Catalogues be bundled with the Interoperability Catalogue in an exchange set as support files, see Section 10 below.

10.1  Management of Feature Catalogue and Portrayal Catalogues updates

Changes to a supported Product Specification may have impacts on an Interoperability Catalogue. Revisions to the Feature Catalogue or Portrayal Catalogue are the most likely to require a revision of the Interoperability Catalogue in order to support the change. These types of changes will generally require a new version (n.n.0) of the Interoperability Catalogue to ensure support. It should be noted that revisions to a supported Feature Catalogue or Portrayal Catalogue may be ignored by previous versions of an Interoperability Catalogue and it is therefore necessary to consider this as part of the change management process, especially if the change is a matter of navigational safety. Major changes to Product Specifications, such as adding functionality or adding new Product Specifications to the supported list will result in a new edition (n.0.0) of an Interoperability Catalogue.

Versions of an Interoperability Catalogue within the same edition are considered a compatible group. When a New Edition is issued, this compatibility is broken; and efforts should be undertaken to update all impacted systems as soon as possible.

Figure 10-1 — Examples of how Feature Catalogue change may impact Interoperability Catalogue lifecycle

Several types of changes to supported Product Specifications may impact an Interoperability Catalogue in such a way that a new version is needed to maintain full support. These include:

Adding new functions in either a supported Product Specification or an Interoperability Specification may require a new version of an Interoperability Catalogue.

10.2  Product Specification updates other than FC/PC

Updates to dataset metadata, such as Product Specification references, may impact the link between a dataset and an Interoperability Catalogue and therefore require a revision to the Interoperability Catalogue (n.n.0). Some changes to an interoperability-ready Product Specification may not require any changes to an Interoperability Specification or an Interoperability Catalogue. This includes amendments to the definitions of features, attributes or attribute values. It also includes minor changes to Product Specifications, such as clarifying language. Other changes may only require an update to the metadata of an Interoperability Specification and/or Interoperability Catalogue, such as in case of supported Product Specification version references. Such minor changes to an Interoperability Specification and/or Interoperability Catalogue may be collected and be applied at a later time when a more substantial revision is required.

10.3  Unpredictable Product Specification updates

Unpredictable changes to an interoperability-ready Product Specification, or its Feature Catalogues and Portrayal Catalogues, should be avoided. Great care should be taken in coordinating changes among all stakeholders to avoid any unforeseen consequences. Product Specifications that are under the same interoperability umbrella should be considered interconnected. The responsible groups should therefore coordinate changes with other groups that issue interoperability-ready Product Specifications. Such coordination can be done, for example, by having an agreed fixed period between releases in which all pending changes are collected, implemented and issued in a coordinated fashion.

10.4  Additional data products to be defined in the Catalogue

An Interoperability Catalogue should in theory be extensible to products not yet defined, provided these are within the same S-100 Edition. New products can be included in a Catalogue, but such scenarios will require a New Edition of an Interoperability Catalogue. The default processing for any Interoperability Catalogue is that any new product follows the default rule of being used as an overlay, generally stacked in a user defined order and with default viewing groups in effect.

10.5  Backward compatibility

Different versions of data products may be simultaneously active; the Interoperability Catalogue design allows for backward-compatible updates if and when the Interoperability Catalogue has to be updated, within the same major Edition. Figure 10-2 below shows an example of how the Interoperability Catalogue may evolve with change over time.

Figure 10-2 — Example life cycle of Interoperability Catalogue

10.6  Interoperability Catalogue product

Each Interoperability Catalogue product should by itself be considered a whole unit. New versions — either clarification, correction, or New Edition — should be updated by replacement with a newer version. The update process should be specified in detail when defining an Interoperability Specification. The following clauses give some principles to consider for the specific update process.

10.7  Support files

Support files to an Interoperability Catalogue are generally the hybrid Feature Catalogues and hybrid Portrayal Catalogues. Methods for managing these are described below.

11.1  Display of significant features

Significant features in a display plane should have the highest drawing priority value within the S100_IC_DisplayPlane. Care should also be given to assigning significant features with high drawing priority values within the relevant S100_IC_Feature and S100_IC_DrawingInstruction. This ensures that less significant features in one data product are not displayed more prominently than more significant features in another product.

11.2  Impacts on viewing groups

The viewing group is a concept to control the content of the display. It works as an on/off switch for any drawing instruction assigned to the corresponding viewing group. The concept can be seen as a filter on the list of drawing instructions [IHO S-100 Part 9, Clause 9-11.1.3].

Viewing groups in Interoperability Catalogues take precedence over the applicable viewing groups for any feature instances from a supported Product Specification, and that are included in a S100_IC_DrawingInstruction, or S100_IC_Feature instance.

11.3  Impacts on Portrayal Catalogues

Viewing systems must manage the visibility and drawing order of data products, especially relative to radar/ARPA, AIS display or other sensor data. Moreover, systems must ensure significant features with over radar flag, in all products, are distinguishable in the presence of radar/ARPA, AIS or other sensor data. In navigation systems tracks and vessel position information are likely high priority while some AIS ASM (application specific messages) may carry lower-priority information, including data described by an S-100 based Product Specification, for example meteorological and hydrographic information.

11.4  Meta-features

It is recommended that viewing systems allow display of meta features for only one product at a time. This is in order to minimize risks of display clutter, user confusion, and the possibility of interpreting meta-features for one product as applying to a different product.

For example, data quality meta features for different on-screen products should not be displayed simultaneously, and that only the top most product data quality should be shown at any given time. This also applies in areas of the screen where the topmost product does not cover.

11.5  Display of text

Text is typically the last item drawn. In general, rules for placement, display selection, and management of long text are defined in the individual Product Specification and associated Portrayal Catalogue. An Interoperability Catalogue would, in general, only govern when a feature that text is generated from is displayed.

11.6  Blended feature concepts or blended portrayals

This clause describes the interoperability solution for blended feature or blended portrayal. These can be produced by using transparency or creating a temporary blended feature or blended portrayal (rule and/or symbol) of specific combinations of features from different products. Such blended concepts will typically be created by using S100_IC_PredefinedCombination which links to a hybrid Portrayal Catalogue that includes the features to be combined and a suppression rule (using S100_IC_SuppressedFeatureLayer) for the features that are to be replaced.

An example where a blended concept could be used is where winds blowing from the west cause fairways to some west coast ports of Finland to get layered ice (wind pushes ice layers on top of each other until there is ice from the sea bottom up to the surface). When an ice-breaker makes a path through some ice remains between the sea bottom and the keel of the ice-breaker. Ice thickness in such a place could be up to 11 m while the ice-breaker draught is around 7-8 meters. In such cases a simultaneous display of both ice coverage and underlying depth area is required. Other depth area features such as spot soundings, rocks, wrecks, etc., are also still important.

11.7  Blended portrayal’s effect on symbols and area patterns

When combining various layers, that may be of different compilation scale and coverage, it is likely that symbols and area patterns will end up at borders, or conflict with symbols and area patterns in other layers. It is important that symbols remain legible, and that user systems include appropriate methods to avoid displaying partial symbols, or “grafting” part of lower-layer symbols onto symbols in upper layers.

For area fills the symbols of a pattern fill must be closer together for a small or narrow area, to ensure enough symbols are seen, and farther apart for a large area, to avoid clutter. An area pattern may be substituted by a single centred symbol if sufficient space is not available for a pattern to be shown.

11.8  Hierarchy of data

Hierarchy between different Product Specifications is influenced by several factors such as intended use within the in-scope user system, for example usefulness a product in navigational operation in a navigation system. It may not be possible to prescribe a fixed hierarchy list as a universal standard, and the Interoperability Catalogue model therefore offers a flexible approach. Within the Interoperability Catalogue the hierarchy of data between different S-100 based Product Specifications is determined using predefined combinations. The S100_IC_DisplayPlanes referenced within a S100_IC_PreDefinedCombination give the order of feature layers. This approach also allows for different stacking orders of the same products within the same Interoperability Catalogue should there be a user need for this. Care should be used (for example by using descriptive names and allowing users to see these when selecting) to ensure the risk of users unintentionally selecting the wrong stacking order.

11.9  Interacting gridded information

If two or more gridded data types are to interact, the hierarchy between them should be established using predefined combinations as with other data types. Particular care has to be taken depending on how the presentation of the data is to be done when deciding which gridded data type has the highest priority, considering items such as will one gridded data type obscure the other.

For example, gridded bathymetry may obscure gridded surface currents and therefore the gridded surface currents should be given the highest priority between the two when they are to be displayed simultaneously.

11.10  Pick reports

Pick reports may be defined in the individual Product Specification. The Interoperability Catalogue model permits reuse of these specifications as it does not specify pick report design for the individual supported Product Specification.

Complete data from all products visible on the screen should be available to the system user, irrespective of all these products being in the scope of the Interoperability Catalogue in use or not.

Features that have been visually suppressed should not be included in the pick report.

11.11  User control over loaded set

It is recommended that users have the option to load additional products in scope for the system, even when these are out of scope for the Interoperability Catalogue, or turn off one or more of the data products in a predefined combination. Portrayal must adjust to the loaded set as appropriate, for example if an additional product is loaded, it should be interleaved with layers from data products in the predefined combination according to the drawing order and drawing priority in its Portrayal Catalogue.

11.12  User control over interoperation level

If more than one interoperability level is supported by the Interoperability Catalogue (see Section 8), it is recommended that users have the option to select the interoperability levels they wish to use. Portrayal must adjust to the new interoperation level.