New symbol for Berth features with categoryOfCargo = 7 (Dangerous or Hazardous) - ENCWG7-5.3_2022

[alvarosanuy]

At S101PT9 the inclusion of the attribute categoryOfCargo as a valid attribute for Berth features was approved.

It was agreed to consider a new symbol for categoryOfCargo = 7 (Dangerous or Hazardous) only.

S-52 presentation already includes a point symbol as part of the drawing instruction (BRTHN01):

S-4 (B-321.8) & INT1 do have a symbol for a dangerous cargo berth. This is:

S-4 portrayal guidance includes the following statement:

Recommendation is:

• [ ] Develop a new 'flame symbol' using F 19.3 as template.
• [ ] Consider adding the flame inside BRTHN01 and shifting OBJNAM from the center of the symbol when this occurs.
• [ ] Investigate the use of the attribute categoryOfCargo for AnchorageAreas and its potential impact on the portrayal of this feature as well (refer to S-4 B-431.3 and N 12.7 in particualr).

@MikusRL or @HolgerBothien - Can any of you assist with the development of the 'flame' symbol?

[MikusRL]

@alvarosanuy I can create the point symbol F19.3 (first square). But would appreciate @HolgerBothien or NIWC help/discussions/input in addressing the second and third square.

[HolgerBothien]

Regarding the second tick box. I think the best solution will be to develop two symbols:

• one with a circle around the pivot point and the flame in the centre (if no ObjectName is given)
• one as an oval with the pivot point moved to the right and the flame moved to the left

The third tick box seems to be out of scope here. I would prefer to handle it as an separate issue.

[MikusRL]

@HolgerBothien did I volunteered too early? Do you have the symbol already perhaps?

[HolgerBothien]

No, this is only a sketch done with MS Paint. No proper vector symbol. So, please move ahead. :-)

[MikusRL]

A very good one. OK.

Just a question, how does the "expanding" of the oval works to facilitate different length of the OBJNAM? Just curious.

[HolgerBothien]

The current symbol doesn't take this into account. It assumes in general numbers between 1 and 99 but works maybe for numbers from 100 to 999. The new symbol should reserve enough space for a three digits number. To making symbols for each length would go a little bit over the top. And it would make the rules unnecessary complex. Or what you think?

[MikusRL]

Will you attend the S-100WG in Monaco? We could take then the discussion further there.

[HolgerBothien]

I will not travel to Monaco but participate online. Unfortunately we can only discuss here or in MS-Teams if that is appropriate for you. Regarding the SVG profile I see many things to be discussed.

[TDYCARHugh]

I am unable to attend the Monaco meeting due to a personal conflict. Happy to be involved in discussions about using/improving the SVG profile.

When I first made the S-100 SVG profile 7 years ago there was a desire to keep it as simple as possible. There was an expectation that some system developers would want to parse and implement the SVG directly instead of being forced to use a full SVG library. So I started with the SVG tiny profile and only included enough instructions to replicate the S-52 symbols. I expected that once other systems started implementing S-100 and product specs got involved in making symbols there would be requests to extend the profile.

[DavidGrant-NIWC]

Sorry we won't see you guys in Monaco.

@TDYCARHugh - I agree that the S-100 SVG profile should be kept as simple as possible. However, I think there is ambiguity regarding what subset of SVG Tiny 1.2 is included in S-100. Appendix 9-B is marked normative, but it says:

This appendix describes the subset of SVG elements that have been used in the creation of S-100 SVG symbols and covers the set of SVG elements and associated attributes and properties that are in use by S-100.

• This note is specific to the draft S-101 symbol set.
• It doesn't describe what is actually required, it just says (paraphrasing) "this is what we are currently using". However, the next paragraph says:

  The S-100 SVG profile is a subset of the SVG Tiny 1.2 profile http://www.w3.org/TR/SVGTiny12

The subset is not formally defined, so one is left to wonder if a particular SVG feature must be supported or not. I think the intent was to only require supporting the features listed in 9-B-2 and 9-B-3, but it doesn't actually say that anywhere. It says things like:

The style properties used in the draft S-100 SVG symbols include:

so, one is left to wonder if other symbol sets will use additional style properties. There are also some missing style properties that are currently in use: "fill-rule", "shape-rendering", "display", etc.

We have seen this ambiguity play out already - ESRI developed a windmill symbol and wondered why we didn't support the curve instruction (part of the "path" command) in our testbed. Here's what S-100 says about the curve instruction: We have since added support for the curve instruction, but I'm not sure that other implementations will do so until they encounter a symbol which uses it.

So, this was all a long way of saying I think that appendix 9B should be updated for S-100 ed. 6, and it should make it clear exactly what is (and what is not) included in the S-100 SVG profile. I would also like it to specifically say that animation, multimedia, scripting, etc., are not supported.

[MikusRL]

I have moved the SVG discussion comments to Issue #103 and will continue here with the Berth dangerous cargo symbol here further. I hope it is ok with everyone.

[MikusRL]

In regards to the "expanding" of the Berth's oval Symbol @HolgerBothien, I was in thinking, that it is made "smarter" in ECDIS, like it is defined as an oval symbol with defined color, but in actual implementation it is actually portraying like a live text box with the rounded corners, which basically at the sides ens up as a half circles, hence ovals. In this way I though it can incorporate whatever the text is in the OBJNAM ito the "oval symbol" recognizable by the mariner as that symbol. But apparently I was mistaken. So I will create two symbols. @alvarosanuy And I would like to agree with @HolgerBothien that the third square should be it's own new issue, if recognized to be created yet for 1.1.0 or later.

[HolgerBothien]

I have tried to use InkScape to create the symbol. It would require changes to the SVG profile of S-100. It is not the final symbol but may give some ideas.

[MikusRL]

Created two symbols BRTHDNG1 and BRTHDNG2, as per the first and second tick boxes of first comment. I agree with @HolgerBothien that the third tick box needs a separate issue, as additional discussion needed before the N 12.7 symbol creation.

BRTHDNG.zip

[TomRichardson6]

I support the symbols Mikus has created and also support creating a new item for the 3rd bullet I think it should be assigned to S-101 1.2.0 not edition 1.1.0.

Looking at some ENCs OBJNAM values may typically be up to 4 characters mixing letters and numbers so suggest that the the text rule considers this to avoid the text clashing with the symbol. The second symbol looks like it would work for 2 character numbers but less well for 4 characters as the name attribute value is a string I'm not sure the rules could assign a different symbol based on the number of characters. Perhaps justification of the text can avoid the clashing of the text and symbol?

[alvarosanuy]

Portrayal subWG meeting - 12th January 2023

1. A decision was made to approve the new symbol BRTHDNG1.

2. NIWC - Please amend the rule and map this symbol to Berth; categoryOfCargo = 7 (Dangerous or Hazardous). Text to display as per current instructions for S-57 BERTHS features (see first comment for this issue).

[alvarosanuy]

@mikan66 - Has this change (rule) been updated in NIWC's draft PC 1.1.0?? Beyond the fact you do not have test data to visualise the mapping?

@TomRichardson6 - Can you provide NIWC with an S101 dataset with containing Berth; categoryOfCargo = 7 (Dangerous or Hazardous) features? - Different geometric primitives as required??

[TomRichardson6]

@alvarosanuy this one is on the list for an update to cell 8 of the S-101 TDS. I hope to have work on these edits underway next week.

[mikan66]

@mikan66 - Has this change (rule) been updated in NIWC's draft PC 1.1.0?? Beyond the fact you do not have test data to visualise the mapping?

@TomRichardson6 - Can you provide NIWC with an S101 dataset with containing Berth; categoryOfCargo = 7 (Dangerous or Hazardous) features? - Different geometric primitives as required??

I won't close any of these PC changes until I have full test data. However, the logic is in the main branch of the PC repo.

[alvarosanuy]

Implemented in PC 1.1.0