search

S-101-Portrayal-subWG / Working-Documents

16 stars 5 forks source link

DCEG 1.1.0_1.2.0 Portrayal Gap Analysis #153

Closed alvarosanuy closed 2 months ago

alvarosanuy commented 9 months ago

Below is the latest S-101 PC Gap analysis with inputs from Tom, Alvaro and NIWC.

DCEG 1.1.0_1.2.0 Portrayal Gap Analysis@05OCT2023.docx

alvarosanuy commented 9 months ago

Entries marked for discussion at this point in time (note that some have their own GitHub issue open anyway):

image image image image image image image

DavidGrant-NIWC commented 9 months ago

Is the text "clr op" displayed when the attribute is encoded as "Unknown"

Currently it will not display the "clr op"/"clr cl" label if the value of the associated attribute is Unknown.

H. amend modelling for the meta feature UpdateInformation

Has Impact. Currently this feature is displayed using the testPCB symbol (frowning face). Will update to draw appropriate symbology based on new updateType attribute. Note that currently multiple features will need to be created if a feature is both moved and modified - may want to consider asking DCEG group to change the attributes upper multiplicity.

L. Modelling and QoBD apply option 1

No current impact since uncertainties aren't visualized. Should we update the label on #1 and PC 115 to target PC 1.2.0?

alvarosanuy commented 9 months ago

L. Modelling and QoBD apply option 1

No current impact since uncertainties aren't visualized. Should we update the label on #1 and PC 115 to target PC 1.2.0?

In order to test Uncertainties in On Shore ECDIS we need a 'Route check' option in both, Route Monitoring and Route Planning modes, to do the 'scanning' of the planned route/look ahead using uncertainties (Vert & Horiz). We decided not to display the uncertainty circles for Horiz Unc. (and we didn't even discussed how we could depict Vert Unc.) but we decided (and is kind of a new IMO PS requirement) that they will interact with A&I. On this note I think we should focus on how we would like ECDIS to visually depict the safety 'breach' to the user (beyond logging an entry in the Alerts panel and centering the display on the problematic feature). At the moment, the charted feature having a safety breach is highlighted in yellow (INDHLT). For the 'uncertainty breaches', we could use a dashed yellow arc/circle or rectangle (when HU=Unknown/zero but VU creates a breach of the Safety Contour setting) to highlight the problematic feature/area to the mariner. Graphical portrayal of uncertainties should only be used to visually support the depiction of a safety breach. Mariners should not be allowed to turn uncertainty circles on/off at their will [Topic for discussion ...].

image

DavidGrant-NIWC commented 9 months ago

11.3.6 requires that the curve representing the safety contour is checked as if it was an area, and it requires that areas are expanded outward. I'm not aware of any way to accomplish this using methods available in S-100 v5.

image

Feature Feature Geometry Geometry for Safety Check S-100 5.x supports?
Safety contour image image No. Requires changes to drawing instruction schema to support an attribute value representing the buffer distance.
Prohibited Area / Area with special conditions image image No. Requires changes to drawing instruction schema to support an attribute value representing the buffer distance.
Soundings / Nav Hazard points image image Yes, but clarifications could help to distinguish between representation interpreted as linear vs. surface geometry

Aside from that issue, and as you note, the PC can be updated to include information which allows the ECDIS to generate alerts in both route planning and route monitoring while incorporating uncertainty values.

On this note I think we should focus on how we would like ECDIS to visually depict the safety 'breach' to the user (beyond logging an entry in the Alerts panel and centering the display on the problematic feature).

IEC 62288 already contains the requirements for display of alert highlights. image image

Mariners should not be allowed to turn uncertainty circles on/off at their will [Topic for discussion ...].

MSC 530.(136) clause 11.3.6 and 11.4.9 state "It should be possible for the mariner to select [...]". My interpretation is that the mariner should have the option to enable/disable the inclusion of uncertainty information in the alert generation/highlighting. We could add a context parameter which would control how the alerts are generated (won't generate alerts based on accuracy info when off), or we could add one or more viewing groups to disable the accuracy highlights (while still generating the alerts).

alvarosanuy commented 9 months ago

IEC 62288 already contains the requirements for display of alert highlights.

My comment was about how to differentiate 'highlights' provided as a result of the safety framework 'touching'' the feature as charted or the uncertainty buffer area IF the mariner selects that option. I personally believe we could vary the current highlights to be slightly different (dashed lines instead of solid + yellow colour) to visually reinforce the difference between both scenarios.

On another but related note, based on the table provided above, I was reminded that the new IMO PS (MSC530(106), also asks for ECDIS to interact with a buffer zone that is not just 'uncertainty related' but also 'user selected'. It says that the ECDIS must provide A&I if the Route (current and 'next' leg) 'Pass closer than set distance from ....': safety contour; a danger; area with special conditions. Refer to Sections 11.3 & 11.4.

DavidGrant-NIWC commented 9 months ago

The alert catalog describes the highlight in terms of IEC 62228, identifying use of either 3.5b or 3.5c. In order to add other highlight styles, we would need to:

It says that the ECDIS must provide A&I if the Route (current and 'next' leg) 'Pass closer than set distance from ....': safety contour; a danger; area with special conditions. Refer to Sections 11.3 & 11.4.

That should be handled in the ECDIS as part of the route plan (either incorporated into the allowable XTE or in addition to the allowable XTE). It effectively adds a buffer to the line representing the planned track, turning the line into an area. You can test this in the ShoreECDIS by modifying the XTE component of the waypoint leg.

The dashed line represents the planned track, the area represents the planned track line +/- the "set distance" (in this case, 75 m). image

There is a similar setting (XTD) for the ownship safety check: image

alvarosanuy commented 9 months ago

Find below updated version of the Portrayal Gap analysis Table (based on DECEG 12.0 20231016):

New entries in Green

DCEG.1.1.0_1.2.0.Portrayal.Gap.Analysis@18OCT2023.docx

alvarosanuy commented 9 months ago

Decisions made at Portrayal subWG meeting on 17/10/23

NIWC to seek further clarifications on implementation if the comments provided are not comprehensive enough.

  1. Entry # 26 - use the legend 'clr op ∞' when the feature attribute verticalClearanceUnlimited=True
  2. Entry # 35 - refer to decision made in https://github.com/S-101-Portrayal-subWG/Working-Documents/issues/116
  3. Entry # 65 - no impact. Only one featureName or Information text will be displayed at a time. This being the one matching the language selected by the user and having displayName=True
  4. Entry # 72 - No impact. Anyone wanting to propose a new symbol for when visitorsMooring=True will have to open a dedicated GitHub issue or submit a proposal to the NCWG. Recommend any proposal also considers symbology for MooringArea; categryOfMooringArea=2 (mooring area for visitors).
  5. Entry # H - Portrayal to match S-52 symbology based on updateType. Also refer to decisions made in (https://github.com/S-101-Portrayal-subWG/Working-Documents/issues/151 & https://github.com/S-101-Portrayal-subWG/Working-Documents/issues/152
  6. Entry # L - refer to https://github.com/S-101-Portrayal-subWG/Working-Documents/issues/1 for decisions on uncertainties' portrayal and A&I performance.
DavidGrant-NIWC commented 5 months ago

Current status.

Background color key:

DCEG.1.1.0_1.2.0.Portrayal.Gap.Analysis@19OCT2023-NIWC.docx

DavidGrant-NIWC commented 5 months ago

Final update.

All implemented except:

See notes on these rows: image image

DCEG.1.1.0_1.2.0.Portrayal.Gap.Analysis@19OCT2023-NIWC.docx

alvarosanuy commented 5 months ago

Thanks for the update - I know we have issues open for 'Hierarchy of Metadata'& Update Information. Same for changes to SVG profile and metadata. @DavidGrant-NIWC - Should we create new issues in this GitHub space for any of the items in the screenshots above?

I would like to close this issue but I want to make sure nothing is left behind ....

DavidGrant-NIWC commented 5 months ago
alvarosanuy commented 4 months ago
  • What should the portrayal be for MooringArea with categoryOfMooringArea=unknown?

Values 1, 2, 3 and Unknown will have the same mapping for now.

  • Ensure the processing for beaconShape=4 is as desired.

    • For instance, LateralBeacon only checks for a lattice beacon when paper chart symbols are enabled.

Ok

  • The beacon rules processing still checks for natureOfConstruction value 11, but it will never evaluate to true.

Agree (needs clean up?), natureOfConstruction value 11 is no longer valid in FC 1.2.0

  • Check to ensure the symbolization is as desired; should these checks be updated to look for beaconShape=4?

Not sure what 'checks' you are referring to. Can you upload a screenshot of how any Beacon looks when beaconShape=4 both, simplified and Paper Chart options?

alvarosanuy commented 3 months ago

Decisions made at Portrayal subWG meeting on 09/04/24

The sWG agreed that all PC changes required to make it aligned with FC 1.2.0 have been applied with the exception of https://github.com/iho-ohi/S-101_Portrayal-Catalogue/issues/314. In regards to 'Hierarchy of Metadata', the sWG decided to:

Also:

alvarosanuy commented 3 months ago
  • [ ] Alvaro is to check that the 'Simplified' symbology for Lattice Beacons (beaconShape=4) is correct in PC 1.2.3.

Checked BeaconLateral; SafeWaterBeacon & SpecialPurposeGeneralBeacon and they still refer to natureOfConstruction=11 to trigger the portrayal of a 'major' beacon and not beaconShape=4

For example:

elseif feature.colour[1] == 4 and contains(11, feature.natureOfConstruction) then featurePortrayal:AddInstructions('PointInstruction:BCNLAT16')

alvarosanuy commented 2 months ago

Closing this issue as the only pending task (Hierarchy of Metadata) is now being tracked in its own GitHub issue https://github.com/S-101-Portrayal-subWG/Working-Documents/issues/164