search

S-101-Portrayal-subWG / Working-Documents

16 stars 5 forks source link

Update Information #78

Closed alvarosanuy closed 1 year ago

alvarosanuy commented 2 years ago

This issue has been created as an Action item from https://github.com/S-101-Portrayal-subWG/Working-Documents/issues/5

The objective is to discuss how UpdateInformation would be implemented in ECDIS and what symbology (if any) it would require.

The goal is to implement some default symbology for all geometric primitives (P, C, S) in PC 1.1.0 to support testing before a final decision is made for S-101 2.0.0. Note that, in parallel, we plan to seek Singapore's Lab support to engage mariners and recommend their the preferred implementation of the 'Review Update' function in ECDIS (to be implemented in S-101 2.0.0 or later ...).

mikan66 commented 2 years ago

I offer the below to assist in further discussions. This is an example of what we have seen in a sample update dataset that contains feature: 'UpdateInformation'. We indicated that it was "added" and then you can review the text in the Pick Report. This is strictly prototype visualization for our own use and is not indicative of any presentation requirements.

image

alvarosanuy commented 2 years ago

https://github.com/iho-ohi/S-101_Portrayal-Catalogue/issues/99

alvarosanuy commented 2 years ago

An option could be amending the modelling of UpdateInformation to include a new mandatory attribute called 'Update type'. The attribute would be an Enumerated List (EN) with the following options: New; Modified; Deleted.

The intention with introducing a new attribute is to help with portrayal as it would trigger existing S-52 symbology currently in use by the 'Review Update' function in ECDIS.

The issue with this proposal is that the UpdateInformation symbology would clash with the symbols depicted by ECDIS if the mariner decides to use the 'Review Update' functionality in ECDIS. I believe that the existing functionality should be amended to only depict UpdateInformation features within the ENC update and, based on the value of the new attribute, portray them accordingly alongside the change explanation and encoded in the updateDescription attribute.

With this approach, UpdateInformation would be only portrayed and referred to by the 'Update Review' functionality and not automatically symbolised by Portrayal Catalogue Rules. Producers (HOs) will become responsible for systematically encoding this feature when delivering safety critical info to mariners via ENC Updates. S-100 ECDIS (or the S-100 side in a DF-ECDIS) wouldn't any longer highlight changes if not accompanied by an UpdateInformation feature.

alvarosanuy commented 2 years ago

I just noticed the following guidance in Edition 1.0.0 of S-98 Annex C (Table C-16 and section 12.11.2). See images below.

Although the text in Table C-16 could be interpreted as 'aligned' with the proposal I presented in the previous Github comment, the 'Update Review' mechanism is still confusing and needs to specify how ECDIS will 'identify the chart corrections in a dataset'.

It looks like the symbolization bit does not need to change (retain as per S-52). The task for us now is to decide and document how we want ECDIS to identify the features that changed and the 'type of change' so they can be symbolised accordingly. More food for thought !

image

image

mikan66 commented 2 years ago

So, we have currently prototyped a combination approach for internal testing. In the earlier screen-shot for the UpdateInformation, the indication is that it was an "Added Feature" (via the update dataset) and the key point is that this "feature" provided information via the text Attribute about a specific surface.

The main take away is to note that most of the information in the update dataset was analogous of the S-57 approach. Only very specific UpdateInformation records were provided and not for every updated record in the update dataset.

TomRichardson6 commented 2 years ago

Casting my mind back on this to the development of the DCEG my recollection is that this Update Information as a feature was intended to allow a producer to clearly indicate a specific change or highlight a set of changes that are temporary and preliminary in nature. ~But in all of those discussions we considered the review update functionality to be separate and that is driven by the S-57 update instructions themselves. The assumption was that some producers may not use these at all due to the additional encoding effort but we wanted to support those that wished to. So I would not support creating Update Information features to duplicate those instructions. So I think there has been some misunderstanding introduced here via S-98.

alvarosanuy commented 1 year ago

More confusion ..... I came across this section in S98 Annex C where it looks somebody has already decided on how UpdateInformation features should portray in S-101. I personally think all this needs more discussion particularly around the way UpdateInformation and ECDIS' ''Update review' function would work/complement each other.

image

alvarosanuy commented 1 year ago

Portrayal subWG meeting - 12th January 2023

  1. There was consensus within the subWG that UpdateInformation should:

  1. It is paramount that the S101PT makes a decision (support) the proposed way forward ASAP so all related documentation (S-98, DCEG, FC, etc) can be updated and provide a clear and authoritative way forward.. Alvaro to present a paper at the next S101PT meeting if necessary.

  2. The subWG recognises that mariners' input would be extremely advantageous to support any decision. Consequently it is recommended presenting a proposal to the Singapore lab (or other testbeds) to specifically focus on the 'ENC update review' topic from the user perspective.

  3. It was also recognised that, in order for the proposed way forward to succeed, ENC production softwares will have to play an important part in assisting encoders with the semi-automated generation of UpdateInformation features (minimal user intervention) when compiling ENC Updates.

TomRichardson6 commented 1 year ago

@alvarosanuy thanks for flagging this as a priority, I think we should commence work on a paper which PT10 can hopefully endorse for inclusion in edition 1.2.0 an interim FC could potentially be created to support testing.

For me this approach needs input from the production software providers to ensure that production systems can populate this new information without burdening producers. Your 4. I think we should aim to circulate the paper to this group well ahead of PT10.

A potential benefit of this approach is that the ECDIS route check function could be used to highlight items since a previous route check.

I would be happy to work with you on the paper.

alvarosanuy commented 1 year ago

@alvarosanuy thanks for flagging this as a priority, I think we should commence work on a paper which PT10 can hopefully endorse for inclusion in edition 1.2.0 an interim FC could potentially be created to support testing.

@TomRichardson6 - Agreed. I'll prepare a draft and share with you for comments before we socialise it with ENC production software companies for their input.

alvarosanuy commented 1 year ago

Decisions made at Portrayal subWG meeting on 11/5/23

alvarosanuy commented 1 year ago

Issue also exists in DCEGsWG https://github.com/iho-ohi/S-101-Documentation-and-FC/issues/41

alvarosanuy commented 1 year ago

This issue can be closed as the DCEGsWG has decided to implement proposed changes for testing in Edition 1.2.0 (https://github.com/iho-ohi/S-101-Documentation-and-FC/issues/41). Also, note the creation of 'follow up' portrayal issues such as: https://github.com/S-101-Portrayal-subWG/Working-Documents/issues/151 and https://github.com/S-101-Portrayal-subWG/Working-Documents/issues/152