NIWC Testbed Update - Slide # 35 - S-101 Feature dependency issues

[alvarosanuy]

S-101PT5 Action 24 - Discuss paper S-101PT5-21

S-101PT5_21_EN_NIWC Test Bed Report_S101PT5_V1.pdf

[DavidGrant-NIWC]

Assumption is that the light should be dependent on the buoy, but the buoy should not be dependent on the light (e.g. the second figure is ok, the third is not).

More generally, should visibility of equipment always be dependent on visibility of the structure - will need to (try to) implement via portrayal rules.

[alvarosanuy]

Agree

[TDYCARHugh]

The concept of portrayal is that the drawing instructions could be used as a display list which is generated in advance and at draw time the display list is only filtered by options such as viewing groups. Turning on/off viewing groups would ideally not require the display lists to be regenerated. The viewing groups act only as filters on the display list. If at draw time we need to traverse feature associations and determine if associated features are being drawn or not it could have a significant impact on system design and performance. I expect that the buoys are being turned on/off by viewing groups.
If we could allow a drawing instruction to have more than one viewing group it might be used to address this issue.

Allow more than one viewing group on a drawing instruction and a flag to indicate whether all or any viewing group in the list must be on for the drawing instruction to be displayed. In this case the light symbol and text instructions would have 2 viewing groups, one for the buoys and one for lights. With the condition that all viewing groups need to be active. So the light symbol and text will not show if the lights group is off or if the buoy group is off.

[DavidGrant-NIWC]

[…] Turning on/off viewing groups would ideally not require the display lists to be regenerated. […] If at draw time we need to traverse feature associations and determine if associated features are being drawn or not it could have a significant impact on system design and performance.

TSM7 proposed symbol dependency to address this gap; S-100WG5 accepted these changes - the visualization of a symbol can now be dependent on a parent symbol. This change eliminates the need to regenerate the portrayal or to traverse the feature associations (the portrayal rules determine the dependency once).

The concept was intended to support dependencies during symbolization of a given feature. For instance, a feature may have multiple symbols/text, each with independent viewing groups - a label on a light for example. The label should turn off when the light is off, despite the fact that they have independent viewing groups. INFORM and CHDATD are some other examples.

Note that viewing groups are not the only way that symbols can be turned off - scale min/max, line suppression, date dependency, and hover over can also turn off symbols.

What we need to determine is if the symbol dependency concept can be leveraged to support cross-feature dependencies (e.g. buoy and light). To do so requires using id and parentId to uniquely identify drawing instructions within the entire portrayal. Currently id and parentId only need to be unique for a given feature instance.

Here are two slides from TSM7 "Capability Gaps in the S-100 Portrayal Model":

[TDYCARHugh]

"Note that viewing groups are not the only way that symbols can be turned off" - agreed. "TSM7 proposed symbol dependency to address this gap" - agreed.

So what is this Issue about? Is it just a request to modify the PC to include dependency assignment in the rule logic?

[DavidGrant-NIWC]

We just need agreement on what the symbolization should look like when one of the features is off:

Assumption is that the light should be dependent on the buoy, but the buoy should not be dependent on the light (e.g. the second figure is ok, the third is not).

Also:

More generally, should visibility of equipment always be dependent on visibility of the structure - will need to (try to) implement via portrayal rules.

[alvarosanuy]

TSM7 proposed symbol dependency to address this gap; S-100WG5 accepted these changes - the visualization of a symbol can now be dependent on a parent symbol.

• Can we get a list of specific feature combinations NIWC understands would benefit from the 'feature dependency' changes to S100 approved by S100WG5?
• Does the concept of 'parent' symbol rely on the existence of: a) an structure-equipment relationship; b) an aggregation or an association; c) none of the previous ?
• What are S-52 limitations on this topic? As far as I remember text display, for example, relies on the visibility of the object itself and I do not remember being able to turn navaid structures off and leave the display of lights on (the other way around was possible though). Was this just an OEM specific implementation without no real S-52 requirement?

.

[DavidGrant-NIWC]

TSM7 proposed symbol dependency to address this gap; S-100WG5 accepted these changes - the visualization of a symbol can now be dependent on a parent symbol.

• Can we get a list of specific feature combinations NIWC understands would benefit from the 'feature dependency' changes to S100 approved by S100WG5?

The change was mainly to support text (text should only be shown if the "parent" symbol is visible), but is needed for any feature which could have symbolization which uses multiple viewing groups, multiple scamin/scamax values, symbols added to lines which may be affected by line suppression, etc.

• Does the concept of 'parent' symbol rely on the existence of: a) an structure-equipment relationship; b) an aggregation or an association; c) none of the previous ?

c) none of the previous. It is strictly a concept realized as part of the portrayal drawing instructions; it is not dependent on information contained within the feature catalogue.

• What are S-52 limitations on this topic? As far as I remember text display, for example, relies on the visibility of the object itself and I do not remember being able to turn navaid structures off and leave the display of lights on (the other way around was possible though). Was this just an OEM specific implementation without no real S-52 requirement?

I believe S-52 only provides a written requirement for text. It is likely OEMs implement as you describe, otherwise it would be confusing to mariners.

[alvarosanuy]

Would a review of the features listed in each Viewing Group be a reasonable starting point? We would be looking at objects that only 'make sense' when displayed at the same time (i.e. light flare with buoy symbol). The goal would be identifying features that are allocated to different VGs but can't always be turned on/off independently (i.e. Buoy without a light during daytime navigation is ok but light flare without a buoy during nigh time navigation is (may) not).

Is something like this NIWC is after???

[DavidGrant-NIWC]

We have started by looking at features which have a FeatureAssociation (StructureEquipment, UpdatedInformation, etc.). The next step would be identifying any features which do not have a FeatureAssociation but do have a visibility dependency - there may not be any.

We are still evaluating various implementation mechanisms, but we have determined that it will be possible to implement the desired functionality. Some minor changes to S-100 may (or may not) be required depending on which mechanism is chosen.

[alvarosanuy]

That's fine. Thanks for the update and please let the subWG know as soon as you have your draft instructions and implementation options ready for review.

[DavidGrant-NIWC]

We are currently updating the (unofficial) PC to add these dependencies; we will provide a list of the affected features and/or associations once complete.

We plan to submit an S-100 change proposal for TSM8 / S-100WG6 which supports these changes. The change is to the Parent instruction in S-100 Part 9a - it adds a featureID parameter:

[DavidGrant-NIWC]

https://user-images.githubusercontent.com/62906211/108766664-70b2c000-7523-11eb-8984-ab83155e136e.mp4

[DavidGrant-NIWC]

We recommend this issue be closed.

After extensive testing, we propose that features should not be dependent on one another; display of equipment should not be dependent on display of the structure (e.g. display of lights should not be dependent on display of buoys).

This is consistent with S-52; see S-64 test 3.3.11 where lights are shown on with buoys off.

The prototype implementation worked as intended, and in isolation appears desirable (see video in previous message). The issue is that when buoys are turned off via their viewing group, unsafe portrayals can be produced where only some of the lights on the chart are displayed (e.g. the ones which are not associated with a buoy).

These unsafe portrayals violate IEC 61174 4.3.3 para 9, which requires that all members of a viewing group turn on and off together:

The mariner may presume that all lights are being displayed when in reality lights associated with buoys are not being displayed. Note the missing light (highlighted):

Buoys Off	Buoys On

[alvarosanuy]

Closed at NIWC's request.