Depiction of Horizontal Clearance values

[alvarosanuy]

I think we need to come up with a way to display horizontalClearanceValue as, for some features and environments, this info may be as (or more) important than vertical clearances when transiting through some Bridges, Gates and even accessing StructuresOverNavigableWater

I propose we consider preceding the existing text strings with 'H' or 'V' (e.g. Hclr op 15) to clarify the type of Clearance in display (Horizontal or Vertical). I prefer this option over trying to replicate the symbols in S-4 B-380. As a starting point, I propose we amend the PC to display Horizontal Clearances on those features that currently carry instructions to display Vertical clearances. The simultaneous display of multiple text labels needs discussion. At the moment Vcl op and Vclr cl are displayed in 2 lines. For those scenarios where the feature also includes information on its Horizontal clearances, we may want to join the 2 Vclr labels in one line and show the Hclr info in a different text line below or display each clearance label in a different line (e.g 3 text lines). Maybe there's an argument to expand the textType attribute for TextPlacement to include clearances (?).

I suggest we consider including a new Boolean attribute 'displayClearance' to horizontalClearanceOpen & horizontalClearanceFixed and, by default, have it set to False. By doing this, we would maintain consistency with S-52 (Horizontal clearances only available to users via Pick report) but give producers the option to show it to mariners on the screen when they consider that relevant and important.

Below is the list of the proposed new text strings (first 3 are existing and the last 2 brand new).

verticallClearanceOpen ---- clr op ---- Vclr op verticallClearanceClosed ---- clr cl ---- Vclr cl verticallClearanceFixed ---- clr ---- Vclr

horizontalClearanceOpen ---- NIL ---- Hclr op horizontalClearanceFixed ---- NIL ---- Hclr

[alvarosanuy]

Decision at PsWG meeting on 11/7/2024

• Endorse the proposal and implement the new abbreviations listed above.
• The Horizontal Clearance label implementation applies to all features having horizontalClearanceValue (HORCLR) as a valid attribute.
• When Horizontal Clearance is populated and multiple Vertical Clearances labels are required (e.g. Close and Open values), the 2 text strings corresponding to Vertical clearances are to be positioned in one line (separated by: space, dash, space? @DavidGrant-NIWC other ideas??) and the Horizontal clearance on the next text line below.

[DavidGrant-NIWC]

How about horizontalClearanceWidth? That applies to Berth, DockArea, DryDock and FloatingDock.

horizontalClearanceValue applies to: Canal, DockArea, Gate, LockBasin, ShorelineConstruction, SpanFixed, SpanOpening, StructureOverNavigableWater, and Tunnel.

Prototype

Only applied to the bottom two SpanOpening features; the top two are SpanFixed and are unchanged.	Before	After

[DavidGrant-NIWC]

I think something like one of these would be easier to read.

no change to vertical clearance labels	add "V." to vertical clearance labels

[alvarosanuy]

How about horizontalClearanceWidth? That applies to Berth, DockArea, DryDock and FloatingDock.

I think the labelling for Horizontal Length and Width (including clearances values - generally shorter than the maximum measurements) is not implemented in S-52. I believe Pick Report is ok in these cases. Let's leave things as they are for now and wait for feedback regarding Hclr and Vclr first.

Only applied to the bottom two SpanOpening features; the top two are SpanFixed and are unchanged.

I understand you did not apply the changes to the SpanFixed Rule yet, but it would be done in PC 1.4.0 (the new labels should apply to SpanFixed as well). Do we agree?

I'm happy to implement:

[DavidGrant-NIWC]

I understand you did not apply the changes to the SpanFixed Rule yet, but it would be done in PC 1.4.0 (the new labels should apply to SpanFixed as well). Do we agree?

Yes, we agree.

Will proceed with:

[DavidGrant-NIWC]

Implemented in 1.4 PC; see PC 417 for samples.

Changes can be made in the next couple of days if desired, otherwise it'll have to wait for 1.5.

[alvarosanuy]

Implemented in 1.4 PC; see PC 417 for samples.

I noticed that a large number of examples have the text 'H.clr op nn.x' and not just 'H.clr nn.x'.

All features except SpanOpening, SpanFixed and Gates (that can have values for when they are Open or Closed) must display 'H.clr nn.x (without the text 'op') as their related attributes are either horizontalClearanceWidth or HorizontalClearancefixed. Can you please check their implementation?

[DavidGrant-NIWC]

Implemented in 1.4 PC; see PC 417 for samples.

I noticed that a large number of examples have the text 'H.clr op nn.x' and not just 'H.clr nn.x'.

All features except SpanOpening, SpanFixed and Gates (that can have values for when they are Open or Closed) must display 'H.clr nn.x (without the text 'op') as their related attributes are either horizontalClearanceWidth or HorizontalClearancefixed. Can you please check their implementation?

My understanding is that we are not displaying horizontalClearanceWidth. Did I misunderstand?

For the rest, it should display as you described, it's just that there isn't supporting test data. I was forced to hard-code values to check the positioning of the labels and didn't take the time to change the hard-coded strings to reflect horizontalClearanceOpen/horizontalClearanceClosed vs. horizontalClearanceFixed.

It should all be (re-)tested when test data becomes available.

[alvarosanuy]

My understanding is that we are not displaying horizontalClearanceWidth. Did I misunderstand?

You are right. I got confused because I did a search for HORCLR in DCEG 1.4.0 and for DryDock and FloatingDock, this S-57 attribute acronym is listed against the horizontalClearanceWidth entry for those features. I don't think this is right. Only horizontalClearanceValue should be 'mapped' to HORCLR. @JeffWootton - What do you think? Should we remove these 2 HORCLR entries from the DCEG (not sure if this links to FC as well)?

[JeffWootton]

@alvarosanuy and @DavidGrant-NIWC :

My understanding of horizontalClearanceWidth on DryDock and FloatingDock (and other features it is bound to) is that it is intended to encode the regulatory width and not the actual physical clearance width. This is implied in the definition for the attribute and in the accompanying encoding guidance. The reference to HORCLR in the DCEG is intended more for conversion from S-57 as the physical horizontal clearance attributes are not included for DryDock and FloatingDock (I assume that this is because the physical clearance is not an issue as this is governed by the gate. So for conversion from S-57 HORCLR in the case of DryDock and FloatingDock is intended to convert to horizontalClearanceWidth.

For DryDock and FloatingDock in S-101, if the horizontal clearances do not display in S-52 for DRYDOC and FLODOC, then they should not display in S-100 ECDIS for horizontalClearanceWidth. If considered necessary I can remove HORCLR from these entries in the DCEG and ensure that the conversion guidance is included in S-65 Annexes B and C.

[alvarosanuy]

@DavidGrant-NIWC - Can I close this issue, or do you have any pending questions?

[DavidGrant-NIWC]

Issue can be closed if you are happy with the placement and abbreviations.

[alvarosanuy]

Close - Implemented in PC 1.4.0