Non-Display of Encoding Combinations in ECDIS

[JeffWootton]

Refer to S-101 Portrayal Sub-WG issue #35 at https://github.com/S-101-Portrayal-subWG/Working-Documents/issues/35.

The above Portrayal GitHub issue is specific to the encoding of enumerate attribute type catgoryOfSlopingGround values 5 and 7, however there are many other encoding combinations inherited from S-57/S-52 that do not display in ECDIS.

The proposal to the Portrayal Sub-Group was to remove values 5 and 7 as allowable values for catgoryOfSlopingGround. The decision from the Sub-Group was to leave as is for now, however this still results in allowable encoding combinations having no display in the ECDIS. For S-101 ENC, what is the point of allowing encoding that cannot be visualized or prompt further investigation by the mariner?

This is not to say that this modelling cannot be included in a Data Producers' source database - just that such encoding will not be exported to S-101. A conclusion from the Portrayal Sub-Group was that this is a decision for individual Data Producers, however it is suggested that the requirement for such information to be included and subsequently portrayed in the navigational ENC should be raised with the IHO NCWG for possible revision to S-4.

NOTE: Feedback from PRIMAR on instances of the population of categoryOfSlopingGround values 5 and 7 in existing ENCs: "As per the discussions at the meeting on 12/7/22 regarding the discontinuation of the values of "5" & "7" impact on current ENC encodings and for DCEG SubWG further discussions and consideratin. As per the situation in July 2022 in PRIMAR RENC DB available ENC data: From bit more than 100 000 features with CATSLO encoded in bit more than 5 000 ENCs there are CATSLO "5" - 41 features in 7 ENCs (CA, CN), and CATSLO "7" - 16 features in 12 ENCs (AR, EC, GB, PT, RU). In some cases these objects have also OBJNAM encoded, including word "pingo" or "scree".

In total affected would be 57 features in 19 ENCs.

Disclaimer - this data is only indicative of the encoding practices, as does not include data from some HOs - either not members of the RENCs or distribution arrangements exclude the distribution through PRIMAR RENC."

[alvarosanuy]

This topic was opened by the PsWG https://github.com/S-101-Portrayal-subWG/Working-Documents/issues/35 due to an DCEG subWG request. The intention was to remove encoding workarounds that were introduced in the S-57 UOC (and now inherited by the DCEG) with the only purpose of ensuring ECDIS portrayal. In this particular case the following statement exists in section 5.14.1 of the DCEG:

Remarks:

• Sloping Ground of type surface that are not radar conspicuous (that is, radar conspicuous not populated)) and having attribute category of slope = 1 (cutting), 2 (embankment), 3 (dune), 4 (hill), 5 (pingo) or 7 (scree) do not symbolise in the ECDIS. Where it is required to encode such areas, alternative features such as Landmark or Vegetation should be used.

The solution may be in ignoring the value of categoryOfSlope and rather focus on implementing portrayal based on 'conspicuousness' rather than on the category of the slope. This would affect both, SlopingGround and SlopeTopline features. All geometry types should have a default portrayal based on the values of the attributes radarConspicuous and visualProminence (irrespective of the value of categoryOfSlope):

• radarConspicuous=False & visualProminence<>1 or 3 then: use LANDF colour for Curves and Surface boundary (no infill). Use SY(HILTOP01) for Point features.
• radarConspicuous=False & visualProminence=1 or 3 then: use CHBLK colour for Curves and Surface boundary (no infill). Use SY(HILTOP11) for Point features.
• radarConspicuous=True & visualProminence<>1 or 3 then: use CHGRD colour for Curves and Surface boundary (infill - line patter made of evenly spaced, thinner lines tilted 30 degrees from the vertical). Develop new point symbol based on SY(HILTOP01) but in CHGRD.
• radarConspicuous=True & visualProminence=1 or 3 then: Curves - use CHBLK colour line intersected by a pattern of evenly spaced, thinner lines tilted 30 degrees from the vertical and in CHGRD colour. Surface - boundary in CHBLK (infill - thin line patter made of evenly spaced lines tilted 30 degrees from the vertical and in CHGRD colour). Develop new point symbol based on SY(HILTOP11) but with thin line patter made of evenly spaced lines tilted 30 degrees from the vertical and in CHGRD colour covering the center of the symbol. Another option is to fill the center of the symbol with CHGRD colour.

Note: The assumption is that mariners would like to distinguish between features that are visually prominent from those that may not be but are radar conspicuous. Some features may be both .......

[LeoKuzmin]

The radar conspicuous natural feature (e.g. Coastline) is depicted in additional with a thick magenta line as a background. I suppose, it makes sense to use the same method for linear and area borders of the SloppingGround features.

[alvarosanuy]

The radar conspicuous natural feature (e.g. Coastline) is depicted in additional with a thick magenta line as a background. I suppose, it makes sense to use the same method for linear and area borders of the SloppingGround features.

I can't find an entry for COALNE; CONRAD1 in S-52 LUT.............. (??). The only thing I was able to find is a picture showing what Leo describes (magenta line behind coastline) in UKHO's NP5012 (2015 Ed). Anyone has more info on this????

[LeoKuzmin]

It is implemented by the QUALIN02 script: elseif feature.Code == 'Coastline' then if feature.radarConspicuous == 1 then featurePortrayal:SimpleLineStyle('solid',0.96,'CHMGF') featurePortrayal:AddInstructions('LineInstruction:_simple_') end

[alvarosanuy]

It is implemented by the QUALIN02 script: elseif feature.Code == 'Coastline' then if feature.radarConspicuous == 1 then featurePortrayal:SimpleLineStyle('solid',0.96,'CHMGF') featurePortrayal:AddInstructions('LineInstruction:_simple_') end

Thanks Leo.

Interesting to find out that QUALIN01 has been used to restrict a portrayal instruction.
The instructions do not allow the 'radar conspicuous' symbolization to be depicted on sections of a feature when edges have QUAPOS and this is <> 1, 10 or,11. The instruction overwrites the HO's intent. Despite of encoding CONRAD=1 on a COALNE feature, the information won't be always visually conveyed to the user. If COALNE has sections that are 'approximate', ECDIS will only show the magenta colour on the sections (edges) with QUAPOS = 1, 10 or 11 (or empty) Although there may be valid reasons for not using CONRAD=1 on approximate features as mariners won't be able to accurately project the radar distance from the charted feature, 'hiding' the CONRAD attribute encoded by the producer through a CSP may not be the best (or at least the only) way it should be done. The existing DCEG Remarks for the feature must explain the portrayal constrain introduced by the CSP and therefore discourage the encoding of CONRAD=1 in features (i.e. coastline) having sections (edges) that are 'approximate' in nature (expressed through the use of some QUAPOS values). I think that many HOs may not be aware that some QUAPOS values are restricting portrayal in ECDIS.

[Christian-Shom]

Shom hardly ever encodes CONRAD=1 due to lack of information from mariners (or lack of guidance to cartographers...). I suspect this is the case for many other HOs. Consequently, the use of 'radar conspicuous', although a good idea, might not be an efficient solution. If we want to keep these encodings, why not having a common symbology and display "Scree", "Pingo", etc. (this would rejoin the current encoding of OBJNAM by some HOs).

[JeffWootton]

Summary of discussions at DCEG Sub-Group Meeting 3 (05-06 October 2022):

DCEG Clause: 5.8, 5.14.1, 5.9, 5.12, 6.4

Points to Note:

• Proposal is that ENC encoding combinations that do not display in ECDIS should be removed from S-101 as they provide no information to the mariner.
• It is also suggested that these encodings are brought to the attention of the NCWG for advice and/or possible amendments to S-4.
• Important to note that removing from S-101 does not mean that this encoding cannot be retained in source databases.
• Note Alvaro comment in the GitHub suggesting that portrayal is related to visualProminence as well as radarConspicuous. [Alvaro to comment?]
• All following comments in the GitHub related only to portrayal so irrelevant for DCEG.

Discussion/Decision:

• It was proposed that there are two options for proceeding with this issue: Remove the non-portrayal encoding combinations from the DCEG now; or request NCWG advice and if feedback is that the information should be displayed in the ECDIS then provide this feedback to the Portrayal Sub-Group.
• NCWG Chair pointed out that even in INT1 there were entries that had no accompanying chart symbol – these entries were added as “placeholders” for future consideration or national symbol adoption.

Action: - Issue to be brought to the attention of the NCWG. paper to be submitted to the NCWG8 meeting (November 2022) (IHO Sec). - No change at this time to the DCEG. [Ongoing] - GitHub issue to remain open for further input (All). [Ongoing]

Refer:
NCWG8_2022_06.10A_EN_Non-Portrayal_of_Information_in_ENC_V1.pdf

S-101PT9_2022_06.1AA_EN_DCEG_Sub-Group_Report_Preso.pdf

The recommendations included in paper NCWG8-06.10A were approved by the NCWG and further ratified by S-101PT. Corresponding amendments made to DCEG EDition 1.1.0. All outstanding issues related to the non-display of encoding combinations in ECDIS have been resolved in accordance with these decisions. Close Issue.