S-131 MHI Best Practices - Revision history

Rmm at 00:43, 20 June 2024

2024-06-20T00:43:30Z

Rmm: meta features, names, and text placement

2024-06-20T00:41:27Z

meta features, names, and text placement

Rmm: Contact information

2024-06-19T23:25:23Z

Contact information

Rmm: Schedules

2024-06-18T07:13:00Z

Schedules

Rmm: information about textual regulations and notes

2024-06-18T00:17:06Z

information about textual regulations and notes

Rmm: Limitation by vessel characteristics and cargo, Applicability

2023-12-06T03:35:02Z

Limitation by vessel characteristics and cargo, Applicability

Rmm: Created page with "Replace this text with page structure, headings, and content."

2023-05-25T00:15:32Z

Created page with "Replace this text with page structure, headings, and content."

New page

Replace this text with page structure, headings, and content.

@@ Line 219: / Line 219: @@
 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 Ed.tion 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
+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
 * <em>avoid</em> the use of TextPlacement in S-131 Edition 1.0.0 datasets.

← Older revision		Revision as of 00:41, 20 June 2024
Line 150:		Line 150:
	\|-		\|-
	\|}		\|}
		+
		+	== 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.
		+
		+	# There must be a minimum of one DataCoverage feature in a dataset.
		+	# DataCoverage features must cover at least the total extent of all geographic features in the dataset.
		+	# DataCoverage features in the same dataset must not overlap one another.
		+	# 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.
		+	# 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.
		+	# 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).
		+	# 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.
		+	# 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.
		+	# For any DataCoverage feature, maximum display scale < minimum display scale.
		+	# 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:
		+	* <em>should</em> populate feature names in S-131 1.0.0 datasets, where names are reasonably expected, e.g., berth numbers,
		+	* <em>should</em> populate the language attribute of featureName (unless it is a "universal" name, such as a berth number), and
		+	* <em>should not</em> 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 Ed.tion 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
		+	* <em>avoid</em> the use of TextPlacement in S-131 Edition 1.0.0 datasets.

← Older revision		Revision as of 23:25, 19 June 2024
Line 129:		Line 129:

	'''Interpretation''': A service is available under normal operation status 24 hours/day on Monday <u>and</u> Wednesday, and from 08:00 to 16:00 LT from Thursday <u>to</u> 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.		'''Interpretation''': A service is available under normal operation status 24 hours/day on Monday <u>and</u> Wednesday, and from 08:00 to 16:00 LT from Thursday <u>to</u> 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 <u>geographic</u> feature.
		+
		+	{\| class="wikitable" style="margin:auto"
		+	\|+ 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 <u>geographic</u> 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).<br/>As a feature/info association, this link will be encoded <u>in the feature type</u> and reference the ContactDetails instance.
		+	\|-
		+	\|}

← Older revision		Revision as of 07:13, 18 June 2024
Line 68:		Line 68:
	## 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.		## 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.
	## If the headline values are not derived from a source text, the ordering should be from general to specific.		## 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.
		+
		+	{\| class="wikitable" style="margin:auto"
		+	\|-
		+	!colspan=4\|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)''
		+	\|-
		+	\| ... \|\| ... \|\| ... \|\| ...
		+	\|-
		+	!colspan=4\|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'' <kbd><gMonthDay>--12-26</gMonthDay></kbd>
		+	:: 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 <u>and</u> Wednesday, and from 08:00 to 16:00 LT from Thursday <u>to</u> 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.

@@ Line 8: / Line 8: @@
 Encoders may find it easiest to capture the application of a regulation (recommendation , etc.) to a class or set of vessels in three phases:
-# 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 Regulation (or Recommendation, etc., as appropriate). Descriptions of what kinds of vessels are subject to the regulation must be excluded from the content of the Regulation instance.
+# 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.
 # Create an Applicability information type and encode the description of what kinds of vessels are subject to (or exempted from) the regulation.
 # 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.
@@ Line 41: / Line 41: @@
 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.

← Older revision		Revision as of 03:35, 6 December 2023
Line 1:		Line 1:
−	~~Replace this text~~ with ~~page structure~~, ~~headings~~, and ~~content~~.	+	== 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.
		+
		+	[[File:S131_12_4.png\|center\|Typical modeling for application of regulation, etc. to vessels specified by dimensions, cargo, etc.]]
		+
		+	Encoders may find it easiest to capture the application of a regulation (recommendation , etc.) to a class or set of vessels in three phases:
		+	# 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 Regulation (or Recommendation, etc., as appropriate). Descriptions of what kinds of vessels are subject to the regulation must be excluded from the content of the Regulation instance.
		+	# Create an Applicability information type and encode the description of what kinds of vessels are subject to (or exempted from) the regulation.
		+	# 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.
		+	# Create the geographic feature if it does not already exist.
		+	# Create an Applicability information type and encode the description of what kinds of vessels are required to use the geographic feature.
		+	# 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)”.
		+
		+	{\| class="wikitable" style="margin:auto"
		+	\|+ Example of conversion of complex condition to multiple simple conditions
		+	\|-
		+	! Complex condition !! Encode as
		+	\|-
		+	\| (condition A) <br/> AND <br/> ((condition B) OR (condition C))
		+	\| Applicability 1: (condition A) AND (condition B) <br/> 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.