alvarosanuy
commented
9 months ago Decisions made at Portrayal subWG meeting on 18/10/23
As per S-52, the expectation is that the 'Move' action will end up showing the existing S-52 symbology for both, the old (CHRVDELn) and the new (CHRVID0n ) location of the feature.
It was decided to experiment with the use an UpdateInformation Curve feature joining the old and the new locations and then symbolise it using an arrow shape pointing in the direction of the movement (CHCOR colour and thin linework). This approach will heavily rely on production software being able to automatically encode the UpdateInformation updateType=4 (move) feature and the corresponding 'Updated Information' Association. On the portrayal side, it's expected that the portrayal rule will not only show the UpdateInformation Curve feature as an arrow but, for Point geometries, also add the corresponding CHRVDELn symbol at the start of the arrow (From) and the corresponding CHRVID0n symbol at the end of it (To). For Curve and Surface features, data producers (assisted by production tools) will have to capture an UpdateInformation feature (Delete) using the geometry at origin and another UpdateInformation (Add) feature using the geometry at the new location of the feature. These 3 UpdateInformation meta features (Delete/Move/Add) will have to be linked together by using an 'Updated Association'.
Problem: The current 1.2.0 modelling for 'Updated Association' does not allow linking UpdatedInformation Meta features together, only Geographic features ...
- [x] Alvaro - Create Test datasets (once production tools are updated to handle FC 1.2.0) and supply to NIWC for testing of portrayal rules.
- [x] NIWC - Implement the above portrayal requirements for UpdateInformation, updateType=4 features of type Curve.
- [ ] @kusala9 - If S101PT approves to proceed with UpdateInformation as the replacement to the current 'ENC Update' review functionality in ECDIS, the use of the 'Arrow' will have to be detailed in S-98 Annex C (C-12.11.2). Also, refer to GitHub #152 for other proposed changes to S-98 on this topic.
DavidGrant-NIWC
Current methodology to represent features that were Moved by an ENC update are not ideal and may not be effective in conveying the right message to mariners. At the moment, 2 UpdateInformation features are generated, one with updateType=Delete and the other one with updateType=Add. As per S-52, there's no visual connection between the 2 actions and therefore the real world occurrence (i.e. a buoy was moved from A to B) may be misinterpreted by the mariner.
A comment from @TDYCARHugh in DCEGsWG issue https://github.com/iho-ohi/S-101-Documentation-and-FC/issues/41#top have some ideas on how modelling/encoding guidance could be improved to support this task:
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.
[ ] Can this modelling be leveraged and used to improve portrayal of 'Moved' features? How?
[ ] What other modelling and portrayal options could we consider?
Another thing that comes to my mind is that the 'ENC Update review' function in ECDIS generally brings up a dedicated window (can't confirm this is a requirement without further reading) where all different changes, a particular ENC update introduced (i.e. ED11 UD6), are listed. This is done using statements like 'BOYSPP moved' with the added benefit that mariners can select a particular entry and the ECDIS display will focus (zoom/center) on the location where the change occurred. If we get to bundle together both update types (Delete and Add) then the change description (BOYSPP moved) and the simultaneous highlighting of both UpdateInformation features could help resolving this issue ....
Note that this issue has dependencies with the symbolisation of deleted features as discussed in issue https://github.com/S-101-Portrayal-subWG/Working-Documents/issues/152