Update Information

[JeffWootton]

DCEG Edition 1.2.0 modeling for the UpdateInformation meta feature, intended to replace the current ECDIS mechanism for highlighting ENC Updates to the Mariner:

UpdateInformation.docx

This revised modelling requires rigorous implementation and testing, and any feedback/comment is invited to inform discussions for the development of the finalized model for S-101 Edition 2.0.0.

Please note, however, the following decision from S-101PT11: S-101PT11 agreed that, due to lack of time for implementation and testing of the revised model and the impact on production systems and producers, the modelling will be “rolled back” to the Edition 1.1.0 model for initial 2.0.0 operational release, pending further results and evaluation of impacts from implementation and testing.

[JeffWootton]

To be discussed at S-101PT12 under Agenda item S-101PT12-06.6.

[JeffWootton]

S-101PT12 Decision: Apply changes as discussed at S-101PT12 in consultation with AU and Telydine Geospatial (Caris).

Changes applied 09 March 2024 for consideration of AU and Caris:

[JeffWootton]

Further amendments following VTC meeting between IHO Secretariat, Australia and Teledyne Geospatial 14 March 2024:

[MikusRL]

Is it correct to assume that the feature Update Information is never expected at New Cell (first Edition of the ENC), and it is optional for ENCs New Editions? Should it be stated as well?

Another use case if the update has a technical or another format issue and can not be released as is or continued with further updates, and is then recommended to be re-issued as a "technical" New Edition (well known with S-57 ENCs) to fix the issue and be able to release, what is the expectation of the Update Information object then. Again, is it correct to assume that in this case the Update Information feature's relevant attribute (update number) are updated "automatically", as the information what has been updated is still relevant and is needed for the end user as basically is an ENC update? Or because it is a New Edition, Update Information feature is not expected any more, as it is optional in ENC New Edition? Can the attribute Update Number hold a new edition number as for this case, and wouldn't be then misinterpreted with the update number? Any thoughts?

[MikusRL]

And sorry, but yet another use case - the Re-Issue. What is expected regarding the Update Information feature then:

• the Update Information feature/features from the "latest" update? or
• all "actual" Update Information features actual at the point of the issuing of the Re-Issue starting from the first ENCs update (or even including the still actual New Edition's Update Information features, if it has been as a "Technical" New Edition? or
• nothing, as it is considered as "a New Edition", therefore Update Information feature is optional?

[DavidGrant-NIWC]

From a technical standpoint you could have Update Information features in new cells / new editions / re-issues. Might be useful to summarize the rationale for the chart.

[TDYCARHugh]

UpdateInformation in a New Edition could be optional and used if the producing agency wishes to call attention to areas or features or to give an overall description of the the New Edition.

UpdateInformation must be mandatory in updates if we wish to be able to replace the older method of highlighting every feature that has an attribute/geom update.

A Re-Issue is not a new edition. It must be equivalent to the result that you would get if you installed the latest edition 000 file and applied all the accumulated updates to the same update number as the Re-Issue. The next update must be able to be applied to either the Re-Issue or the accumulated dataset. So it would contain all the UpdateInformation features that have been included in the base 000 and updates.

[DavidGrant-NIWC]

• The UI with updateType = insert should use the geometry of the inserted segment at the new position rather than restricting to curve geometry.
• The UI with updateType = move should use either no geometry, or curve geometry. If curve geometry is used the portrayal will depict the curve, which is intended to visually connect the deleted and inserted features.

[benhazelgrove]

• The UI with updateType = insert should use the geometry of the inserted segment at the new position rather than restricting to curve geometry.
• The UI with updateType = move should use either no geometry, or curve geometry. If curve geometry is used the portrayal will depict the curve, which is intended to visually connect the deleted and inserted features.

@DavidGrant-NIWC are we asking for enhanced guidance on the depiction of a changed curve? Depth Contour change for example? I understand the modelling is good, further guidance for portrayal required?

To change a segment of a depth curve, compilers will need to add start and end nodes of the changed section in order for the UI feature to highlight to changed curve segment only.

[DavidGrant-NIWC]

My comment was intended to address the case where a curve or segment of a surface is deleted and replaced with either a point or a surface. Granted this probably almost never occurs, but it isn't disallowed so it should be accounted for.

You could also move a single point of a curve or surface.

[LizHahessy]

Just for clarification, are we intending to apply this to all features or just for ones that are navigationally significant? In the specification it implies that data producers can decide what is navigationally significant, but some of the comments suggest it goes on every change or mirror existing functionality. DK has concerns regarding the manual work that may be required, as we do not see how this can be meaningful for the mariner and automated. Our edits are in a database and not specifically linked to a product. For example, if we conduct a global change on our database to tidy up incorrect encoding or spellings, we will not be able to release an update, without either setting a mandatory UpdateInformation or waiting until a navigationally significant feature has been amended. This would likley have to be manually managed. Additionally we have concerns regarding the deletion of the UpdateInformation. It states that they should be removed at new edition or at the next update where it is not relevant. When editing in a database and not a product we do not always know whether the export will be an update or new edition, so this will need to be managed manually. We support the principle behind the idea but without a clearer indication on how this can be technically achieved, we are concerned that this becomes a very manual task or an unintended consequence may be that HOs make more New Editions to avoid manually managing the UpdateInformation, which will limit the benefit to the mariner. Is there a clear use case and quantifiable benefit to the mariner against the potential work it may create and time it may take?

[benhazelgrove]

AHO only intends to use it for Navigationally significant features. If we were to do an entire change to our portfolio to fix spelling mistakes this would not be something we would create an UI feature for.

The benefit for the mariner will be the ECDIS screen on the bridge will have a lot more clarity around what has been updated in a product rather than the orange mess that currently occurs and the mariners need to cross reference with NTM documentation to potentially find Nav critical update data.

Agree that the management of deletions needs to be addressed, however the benefits of this feature should be forefront of our minds when thinking of our customers.

[YvesGuerin]

@TDYCARHugh I know that the paper chart is the poor relation of cartography, but I would be interested in an update of the HPD-PCE with the same concepts. In the future, do you think these concepts could be applied to Paper Chart Editor? This would be useful for NtM (link to S4 (NCWKG)).

[TDYCARHugh]

@YvesGuerin , The components are not specific to ENC. Please reach out through your Teledyne connections to discuss details.

[DavidGrant-NIWC]

Supported geometries by updateType

updateType	Point	MultiPoint	Curve	Surface	None
1: insert	valid	not valid	valid	valid	not valid
2: delete	valid	not valid	valid	valid	not valid
3: modify	valid	not valid	valid	valid	valid (no portrayal)
4: move	not valid	not valid	valid	not valid	valid (no portrayal)