S-131 MHI Best Practices

Limitation by Vessels Characteristics and Cargo

(Source - S-131 Edition 1.0.0 DCEG)

Capturing the application of a regulation, recommendation, etc. to specified kinds of vessels

This will generally be modeled by an InclusionType relationship between the abstract supertype AbstractRxN (as the superclass for Regulations, Restrictions, Recommendations, and NauticalInformation information type classes) and the Applicability class.

Encoders may find it easiest to capture the application of a regulation (recommendation , etc.) to a class or set of vessels in three phases:

1. Encode the operative part of the regulation (the part that describes what the vessels subject to the regulation must or must not do), creating an instance of Regulations (or Recommendations, etc., as appropriate). Descriptions of what kinds of vessels are subject to the regulation must be excluded from the content of the Regulation instance.
2. Create an Applicability information type and encode the description of what kinds of vessels are subject to (or exempted from) the regulation.
3. Link the two using an InclusionType with membership=included if the vessels described by Applicability are subject to the regulation, or membership=excluded if they are explicitly exempted from the regulation.

It is not necessary to create separate instances of the regulation for inclusion and exclusion.

Capturing the permissibility or otherwise of a geographic feature for specified kinds of vessels

Encoders may find it easiest to capture the permissibility of a feature to specified kinds of vessels in three phases.

1. Create the geographic feature if it does not already exist.
2. Create an Applicability information type and encode the description of what kinds of vessels are required to use the geographic feature.
3. Link the two using a PemissionType with categoryOfRelationship = required.

For the other relationships (prohibited, not recommended, etc.) steps 2 and 3 should be modified accordingly (i.e., if use by certain kinds of vessels is “not recommended” encode the description of that kind of vessels in an Applicability and create a linking PermissionType with categoryOfRelationship = not recommended). It is not necessary to create a separate instance of the geographic feature for each type of relationship.

Constructing the Applicability information type

Where the source material describes complex conditions, encoders may find it useful to write out the conditions in structured language with grouping parentheses, for example, as “(condition A) AND (condition B) AND (condition C)”, or draw diagrams, before encoding Applicability and its associations.

Note that the model limitation on mixing logical connectives means some forms of conditions which use “nesting” cannot be encoded in a single Applicability instance and multiple instances must be created.

EXAMPLE: The complex condition “(condition A) AND ((condition B) OR (condition C))” must be encoded as two Applicability instances, one with “(condition A) AND (condition B)” and the other with “(condition A) AND (condition C)”.

Example of conversion of complex condition to multiple simple conditions

Complex condition	Encode as
(condition A) AND ((condition B) OR (condition C))	Applicability 1: (condition A) AND (condition B) Applicability 2: (condition A) AND (condition C)

Data producers may contact NIPWG with questions about encoding complex conditions.

As a last resort, conditions may be written as phrases in natural language and encoded in the information attribute. It is acceptable for an Applicability to have only the information attribute populated.

Textual Regulations and Notes

(Source - S-131 Edition 1.0.0 DCEG)

Use of appropriate information type

The appropriate information type from Regulations, Restrictions, Recommendations, and NauticalInformation should be used depending on the nature of information to be encoded.

1. Regulations is intended to be used for official rules, laws, and similar source material, i.e., sources that have the force of law or are mandated by a controlling authority. They will generally originate from some kind of administration or authority, including port authorities.
2. Restrictions is intended for restrictions that constrain the activities of vessels temporarily with or without the legal force, or for longer terms without the force of law; they may be issued by a local authority such as a port captain or US Coast Guard district.
3. Recommendations is intended for encoding suggestions, limitations, or preferred procedures that are not mandatory.
4. NauticalInformation is intended for material that is largely informative in nature, of which does not fit into the category of regulation, recommendation, or restriction.

Content

The content of the regulation (or recommendation, restriction, or note) should be encoded using the textContent attribute. Text content should be compact and accessible to the expected audience, and include pertinent information, in summary form if necessary. Generally, avoid including the entire text of regulations where it is complex in structure or unncessarily legalistic or verbose. Instead, condense long regulations or notes into a summary, include exceptions not covered by the summary, and include a reference where the full details can be obtained. References should be accessible to mariners, so they can obtain the complete text.

Textual content may be supplemented by one or more diagrams or sketches using the graphic attribute.

Classification

The classification attributes categoryOfRxN and actionOrActivity codelists in the rxnCode complex attribute should be populated wherever possible, in order to facilitate mariner identification of information relevant to particular route planning or navigation tasks.

1. Being open enumeration codelists, these attributes allow for additional categories not listed among their standard values. For example, an “under repair” activity might be encoded in the actionOrActivity attribute (as “other: underRepair”).
2. Note that such extra values will merely be displayed and not processed (for example, the user interface will not use extra values to choose symbols or filter instances of Regulations, whereas it may apply filters to the standard values and/or them in portrayal).

Titles and headlines

The headline attribute of rxNCode should be used to encode brief topic headings describing the textual content of the Regulations object. Topic headings in the source material may be suitable either as-is or being adapted for use in the intended application context (for example, being shortened for readability on an ECDIS screen or auxiliary display).

1. The headline attribute of the textContent/information attribute may also be used to provide sub-heads but must not duplicate the content of rxNCode/headline.
2. Where multiple headline attributes are encoded in the same instance of rxNCode complex attribute, they must be ordered as follows:
   1. If the headline values are derived from a source material (such as the published legal text of a government regulation), the ordering must conform to the hierarchy in the source, for example, section headings must precede sub-section headings. It is not necessary to include the entire hierarchy of headings for the portion that is actually encoded in the textContent co-attribute.
   2. If the headline values are not derived from a source text, the ordering should be from general to specific.

Schedules

Operating schedules and business hours of organizations are encoded by associating a ServiceHours instance to an Authority. Partial work schedules on holidays or other special days are encoded by associating a NonstandardWorkingDay instance to the ServiceHours instance.

Similarly, operating schedules for a facility are encoded by associating a ServiceHours to the geographic feature instance representing the facility, and associating a NonstandardWorkingDay to the ServiceHours to encode partial working days.

To encode 26-hour operation, omit the times of day. Alternatively, midnight to midnight can be encoded (00:00:00 to 24:00:00).

Seasonal variations in service hours can be encoded using multiple Service Hours instances with appropriate periodicDateRange values.

If the schedule is complex, it may help to put in tabular form before attempting to encode it. The following tabular structure is suggested - encoders may adapt it as convenient.

Normal operations
Operations	Days	Time	Notes
Normal / closed / unmanned / other: ...	(Days of week)	(Times of day)	(additional information)
Normal	Mon	11:00 to 15:00	Banker's hours every Monday
Normal	Tue - Thu	05:00 to 17:00	(info for encoder - when dayOfWeekIsRange = true)
Normal	Fri, Sun	06:00 to 10:00	(info for encoder - when dayOfWeekIsRange = false)
...	...	...	...
Exceptions
	days of exceptional schedules (fixed and floating public holidays, etc.)		(information about operation on specified special day)
	...		...

Simpler schedules may be expressible in phrases:

• Normal operation: (date range) DoW-DoW, hh:mm-hh:mm, (additional information/link)
• Exceptions: (fixed/variable dates), (additional information/link)

The S-131 DCEG contains an example, similar to the example below:

ServiceHours

scheduleByDayOfWeek

categoryOfSchedule =1 (normal operation)

timeIntervalsByDayofWeek

dayOfWeek =2(Monday), 4(Wednesday)

dayOfWeekIsRange =0 (false)

timeIntervalsByDayofWeek

dayOfWeek =5(Thursday), 7(Saturday)

dayOfWeekIsRange =1 (true)

timeOfDayStart = 08:00:00

timeOfDayEnd = 16:00:00

NonStandardWorkingDay

dateFixed = (December 26) as <gMonthDay>--12-26</gMonthDay>

dateVariable = "Last Monday in May" (without quotes)

information.text = “By pre-arrangement” (without quotes)

Interpretation: A service is available under normal operation status 24 hours/day on Monday and Wednesday, and from 08:00 to 16:00 LT from Thursday to Saturday. The service is available by pre-arrangement on the last Monday in May and the 26th of December of each year when they fall on days which would otherwise be normal working days.

Contact Information

The ContactDetails information type provides several attributes for encoding different types of contact information.

The name of the contact (for example, the name of the agency, pilot service, office, etc.) should be encoded in the featureName attribute, which is inherited from InformationType.

To encode contact information in different languages, separate instances of ContactDetails may be created.

Contact information can be associated to an Authority or to any S-131 geographic feature.

Associations to ContactDetails

Type to which ContactDetails is associated	Purpose of association	Association Name	Encoder Note
Authority information type	contact information for the authority	AuthorityContact	Use when providing contact data for an organization in general, not limited to any specific purpose (the organization may of course be limited to a particular activity, e.g., pilot services)
Any subtype of OrganizationContactArea (i.e., any geographic feature)	contact information particular to the service provided at a location	ServiceContact	Use when further information about the controlling authority is not available or if the contact is specific to the feature (e.g., where requests for a particular type of service should be submitted). As a feature/info association, this link will be encoded in the feature type and reference the ContactDetails instance.

Meta features

The following meta-features are mandatory in S-131 Edition 1.0.0:

• DataCoverage
• QualityOfNonBathymetricData
• SoundingDatum
• VerticalDatumOfData

Data Coverage

DataCoverage expresses where the presence or absence of S-131 geographic features is asserted. Unlike S-101 datasets, there is no 'skin of the earth' principle in S-131 and there may be regions covered by a DataCoverage but where no geographic S-131 feature is present.

1. There must be a minimum of one DataCoverage feature in a dataset.
2. DataCoverage features must cover at least the total extent of all geographic features in the dataset.
3. DataCoverage features in the same dataset must not overlap one another.
4. If the cell must include distant areas that are not part of the port area, such areas will generally be excluded from the DataCoverage feature(s). However, consistent with rule (1) above, if a geographic feature outside the legal port area is included in the dataset (such as a remote anchorage or pilot boarding place), the DataCoverage must be extended (or another DataCoverage created) to include such remote features.
5. Attributes:
   • The mandatory attribute maximumDisplayScale is used to indicate the largest intended viewing scale for the data.
   • The mandatory attribute minimumDisplayScale is used to indicate the smallest intended viewing scale for the data.
   • The values of maximum and minimum display scales should be harmonized with comparable base layer S-101 datasets. This serves to harmonize the loading strategy of S-131 port information with that for the underlying ENCs. However, use of the same values as S-101 datasets is not mandatory in S-131.
6. Given that S-131 data will overlay ENC and possibly other datasets, the conditions described in the S-101 DCEG “Data Coverage” clause for displaying overscale warnings and setting the viewing scale may be overridden by interoperability constraints or the presence of higher-priority datasets. This should be addressed in the S-100 interoperability specification (note that as of June 2024, the interoperability does not include S-131 among its covered products).
7. Typically, only a single DataCoverage feature should be used in a dataset. However, if the maximum display scale is different for discrete areas within a single MHI dataset, this must be indicated by encoding separate, non-overlapping DataCoverage features, each having a different value populated for maximumDisplayScale.
   • Avoid excessive use of multiple DataCoverage features having different values of maximumDisplayScale.
   • Where different values of maximumDisplayScale are used, this should be restricted only to data compiled in order to achieve the intended navigational purpose of the entire dataset.
   • Datasets must have the same value for minimumDisplayScale for all DataCoverage features in the dataset.
8. Where a dataset consists of only one DataCoverage feature, the value for the maximum display scale populated in the dataset discovery metadata must be the same as the value populated for maximum display scale on the DataCoverage.
9. For any DataCoverage feature, maximum display scale < minimum display scale.
10. S-131 does not use the NULL value, which is permitted in S-101 for minimumDisplayScale when maximumDisplayScale=10,000,000. An appropriate greater value may be used instead.

Quality of Non-Bathymetric Data

The meta feature QualityOfNonBathymetricData may be used to provide an indication of the overall uncertainty of position for all non-bathymetric features (in S-131, this is all geographic features).

Horizontal and vertical uncertainties that apply to the majority of features are encoded as attributes of one or more QualityOfNonBathymetricData features.

Cartographers should ensure that quality is indicated over the whole coverage, i.e., the spatial union of all QoBD features should be identical to the spatial union of all DataCoverage features in the dataset. (Typically, there would be one DataCoverage and one QualityOfNonBathymetricData feature, with the same extents.)

Exceptional horizontal and vertical uncertainties are encoded in a SpatialAccuracy information type associated to particular spatial primitives.

The attributes horizontalPositionUncertainty, horizontalDistanceUncertainty and horizontalPositionUncertainty apply to all positions within the extent of the Quality of Non-Bathymetric Data features. These attributes may not be bound to specific feature instances unless the binding is included in the feature catalogue and GML schema. Spatial uncertainty for individual geographic features may be indicated by associating a SpatialQuality information type to the spatial primitive(s) encoding the location or boundary for the individual feature instance.

Sounding Datum and Vertical Datum

There must be only one SoundingDatum feature in an S-131 dataset, providing the datum for all depth values encoded in any feature. Given the relatively small extent of S-131 datasets and the importance of uniform datums in the same port, it is not anticipated that depths in different features will be referred to different datums; however, if this is the case in the sources, values must be converted to the same datum before encoding in the dataset.

There must be only one VerticalDatumOfData feature in an S-131 dataset, providing the datum for all elevation values encoded in any feature. Given the relatively small extent of S-131 datasets and the importance of uniform datums in the same port, it is not anticipated that elevations in different features will be referred to different datums; however, if this is the case in the sources, values must be converted to the same datum before encoding in the dataset.

Feature Names

All area and point features within an MHI product should be encoded using the attribute featureName, if a name is available.

See the S-131 DCEG for more details about feature names.

The modeling and interpretation of featureName attributes has changed significantly in the current (June 2024) S-101 (ENC) specification and S-98 Annex C, after S-131 Edition 1.0.0 was published in 2023. However, the S-131 Edition 1.0.0 encoding and interpretation remain as described in S-131 Edition 1.0.0 until IHO release a revised edition of S-131. Given the significance of feature names in datasets, data producers:

• should populate feature names in S-131 1.0.0 datasets, where names are reasonably expected, e.g., berth numbers,
• should populate the language attribute of featureName (unless it is a "universal" name, such as a berth number), and
• should not encode multiple featureNames in the same language for a single feature of info type instance.

Text Placement

See the S-131 DCEG for more details about the use of text placement.

The modeling and interpretation of text placment has changed significantly in the S-101 (ENC) specification and S-98 Annex C after S-131 Edition 1.0.0 was published in 2023. However, the S-131 Edition 1.0.0 encoding and interpretation remain as described in S-131 Edition 1.0.0 until IHO release a revised edition of S-131. To avoid the need for implementation efforts in different directions at this point of time, it is recommended that data producers

• avoid the use of TextPlacement in S-131 Edition 1.0.0 datasets.