Update Information - Detailed Description

[JeffWootton]

Comment from T-Caris: DCEG section 3.11 Update Information remark one states that Additional Information about the update can be encoded as Nautical Information however the DCEG and FC does not include the association between UpdateInformation and Nautical Information.
Section 25.1 Additional Information does not list Update Information as being associated to Nautical Information.
Include optional association between Update Information and Nautical Information.

Additional comment: DCEG 3.11 Update Information does not describe whether/how Update Information can be used to describe changes to Information type content. Include optional association between Update Information and Nautical Information.

Suggested solution: Given that the information related to an ENC update as included in UpdateInformation is specific to a single update and therefore any additional information related to the update would likewise be specific to the update, it is proposed that rather than allowing the association of AdditionalInformation to the UpdateInformation feature, the complex attribute information is bound to the UpdateInformation feature itself.

For changes to Information types made by ENC Update, it is proposed that guidance is included at clause 3.11.1 to associate the UpdateInformation to the geo feature(s) to which the updated Information type is associated, rather than allowing the UpdateInformation to be directly associated to the Information type itself. The main consideration in proposing this option is the complexity of portraying the indication of the UpdateInformation in the ECDIS.

The resultant DCEG changes (clause 3.11) are as follows:

[Christian-Shom]

Agree with the proposed changes.
New bullet: Suggest to replace "should" by "must": "... the Update Information must be associated with the features to which the information type is associated".
Examples or use cases are needed to provide further guidance on when/how to encode Update Information, so that data providers do not make an abusive use of this feature. End user expectancies would be profitable.

[alvarosanuy]

More discussion on this topic in S-101-Portrayal-subWG/Working-Documents#78

[JeffWootton]

From DCEG Sub-Group meeting 3 Record:

Points to Note:

• Proposal is to add the information complex attribute to UpdateInformation to enable encoding of additional information relevant to an ENC Update(s) (consistent with changes made for geo features in Edition 1.2.0).
• Additionally, new guidance has been included to require an instance of UpdateInformation related to a change to an information type to be associated with the geo features to which the information type is referenced.
• Note Christian approval of the changes, with suggestion that the “should” is changed to “must” in the new bullet. Also suggestion that examples/use cases are included.

Discussion/Decision:

• The proposal to add the information complex attribute to the UpdateInformation meta feature was approved for S-101 Edition 1.1.0.
• The proposal to include guidance that updates related only to an information type should require the UpdateInformation to be associated only to the geo feature that the information type is associated with was approved for S-101 Edition 1.1.0.
• Concerns were raised as to how the modelling is intended to work in regard to optimizing portrayal and indications in ECDIS. It was agreed that in moving forward it should be assumed that the implementation of the UpdateInformation feature in S-101 would replace the current S-57/S-52 system implementation (it was noted that the IMO ECDIS Performance Standards only state that the indication of changes applied in an ENC Update are to be made visible (highlighted) to the mariner on request – how this is done is not specified).
• The suggestion was made that a mechanism could be provided for the data producer to indicate those updates that are minor in nature and do not impact on safety of navigation (and therefore are not highlighted on request). There was concern that this could be erroneously applied.

Action:
- Keep Issue open for contributors to include additional comments/observations and as a mechanism for posting/discussing further development of UpdateInformation (All). [Ongoing]
- Report to the S-101PT that the intention for further development of the UpdateInformation meta feature is that it is to replace the current S-57/S-52 system implementation for highlighting ENC Updates (IHO Sec). [Complete]

From S-101PT9 Record:

It was suggested that the application of the UpdateInformation Meta feature be mandated for all “significant” (that is, having a significant impact on safety of navigation) Updates as a replacement for the current ECDIS system implementation for highlighting ENC Updates. It was agreed that the changes made to UpdateInformation for Edition 1.1.0 were OK, however further discussion was required. It was noted that such implementation could potentially result in significantly more work required by Data Producers.

Action S-101PT9/06: DCEG Sub-Group to discuss and develop options and associated guidance for the implementation of the UpdateInformation Meta feature for consideration of the S-101PT.

[alvarosanuy]

S-101-Portrayal-subWG/Working-Documents#78

[JeffWootton]

Refer to Paper S-101PT10-07.10 and associated Action S-101PT10-21.

To be discussed at next DCEG Sub-Group meeting, for submission to S-101PT11.

[JeffWootton]

An initial draft paper S-101PT11-08.4 has been prepared for discussion at the DCEG Sub-Group meeting 05-06 September 2023.

S-101PT11_2023_08.4_EN_Modelling_and_Use_of_the_UpdateInformation_Feature_V1.pdf

Comments in advance of the DCEG Sub-Group meeting are welcome.

[alvarosanuy]

Support the paper. Some points I would like to discuss:

• Should S-98 Annex C be updated to better communicate OEMs expected performance (S-52 vs S-101) when mariners select the 'ENC Update review' function in a DF ECDIS?
• Should we create a new S-164 test to verify ECDIS performance (as per above).
• Should we create a new Alert - When UpdateInformation impacts and Active or Planned route (including safety corridor). Not sure if this is currently an ECDIS requirement when an ENC update adds, deletes or moves a feature into that space. If this is the case this entry can be ignored.
• Not sure about the use case for a new attribute updateExpiryDate. Visually and for Alerts, this should be handle by dateEnd.
  Also, although I can't say it is an ECDIS performance requirement, I've seen ECDIS present/group changes by ENC Update number. Wouldn't removing the feature from the ENDS interfere with that functionality? Furthermore, would a new system attribute (i.e. updateNumber) be required to support this functionality in S-101 (I imagine that currently in S-57 is managed by binary differencing methodology?).

[mikan66]

Support the paper as well. We are actively looking at the implementation of this, but there are very limited test scenarios on hand. The revised attributes will feed into a new portrayal rule. What we presented previously, (visually), was done outside of the concepts of S-100 modelling, so this approach will be more in line with the S-100/S-101 constructs.

• I don't see any impact to performance and this approach may in fact reduce some display clutter and OEM processing if utilized properly.
• I'll take all the test data anyone is willing to produce, especially with multiple updates: *.001, *.002, *.003 and so on.

[DavidGrant-NIWC]

Paper looks good; this seems like a big improvement in S-101 that mariners will appreciate. As Mikan noted, it would be good to move this forward so we can start testing and get feedback for iterative improvements to the modelling and/or the portrayal.

Some notes:

• I think it would be more useful if updateType enumerated the type of change (add, delete, move, modify) rather than the ISO-8211 instruction used to implement the change (insert, delete, modify).
• For deleted features:
  • Recommend adding an attribute to identify the code of the deleted feature.
• Consider adding an optional label attribute, primarily to provide a label at deleted feature locations during update review. This could also be used to visually associate the old and new locations of moved features, or to provide a short label which could speed up the review process for the mariner.
• Consider adding noGeometry to the primitive types for UpdateInstruction to allow for updates which don't affect geometry.
• How should modifications to fixedDateRange be handled? Recommend that this attribute only be populated when necessary with the old value (for deleted or modified features). The new or unchanged value can always be retrieved from the associated feature.
• The portrayal catalog will implement the portrayal requirements (you note this in item 8 bullet one, but the 10.7.2 portion of the paper implies OEM implementation). For dual-fuel they will have to tie the PC independent selector to their existing UI component(s). The S-101 PC provides an independent selector to toggle visibility of UpdateInformation features.
  

My assumptions regarding encoding for the various update scenarios:

updateType	Geometry	UpdatedInformation.identifies
Delete	Location of the deleted feature	-
Move	Previous location of the feature	Relocated feature
Add	noGeometry	Added feature
Modify	noGeometry	Modified feature

[TDYCARHugh]

I think there are some problems with the proposed updateType attribute. I think the concept of the Update information is to give the mariner meaningful information about changes in the data with respect to the context of the change. I think there will be cases where the context of an update (new survey, traffic change, etc) would require changes within that context that could include Move, Add, Modify, Delete. I think it would make more sense to have different roles for the association between the Update Information feature and the features involved in that update. Using roles such as move, add, delete for the association would allow a compound situation to be described by the Update Information. Also I think it might be useful to have the update number to allow for past and current UpdateInformation objects to be distinguished.

[TDYCARHugh]

The discussion in sub group VTC meeting today identified that the S-100 portrayal is only working with current features in the dataset and does not have access to the 8211 records used to apply the update. For a deletion it seems there would need to be an Update Information with the geometry of the deletion (since the deleted feature/geom is gone) and to define a move or compound situation it might be useful to be able to make a compound UpdateInformation ( associations to other UpdateInformation features) or an Information type that is shared by the UpdateInformation features where the Information type carries the higher level contextual meaning for a set of UpdateInformation features.
If we use a compound feature we would want to extend updateType to include 'complex' or make it optional.
I still think it would be good to have an attribute for updateNumber.

[JeffWootton]

Refer to discussions at DCEG Sub-Group 4 meeting (September 2023), Paper S-101PT11-08.4, related decisions and Action S-101PT11-33. Changes applied for S-101 Edition 1.2.0 at DCEG clauses 3.12, 28.23 and 28.24; and Edition 1.1.0 attribute updateDescription removed.

Close Issue. Open new Issue for feedback on implementation and testing for amendments to be made for Edition 2.0.0.