To successfully use the Presentation Library ECDIS shall be capable of performing spatial queries on ENC data during import and symbolisation. Spatial query is understood as possibility to inspect graphical position and numerical value of spatial coordinates associated with a charted object. Spatial query could be available as a part of cursor pick (see 10.8) or as an independent function. Due to the complex nature of these queries it is recommended that the inspector of this requirement tests extensively that all required geometric primitives are accounted for in these tests and that the conditional symbology procedures are thoroughly understood during manufacture. Refer to section 12 for further details of which queries are required. Note: IHO S-64 contains examples of cases which an ECDIS shall be able to handle.
10.3 How to use the Look-Up Tables
Prior to drawing any chart objects on screen, the first action the ECDIS shall perform as a fail-safe measure, is to cover the screen with grey NODTA colour fill together with fill pattern NODATA03. Display priority is 0, supressed by radar, category “displaybase”, viewing group is 11050. This section describes how S57 features objects are converted to symbols, line and fill styles using the lookup tables. A number of ECDIS display requirements derived from the IMO Performance Standards and the IHO specifications are not handled by look-up tables. These are described in section 10.5.
The S-52 look-up tables are made up of five separate lists. The look-up tables specify how object classes are presented graphically on the chart display. Each look-up table entry contains six mandatory fields plus one optional field separated by commas “,” and using the double quote “ as a text delimiter for each value. The following lookup tables are defined:
Feature object acronym – This is the S-57 acronym for a particular feature class, e.g. BOYCAR, LNDARE etc. A default value of “######” is also defined.
Feature attribute combination – This field is used to define a set of feature attributes which may be matched. It consists of a concatenated list of valid S-57 attribute acronyms together with optional values. A line in the lookup tables matches a given feature object if, and only if, fields 1 and 2 match according to the rules defined in this section.
Symbolisation instructions. The instructions to be used to symbolise the feature objects. This may be composed of any of the symbolization commands defined in section XX of this document.
Display category – can be “DISPLAYBASE”, “STANDARD”, “OTHER”, “MARINERS”.
10.3.3 Matching Entries in the Lookup Tables
It is important to note that look-up table lines with the same feature object class in field 1 shall be grouped together and the order defined in the Presentation Library shall be preserved, to provide correct symbolization. The order of the attributes within a given line has no significance, but the order of the attribute values within a given attribute field (2) is significant. When a matching line is found for a feature object the lookup table line used for its symbology instructions shall then also be used for display priority, over radar flag, IMO category and optional viewing group unless modified by a conditional symbology procedure..
10.3.3.1 Look-Up Table Entry Matching
To find the symbology instruction for a specific object, enter the look-up table with the object's class code and gather all lines that contain the class code in field 1. If only a single line is found, field 2 of that line shall be empty and the object is always shown with the same symbology regardless of its description.
If there is more than one line in the look-up table, search for the first line each of whose attribute values in field 2 can also be found in the attribute values of the object. If more than one attribute value is given in the look-up table, the match to the object shall be exact, in order as well as content.
For example, a look-up table attribute value 4,3,4 is not matched by object attribute values 3,4,3 or 4,3. However, the existence of further attribute values does not invalidate the match: in the above example object attribute values 4,3,4,7 would match the look-up table, (because value 7 is not used in symbolizing). Use the symbology instruction given by that line in field 3 to symbolize the object's geometry. As a further example, an object "BCNLAT","COLOUR3,1", for which there is no exact match in the simplified point look-up table, shall be symbolized using the line for "BCNLAT","COLOUR3".
IMPORTANT: If no look-up table line can be identified where all attribute values in field 2 match the object's attributes, select the symbology instruction from the first line that contains the object class code in field 1. Field 2 of this line shall be empty and field 3 shall contain a fail-safe generic symbolization instruction.
10.3.3.2 Look-Up Table Attribute Matching
The rule in the paragraph above applies in the usual case when the look-up table contains specific values of the attribute in field 2. In this case fields 1 and 2 are of the general form: "OBJCLS", "ATTRBAiATTRBBj", where ATTRBA (attribute A) and ATTRBB (attribute B) are drawn from the SENC. Only values “i”" and “j” of ATTRBA and ATTRBB respectively will match.
Other forms of feature object/attribute matching may be used in certain cases:
(i) No value is given for the attribute value in field 2; the value is missing.
This look-up table line is of the form "OBJCLS", "ATTRBA".
It is used when the same symbolization is to be employed for all values of attribute A.
Any value of the attribute except «unknown» will give a match.
(ii) The placeholder “?” is given for the attribute value.
This look-up table line is of the form "OBJCLS", "ATTRBA?".
Only the attribute value=unknown (i.e., omitted in the data) will give a match in this case. S57 defines how “unknown” is encoded as a value for various attribute types.
Example: "DEPARE","DRVAL1?DRVAL2?","AC(NODTA);AP(PRTSUR01)" etc., is the symbolization for an incompletely surveyed area.
(iii) There is one instance where S‑57 uses the «omission» of a mandatory attribute (i.e., the mandatory attribute is not present and the attribute code is omitted) to code a specific object: “TSSLPT”,””, where ORIENT is omitted, codes a traffic junction.
In every other case, the first look-up table line for each object class omits all attributes and is used to give the default symbolization for that feature object..
10.3.3.3 Look-Up Table Conditional Symbology
For some object classes the relation between attribute values and symbology instruction is too complex or the presentation depends on Mariners' selection. Therefore a conditional symbology procedure is defined in the "symbolization instruction" field which in turn produces the symbology instructions for presentation and may modify the priority, the radar flag, the IMO category and/or viewing group.
10.3.3.4 Symbolizing a non-ENC object class
When there is no look-up table entry matching the object, the look-up table is incomplete or the object is of an unknown object class, the ECDIS presentation shall use the symbol ('QUESMRK1'). All known S-57 attributes permitted for ENCs that have been populated, shall be available for cursor enquiry. Values of unknown attributes shall also be available via the cursor enquiry.