Closed alvarosanuy closed 10 months ago
To look into the INT1 Q63.
Portrayal subWG meeting - 12th January 2023
Alvaro mentioned that another (simpler) option would be to use the international abbreviation (Illum) as it is currently supported in S-4 & INT1.
Due to time constrains, it was decided to delay the decision until PC 1.2.0.
All subWG members are encouraged to provide their views by commenting in this issue before the next meeting.
DCEG 19.1.6:
Where a lighthouse is illuminated by flood lights, the additional value of status = 12 (illuminated) must also be populated.
This mean that a portrayal rule for Status=12 would be redundant when a LightAllAround with categoryOfLight=8, 9 or 11 is encoded. Btw, does anyone know why the flood light symbol (LIGHTS82) is different compared to the flood light symbol in S-4 (P63)?
Decisions made at Portrayal subWG meeting on 10/5/23
All
In reviewing the need for test data for this issue I noticed that LightAllAround does not have Status Illuminated as an allowable value so have added a Buidling Single feature with Status illuminated to support this.
Please expand if this does not meet the requirement for this issue.
All
TDS 19 has been updated to include a Building Single with Status Illuminated, please advise if further edits are required.
https://github.com/iho-ohi/S-101-Test-Datasets/tree/main/dev/cells/101AA00DS0019/7
Current portrayal:
With pick report:
This issue is marked for inclusion in the 1.2.0 PC. Expect that there will be issues with labels overwriting one another:
featureName
attribute which may require a labelstatus=12
will require a labelfeatureName
List of features which currently allow status=12
:
Building
AirportAirfield
Runway
Bridge
Conveyor
CableOverhead
PipelineOverhead
PylonBridgeSupport
FenceWall
Railway
Road
Landmark
SiloTank
WindTurbine
FortifiedStructure
ProductionStorageArea
Checkpoint
Pile
ShorelineConstruction
Causeway
Crane
Berth
MooringWarpingFacility
DryDock
FloatingDock
Pontoon
FishingFacility
OffshorePlatform
PipelineSubmarineOnLand
OffshoreProductionArea
BeaconLateral
BeaconCardinal
BeaconIsolatedDanger
BeaconSafeWater
BeaconSpecialPurposeGeneral
Daymark
SignalStationWarning
SignalStationTraffic
HarbourFacility
SmallCraftFacility
S-4 states, in section B-478.2, that:
Floodlighting should be depicted on charts mainly when it affects structures (for example: a pier; pier-head lighthouse) or dangers close to navigable water. Accordingly, I recommend we restrict the use of the text (Illum) to the features listed below. The rest would be discoverable via Pick report only. Also, recommend the label is positioned to the top left side (NW in North Up mode) of Point features and the center points of Curves (10 mm away?). For Surfaces should be placed to the NW as well but maybe further away to avoid clashing with large centered symbols (15 mmm away?). Preferred distances TBC with testing.
Building
Bridge
Conveyor
CableOverhead
PipelineOverhead
PylonBridgeSupport
Landmark
SiloTank
WindTurbine
FortifiedStructure
ProductionStorageArea
Pile
ShorelineConstruction
Causeway
Crane
Berth
MooringWarpingFacility
FloatingDock
Pontoon
OffshorePlatform
OffshoreProductionArea
BeaconLateral
BeaconCardinal
BeaconIsolatedDanger
BeaconSafeWater
BeaconSpecialPurposeGeneral
Daymark
SignalStationWarning
SignalStationTraffic
HarbourFacility
Decisions made at Portrayal subWG meeting on 10/5/23
- NIWC to implement the use of the INT abbreviation (Illum) when a feature has the attribute status = 12 (illuminated). Based on @KlasOstergren-SMA input, LightAllAround with categoryOfLight=8, 9 or 11 should be excluded from the proposed new mapping. Text parameters should be identical to the text string values used on the other status values (2, 7, 8, 11, 17) currently portrayed in S-101.
- Request Test Data
S-4 states, in section B-478.2, that:
Floodlighting should be depicted on charts mainly when it affects structures (for example: a pier; pier-head lighthouse) or dangers close to navigable water. Accordingly, I recommend we restrict the use of the text (Illum) to the features listed below. The rest would be discoverable via Pick report only. Also, recommend the label is positioned to the top left side (NW in North Up mode) of Point features and the center points of Curves (10 mm away?). For Surfaces should be placed to the NW as well but maybe further away to avoid clashing with large centered symbols (15 mmm away?). Preferred distances TBC with testing.
Do I understand this correctly that the LIGHTS82 symbol will longer be used in the portrayal catalogue? In our opinion, the label (illum) is redundant to the LIGHTS82 symbol and not vice versa. If we see a risk of having a label that clashes with other labels, why do we not use the LIGHTS82 symbol for the LightsAllAround feature instead? Since floodlights can be used to illuminate a danger close to navigable water, the symbol is preferable to a label which is more likely to be switched off by the user.
Do I understand this correctly that the LIGHTS82 symbol will longer be used in the portrayal catalogue?
Nothing changes in regards to the current use of LIGHTS82. Problem is, LIGHTS82 (and LIGHTS81 - see first Issue comment above) are only used to depict the 'illuminating' light (flood, strip and spot lights) not the structure being 'illuminated'.
This issue is about making sure that, when the scale is not large enough, and producers are not able to capture the 'illuminating' lights, the 'illuminated' structure portrays something that indicates to the mariner that it will stand out at night because it is illuminated.
At the last meeting we decided that, instead of trying to use LIGHTS82 (that could be harder to position at a default location that suits more than 30 different features types and geometries + some symbol rotation?), it would be easier to go with the INT Abbreviation (Illum) next to the structure instead.
Nothing changes in regards to the current use of LIGHTS82. Problem is, LIGHTS82 (and LIGHTS81 - see first Issue comment above) are only used to depict the 'illuminating' light (flood, strip and spot lights) not the structure being 'illuminated'.
Thank you Alvaro for the clarification!
Decisions made at Portrayal subWG meeting on 17/10/23 The group decided not to proceed with any option (symbol or abbreviation) due to the large number of features affected and the complexity of ensuring clutter is not introduced and display readability is not affected. It is important to note this change proposal did not come from Mariners and that S101 portrayal will behave as S-52 currently does.
Is it worth it considering additional portrayal for those features encoded with status == 12 (Illuminated)??
When encoding an illuminated feature at large scale compilers may decide to capture a Lights feature additionally to the illuminated feature itself [i.e using LightsAllAround_categoryOfLight = = 8 (Flood light) or 11(spot light) which display using LIGHTS82 or == 9 (Strip light) which uses LIGHTS81]. At smaller scales (or in small/short real world features) compilers may decide to use status == 12 on the feature instead. This encoding currently won't change the depiction of the illuminated feature. The info is only available through 'Pick report'.
An option would be to depict SY(LIGHTS82) when Status==12 (Illuminated) as an 'additional' symbology to the one used to depict the illuminated feature itself. Please note that, at the moment, there are 39 features in S-101 that can be encoded with Status==12 (Illuminated). Not sure a unique LIGHTS82 'symbol offset' would work for all possible symbol combinations ....