Talk:NIPWG S-127 traffic management discussions

Summary of email discussion in May-July 2020

Participants: Jens, Mike, Jason, Stefan, Tom, Eivind, Raphael.

An extension to S-127 is needed to cover so-called "narrow passages" like bridges (i.e., bridge passages for vessels), locks, possibly canals.

There are S-101 features that model the physical dimensions of these features. S-130 (Marine Physical Environment) would cover the environment around these features.

S-127 should cover the passage act (that means navigating through a bridge, lock or even through a canal) and bridge/lock/canal control offices, the communication with them. S-127 need not replicate all S-101 modeling of these features, but can include basic attributes used in S-101, e.g., type of bridge.

Locks and bridges:

1. Maximum safe vessel parameters (size, draft, loa, beam, air draft, etc.) allowed to pass through. These parameters take into account these maximum permitted values will be less than S-101 items such as horizontal clearance and vertical clearance.
2. Type of bridge (fixed, vertical lift, swing, single- or double-leaf bascule, pontoon, etc.)
3. Notification requirements for movable spans (on signal, advance notice, etc.) if any.
4. Contact information for movable spans (VHF, call sign, telephone, facsimile, e-mail, web address, etc.).
5. Hours of operation or closure for moveable spans (24 hour, schedule based on specific/fixed times, hours of closure (usually during vehicle rush hours, notification requirements).
6. Signals - Visual (lights, flags, etc.) signals or sound signals. Examples: horn, siren, bells, lights, visual markings, etc.

Canals - can they be covered by adapting the existing Vessel Traffic Service or Ship Reporting Systems modeling?

Informal solution arising from email discussion as of July 2020:

Features:

• New "Narrow Passage" feature for locks and bridges. Alternative name Maritime Infrastructure Affecting Marine Traffic Management.
  • "Narrow Passage" should be a sub-class (or super-class?) of the S-127 feature WaterwayArea.
  • Comment: "narrow passage" suggests a a natural physical/ geographical phenomenon affecting the width of a channel, either through dredging, ATON placement, or the physical locations of rocks/shoals/land.
  • Using WaterwayArea for bridge (passages) and locks is also a possiblity but seems the less preferred alternative. If used, it will probably need additional attributes (e.g. a category attribute). Probably also an association to
• Reuse the existing S-127 feature "Waterway Area" for Canals?
  • Note: The current definition in the GI registry is from Inland ENC but it is different from S-32. The NIPWG WATARE uses the S-32 definition. Ideally the registry should follow S-32.
• A separate feature "SignalStationTraffic" of category "lock" (and "bridge passage"?) could be used in addition to the WaterwayArea. S-127 includes SignalStation (Traffic, Warning) features.
  • This feature would accept the signal data as nautical info and also contact details, but apparently not the service hours, which would still need to be encoded within the Authority of the Waterway area.
• Nautical information - instances of this information type are used for general information and signal explanations.

Attributes and associations:

• Lock dimensions (can be) encoded as recommended vessel dimensions using Applicability, with actual lock dimensions in additional NauticalInfo text.
  • Lock dimensions does not necessarily exactly correspond to vessel dimensions though. (For example: maximum draft should probably be a bit less than lock depth).
  • Conclusion: current S-127 support encoding of vessel dimensions but not actual lock dimensions.
• A Bridge / Lock "operator" is encoded as an additional Authority, with schedules, contact details etc. attached. Conclusion: Operating hours, contact details etc. currently needs an "Authority".
• Service hours has additional Nautical information- objects to tell whether the schedule describe hours when the bridge is open, open on pre-notice or closed. All pre notice requirements are also added as info to the opening hours".
  • categoryOfSchedule accepts values Normal, Unmanned, Closed. The bridge can operate in modes Normal, Closed or “open on pre-notice”. Is it assumed that “unmanned” equals reduced level of service or do we need an additional value option?
  • categoryOfSchedule is a codelist, so "extra values" can be encoded as "other:..." values. If they are widely used they can be proposed for addition as 'standard values' to the codelist.
• SignalStation (Traffic, Warning)
  • Signal descriptions should be encoded in the textContent attribute, since in general they are quite complex. NauticalInformation has been associated to encode visual depictions of signals (because textContent has no graphic sub-attribute).
  • We should consider adding the graphic attribute to the SignalStation... features, for pictorial depictions of signal lights, etc., in which case associating NauticalInformation to the signal feature would be unnecessary.