Light description not displayed for sector lights

[KlasOstergren-SMA]

I have noticed that the light description label is not shown for sector lights in the PC. For S-57 ECDIS I know that some show light description labels for all lights, while others don't show them for sector lights.

Based on end-user feedback, SMA proposes that the light description is shown for all lights if the mariner has turned on light descriptions. If the Portrayal Sub-group sees a problem with this approach, light descriptions should at least be shown for all lights associated with a TextPlacement feature.

The display of characteristics for sector lights is very important for night navigation in archipelagos areas where there are several sector lights and the water is narrow, so that you don't have time to do pick reports all the time.

[MikkoHovi-FI]

I agree with Klas on this. Light descriptions should be shown on sector lights as well.

I’d like to echo especially the point that with sector lights the description string is quite important in our waters. Just as an example, on Finnish paper charts the light description is always shown by default for sector lights, but never by default for floating lights to manage clutter.

[KlasOstergren-SMA]

As agreed at the last meeting, here is some guidance from S-4 on how to construct the light description when it applies to sector lights. As long as the character is the same for all sectors, it's basically the same rules as for other lights, except that there are multiple colours and can be multiple nominal ranges. The extracts from S-4 below show what the colour and nominal range should be. For a first simple test, the S-101 TestDataset 23 can be used. I will create a test dataset based on real world data as soon as possible.

[alvarosanuy]

@DavidGrant-NIWC - Any progress prototyping this change proposal?

[DavidGrant-NIWC]

I can start, but I'd like more/better test data.

Some implementation questions:

• What do you want to do when there are multiple sector characteristics?
• I assume this should incorporate labels for directional lights?
  • These are currently labeled independently.
• What should be shown if valueOfNominalRange isn't populated in a sector and that sector has the longest or shortest range?
  • What if none of the sectors have valueOfNominalRange populated?

[DavidGrant-NIWC]

Here's a prototype implementation describing a sector light in test dataset 23:

Fl(3) WRG 10s8-6M

While this might work for the majority of use cases, it (probably) won't work correctly when:

• There are multiple sectorCharacteristics
• valueOfNominalRange isn't populated for the longest/shortest range
• There is a directional light in one or more sectors
• One or more sectors have multiple colors (oscillating light sectors)
• Two sectors have the same colour with different valueOfNominalRange
• Other edge cases which haven't occured to me

[alvarosanuy]

@DavidGrant-NIWC - Thanks for the work so far. I'll let up to @KlasOstergren-SMA to work with you to move this forward after 2.0.0 (?). I'll update the label in this issue.

[KlasOstergren-SMA]

Here's a prototype implementation describing a sector light in test dataset 23: > Fl(3) WRG 10s8-6M

As far as I recall the discussion at the subgroup meeting, we agreed to focus on the "simple" cases as this will cover a very large percentage of all sector lights. Here are my inputs:

• valueOfNominalRange isn't populated for the longest/shortest range The portrayal should just show the populated values and if it's not poulated at all, just leave it out from the label. It is up to the data producer to decide what information is needed and have a proper encoding based on that.

• Two sectors have the same colour with different valueOfNominalRange Not sure I understand the issue here. Isn't the label just populated with the biggest and smallest value (as described in S-4)?

• There is a directional light in one or more sectors My opinion is that the Dir label is not needed in this cases as the user always will see the sector in the ENC compared to paper charts where there can be just a flare and the Dir label.

• There are multiple sectorCharacteristics Could this be shown ol multiple lines like it is on paper charts? I assume there will not be many cases where there are more than two different characteristics. If the screen becomes cluttered, the data producer can add a TextPlacement to avoid that.

• One or more sectors have multiple colors (oscillating light sectors) If we focus on the large number of cases, I think we can leave this cases for now without any label.

I welcome others optinions on this. @MikkoHovi-FI what do you think?

[MikkoHovi-FI]

Here's a prototype implementation describing a sector light in test dataset 23: Fl(3) WRG 10s8-6M

To be precise this should be Fl(3)WRG 10s8-6M (or Fl(3)WRG.10s8-6M) according to S-4 as there should not be a full stop (or a space) after a bracket.

As far as I recall the discussion at the subgroup meeting, we agreed to focus on the "simple" cases as this will cover a very large percentage of all sector lights. Here are my inputs:

• valueOfNominalRange isn't populated for the longest/shortest range

The portrayal should just show the populated values and if it's not poulated at all, just leave it out from the label. It is up to the data producer to decide what information is needed and have a proper encoding based on that.

Agree, using max and min of populated values should be sufficient to form the range element in the description.

• Two sectors have the same colour with different valueOfNominalRange

Not sure I understand the issue here. Isn't the label just populated with the biggest and smallest value (as described in S-4)?

The colours and ranges are not linked in the description string, thus this should not be an issue. And if we are talking about ordering the colours (as they should also be arranged according to descending range), then I would use max range within each colour for the ordering.

• There is a directional light in one or more sectors

My opinion is that the Dir label is not needed in this cases as the user always will see the sector in the ENC compared to paper charts where there can be just a flare and the Dir label.

I'd agree with Klas on this.

• There are multiple sectorCharacteristics

Could this be shown ol multiple lines like it is on paper charts? I assume there will not be many cases where there are more than two different characteristics. If the screen becomes cluttered, the data producer can add a TextPlacement to avoid that.

This also what I would do - one string per sectorCharacteristics and per line. The next question probably then will be the order of the lines. The logic in S-4 favors, I believe, description that includes the longest range first.

• One or more sectors have multiple colors (oscillating light sectors)

If we focus on the large number of cases, I think we can leave this cases for now without any label.

Agree, oscillating sectors are still a marginal case. And I guess the same approach would do with other more complex cases as well.

For example, my estimate is that of the 2550 (of which 422 have multiple sectors) Finnish sector lights the 'simple cases' would be able cover at least 99.5 %, if not all. I'm pretty confident about this, because our paper chart production line already creates S-4 compliant light description strings (including the allowed abridged alternatives) automatically in from S-57 data using xslt, and so far we haven't found a case it can't do. We don't however have any of the most extreme cases possible around.

[DavidGrant-NIWC]

Here's a prototype implementation describing a sector light in test dataset 23: Fl(3) WRG 10s8-6M

To be precise this should be Fl(3)WRG 10s8-6M (or Fl(3)WRG.10s8-6M) according to S-4 as there should not be a full stop (or a space) after a bracket.

This just leverages S-52 10.6.3 / LITDSN02 which permits a space

As far as I recall the discussion at the subgroup meeting, we agreed to focus on the "simple" cases as this will cover a very large percentage of all sector lights. Here are my inputs:

• valueOfNominalRange isn't populated for the longest/shortest range

The portrayal should just show the populated values and if it's not populated at all, just leave it out from the label. It is up to the data producer to decide what information is needed and have a proper encoding based on that.

Agree, using max and min of populated values should be sufficient to form the range element in the description.

This would result in something like: Fl(3) WRG 10s8M

• Two sectors have the same colour with different valueOfNominalRange

Not sure I understand the issue here. Isn't the label just populated with the biggest and smallest value (as described in S-4)?

The colours and ranges are not linked in the description string, thus this should not be an issue. And if we are talking about ordering the colours (as they should also be arranged according to descending range), then I would use max range within each colour for the ordering.

The portrayal is attempting to order the colors by descending range. We can use max range if that is agreed upon.

• There is a directional light in one or more sectors

My opinion is that the Dir label is not needed in this cases as the user always will see the sector in the ENC compared to paper charts where there can be just a flare and the Dir label.

I'd agree with Klas on this.

👍

• There are multiple sectorCharacteristics

Could this be shown ol multiple lines like it is on paper charts? I assume there will not be many cases where there are more than two different characteristics. If the screen becomes cluttered, the data producer can add a TextPlacement to avoid that.

This also what I would do - one string per sectorCharacteristics and per line. The next question probably then will be the order of the lines. The logic in S-4 favors, I believe, description that includes the longest range first.

This is probably the biggest issue to overcome. Although we could output multiple lines, that would break TextPlacement because TextPlacement can only alter the placement of a single output string. There is also no way to distinguish between different lines of a light description (because it is presumed to be a single string).

I'll have to look into the TextPlacement implementation to see if we can do something about this.

• One or more sectors have multiple colors (oscillating light sectors)

If we focus on the large number of cases, I think we can leave this cases for now without any label.

Agree, oscillating sectors are still a marginal case. And I guess the same approach would do with other more complex cases as well.

For example, my estimate is that of the 2550 (of which 422 have multiple sectors) Finnish sector lights the 'simple cases' would be able cover at least 99.5 %, if not all. I'm pretty confident about this, because our paper chart production line already creates S-4 compliant light description strings (including the allowed abridged alternatives) automatically in from S-57 data using xslt, and so far we haven't found a case it can't do. We don't however have any of the most extreme cases possible around.

Ok. My concern is that an unexpected edge case doesn't break the portrayal.

[DavidGrant-NIWC]

Here is what the current portrayal looks like with the test data that I have available:

Test dataset (TDS) 19, single sector characteristics, with sector line length, no text placement:

TDS19, multiple sector characteristics, no sector line length, no text placement:

TDS23, with text placement:

TDS TextAlignv4 (from Klas):

[alvarosanuy]

Implemented in PC 1.4.0