Display parameters for 'New Text'

[alvarosanuy]

https://github.com/iho-ohi/S-101_Portrayal-Catalogue/issues/61

@DavidGrant-NIWC made the following statement in their Github space (see link above):

Someone needs to define the display parameters for features with the feature name attribute which:

- [ ] Didn't exist in S-57 - [ ] Existed in S-57 but didn't display OBJNAM (or didn't have OBJNAM)

An example is DISMAR / DistanceMark. DISMAR has an OBJNAM attribute in S-57, but S-52 doesn't display it. In S-101 DistanceMark has a featureName attribute and nothing prevents an encoder from setting featureName.displayName to true.

Either it should be clarified that featureName.displayName should never be set to true for these features, or display parameters should be provided corresponding to the S-52 TX/TE instructions: TX(OBJNAM,1,2,2,'15110',0,1,CHBLK,26)

I think we first need to identify all existing instances described above and then discuss the best way forward.

Somebody would like to volunteer to collate this info for us?

[alvarosanuy]

Portrayal subWG meeting - 12th January 2023

1. The subWG agreed that if, featureName and displayName are allowable attributes for a feature, the expectation is to see featureName display when displayName is encoded as Yes.

2. It was decided to use a unique standardised text instruction for all instances not previously described in S-52.

3. NIWC will asses S-52 text variations and implement, in PC 1.1.0, the most used option for testing purposes.

4. It would be very useful if NIWC can provide a list of features that fall in this category so test data can be produced and their display reviewed accordingly.

[mikan66]

From S-52 we have the following: TE or TX commands = 445 instances With OBJNAM = 293 With other attributes = INFORM(6), ORIENT(24), VER*(42) and so on.

Now if we need to drill down deeper like Dave's comment about DISMAR having attribute OBJNAM and no display rule, that will require manually walking the UOC and comparing to each S-52 display rules.

[alvarosanuy]

From S-52 we have the following: TE or TX commands = 445 instances With OBJNAM = 293 With other attributes = INFORM(6), ORIENT(24), VER*(42) and so on.

Now if we need to drill down deeper like Dave's comment about DISMAR having attribute OBJNAM and no display rule, that will require manually walking the UOC and comparing to each S-52 display rules.

@mikan66 - Any chance of getting a report out of the latest FC instead of visually scanning though the DCEG??

[mikan66]

@alvarosanuy regarding "Any chance of getting a report out of the latest FC instead of visually scanning though the DCEG?", I'm not sure what you want me to find within the 1.1.0 FC? I have a list of features with "featureName", but the lower multiplicity is usually ZERO.

[TDYCARHugh]

List of Features that can have a featureName:

AdministrationArea AirportAirfield AnchorBerth AnchorageArea ArchipelagicSeaLane ArchipelagicSeaLaneArea ArchipelagicSeaLaneAxis BeaconCardinal BeaconIsolatedDanger BeaconLateral BeaconSafeWater BeaconSpecialPurposeGeneral Berth Bridge Building BuiltUpArea BuoyCardinal BuoyEmergencyWreckMarking BuoyInstallation BuoyIsolatedDanger BuoyLateral BuoySafeWater BuoySpecialPurposeGeneral CableArea CableOverhead CableSubmarine Canal CargoTranshipmentArea Causeway Checkpoint CoastGuardStation Coastline CollisionRegulationsLimit ContinentalShelfArea Conveyor Crane CurrentNonGravitational Dam Daymark DeepWaterRoute DeepWaterRouteCentreline DeepWaterRoutePart DistanceMark DockArea DredgedArea DryDock DumpingGround Dyke Fairway FairwaySystem FenceWall FerryRoute FisheryZone FishingFacility FishingGround FloatingDock FogSignal FortifiedStructure FoulGround FreePortArea Gate Gridiron HarbourAreaAdministrative HarbourFacility Hulk IceArea InformationArea IslandGroup Lake LandArea LandElevation LandRegion Landmark LightAirObstruction LightAllAround LightFloat LightFogDetector LightSectored LightVessel LocalMagneticAnomaly LockBasin LogPond MarineFarmCulture MarinePollutionRegulationsArea MilitaryPracticeArea MooringTrot MooringWarpingFacility Obstruction OffshorePlatform OffshoreProductionArea OilBarrier PhysicalAISAidToNavigation Pile PilotBoardingPlace PilotageDistrict PipelineOverhead PipelineSubmarineOnLand Pontoon PrecautionaryArea ProductionStorageArea PylonBridgeSupport RadarLine RadarRange RadarStation RadarTransponderBeacon RadioCallingInPoint RadioStation Railway RangeSystem Rapids RecommendedRouteCentreline RecommendedTrack RescueStation RestrictedAreaNavigational RestrictedAreaRegulatory River Road Runway SeaAreaNamedWaterArea SeabedArea Seagrass SeaplaneLandingArea ShorelineConstruction SignalStationTraffic SignalStationWarning SiloTank SlopeTopline SlopingGround SmallCraftFacility Sounding Spring SubmarinePipelineArea SubmarineTransitLane TidalStreamFloodEbb TidalStreamPanelData Tideway TrafficSeparationScheme Tunnel TwoWayRoute UnderwaterAwashRock Vegetation VesselTrafficServiceArea VirtualAISAidToNavigation WaterTurbulence Waterfall WeedKelp WindTurbine Wreck

[alvarosanuy]

SCOPE:

1. Make sure all features that have featureName as a valid attribute have text instructions to display them when displayText=Yes.

• [ ] Identify the features to be reviewed - @TDYCARHugh and Tom Richardson have provided a list of the features that need to be reviewed and text instructions added when missing. Action: NIWC to review each feature and add text instruction (see below) when missing.
• [ ] Identify the most suitable (generic) text instructions to be used based on a review of text instructions in S-52 - @DavidGrant-NIWC proposed: TX(OBJNAM,1,2,2,'15110',0,1,CHBLK,26). Action: Nil (Done) Note that in some instances CHBLK may not be the right colour. I recommend start by using the generic text outlined above in PC 1.1.0 and develop a test cell that includes all the listed features with featureName populated and set to display. A new issue can be created by the Test Cells sWG to go through the different text displays and assess their suitability (goal would be completing the review and amendments for PC 1.2.0). Action: Test Cells sWG lead to coordinate the development of test cells, their review and recommendations to the PsWG.

[TomRichardson6]

@alvarosanuy The final action this is a fairly significant task given the number of features, we may struggle to do this in time for PC1.1.0. I assume that all features with existing S-52 instructions are catered for. So I would propose that we focus on the new features only (yellow fill in the spreadsheet I provided) and for all other features that didn't have an S-52 instruction the generic instruction is used. The issue could then be held open to do this review for 1.2.0.

[alvarosanuy]

Work done by @TomRichardson6 to assist with this task

Extracted all features with Feature Name present in FC 1.1.0

Used the S-52 (Preslib 4.0.2) to indicate features as follows;

Green name was displayed in S-52

Yellow – new feature or potential to review e.g. Buoy Emergency… should display as other buoys do

My suggestions are in col I

Other – name doesn’t display and suggest review not needed.

One caveat is that I mapped the S-52 rules at the object level only so I didn’t check whether for some of the objects OBJNAM only displays based on specific attribute combinations.

Attached are the combined S-52 lookups I used.

S-52 Preslib 4.0.2 Combined Lookups 20190905.xlsx

FeatureNameSummary.xlsx

[alvarosanuy]

@TomRichardson6

Other – name doesn’t display and suggest review not needed.

The decision made by the PsWG at its last meeting was:

Portrayal subWG meeting - 12th January 2023

The subWG agreed that if, featureName and displayName are allowable attributes for a feature, the expectation is to see featureName display when displayName is encoded as Yes.

For those features in S-52 that have OBJNAM as a valid attribute but not text instructions to display it (discoverable by pick report only), the S-57 to S-101 conversion will populate displayName=NO. The question is what happens if the producer decides to switch it to YES. This is not an option in S-52 but, in S-101, this is now different and the 'power' sits with the encoder.

If we want to restrict producers from deciding what text they want to display in their ENCs, then we need to look at 'selectively' locking or removing the displayName sub attribute from the complex attribute featureName in certain features. Not sure this is even possible! A softer approach is to try to control encoding by Validation checks. To forbid the use of displayName on certain features we should be looking at Critical errors. Are they really critical?

If implementing what was decided by the PsWG at their last meeting is too hard we then need to look at other alternatives like 'restricting encoding' as detailed above but, is this any easier ??

[TomRichardson6]

@alvarosanuy I wasn't very clear, to clarify;

By Other doesn't display I mean does not display in S-52. I support S-101 displaying these names where displayName is True but for 1.1.0 I think we can just go with that default instruction in all of those cases and tailor the text colour etc in 1.2.0.

Fully support producers being able to control this display and I see it as an S-101 benefit putting the cartography back to some extent.

Hope that clarifies.

[mikan66]

So, a quick manual search of existing Lua rules with Text Instructions is contained in the attached file (look to the far right columns). There are a few rules, like SpanFixed.lua that weren't on this list or found with my simple search tool. I also see it's not on Hugh's list either.

Questions:

1. Do I need to validate each EXISTING Text Instruction rule for proper display of text "if and only if displayName is true"? This might be an easy change if applied uniformly to ever feature.
2. What do you want me to do for all the other entries that don't have Text Instructions, (looks like significant effort to analyze all the features with No Text entries). FeatureNameSummary.xlsx

[TDYCARHugh]

I got my list from the latest FC which should match the DCEG where Span FIxed does not include a feature name attribute. The original intention for the use of display name was to indicate which name to use when multiple names have been encoded. There was discussion about the possibility of having a long and short name and then use display name = true on the short name to have it be shown.
Using the display name boolean for cartographic decisions about showing a name or not should be discussed and documented because it could impact portrayal logic. Also the display name attribute is optional (so is language) and if there is only one name and no display name or language I would expect the default to be to assume that it is to English and to be shown.

[alvarosanuy]

I think that, like with the UpdateInformation feature, there are different views on how featureName should be used in practice, particularly considering that:

• an infinite number of these complex attributes can be created for the same one feature
• some sub attributes (e.g language) that can be the trigger for priority display are not mandatory and, even if they were, there's nothing limiting the producer from encoding the same value (e.g english) in more than one featureName instance.
• several featureName attribute instances can be marked as 'display' (displayName=True) and no rules exist on how to show all of them at the same time without clashing on each other.

Also, is the behaviour of the context parameter 'national language' defined anywhere? If the value selected is not 'eng', would ECDIS turn OFF any name having english or empty/unknown and turn ON names encoded with language = to the selected language or would it keep english when the selected language does not exist for the same feature? How would ECDIS manage/display several names encoded on the same feature if they have the the same language and this matches the value selected for 'national language'?

The questions keep piling up for me.

Are you keen for dedicated 2hrs VTC meeting sometime next week on this topic? I think we need to make sure Jeff and OEM representatives attend as well.

At this point in time I am recommending we:

1. Ensure all S101 rules related to S-57 objects that have, in the S-52 LUT, an attribute combination entry that includes TX instructions includes a command to display the same text string when name has a value and displayName=True. - GOAL for PC 1.1.0.
2. Delay the full implementation of featureName for PC 1.2.0 or later to give us time to discuss, in more detail, all possible encoding and implementation issues.
3. Meet next week by VTC to put on the table all our concerns and make sure we have a way ahead (implementation solution) for each of them. We may even need to tap into modelling to get around some of these issues....

[TomRichardson6]

@alvarosanuy I support the recommendations and can be available to meet and reach a consensus for 1.1.0 on this noting we can refine in 1.2.0 based on experience gained. I would hope we can have some functionality in place for 1.1.0 to support testing and I can note any known limitations in the planned release notes.

I think it will be necessary to make some initial assumptions on the use of feature name which when validated can be included in the DCEG and within validation checks. Right now we only have the old check for name equal to national language name. Some ideas;

1. If multiple instances of the featureName complex attribute are present only 1 should have displayName = True. This can be enforced by a validation check with severity Error.

2. If national language is enabled then all text attributes with a language value other than eng display with those values, if no language value is present on any values for that complex that value still displays. Potential for multiple values with the same language is addressed by assumption 1 above.

3. Excessive use of feature name should be minimized to only navigationally relevant names.

4. If no values of featureName have displayName = True the name shall only display if the feature has a rule in S-52 or its new and its been added to that list.

[mikan66]

Next week is difficult for me to meet except for Monday. My presence is not required for the way-ahead decisions. I draw your attention to this related topic for the "no geometry" features which have their own routine for now (right side of picture). There have been no changes in the general case on this topic (left side and see the full issue thread from the top PC #61).

https://github.com/iho-ohi/S-101_Portrayal-Catalogue/issues/61#issuecomment-1433053443

[MikusRL]

My 5 cents to @TomRichardson6 last comment:

1. Agree, but it should work like that for every single language encoded (only like mentioned at the end of bullet point 2). If no language is encoded - it is expected that it is in eng, or readable with eng characterset. If as is written in bullet point 1now - ECDIS can suddenly portray Names in language you can not read, and you will need to find switch to force to show default - eng. And default eng Name still to be mandatory, as was for S-57, if any other language encoded too. Also, if Name is considered navigationaly significant, it should be so in all encoded languages, hence should be displaying one Name in all your selected language modes of ECDIS, or not displaying in any language. Then the rest of the encoded additional same language versions must be dislayName = False, and available only through the pick report.
2. I think this needs to be better than that, just because if from all other languages one Name will display, that is without thinking a clutter of screen, where even two different other national languages are encoded. There must be designed new choice in ECDIS, that mariner can select from the national language list of available languages from within the datasets available, rather than just a choice of "eng" or "national language". Then the problem is solved. Would this need the @alvarosanuy mentioned modelling? Maybe for 1.2.0? Definitely for 2.0.0.
3. Yes, and it should be applied with the same rationale for all languages the dataset is encoded in, hence returning to bullet point 1 - if more than one language encoded, then max. one entry for each language is set to displayName=True.
4. Agree. If not in S-52 or not added to that list already, then only available in pick report. And thinking further, even the pick report could be overload of info, especially if unreadable for you, so could "hide" the non mariner chosen language entries, but that is already other discussion I guess.

[TomRichardson6]

@MikusRL you are correct I'll try again for 1.

1. If multiple instances of the featureName complex attribute are present only 1 should have displayName = True. If multiple values have different values for language then they can have displayName = True. This can be enforced by a validation check with severity Error.

On your 2. I'm not so sure, as I understand if the use of national language in ECDIS is primarily where vessels are engaged on voyages within one countries waters rather than vessels trading internationally where the default of English would generally be used. Maybe we need more user engagement on this before we define such a solution. Although I understand that some countries have many official languages I am not aware that any producers that would wish to encode more than one national language within the same ENC.

I'll try and make a test dataset as I think that would be useful to support these discussions.

[alvarosanuy]

@alvarosanuy sent a MSTeams meeting invite to all PsWG members by email on 20230224 to facilitate the discussion on this topic.

[MikusRL]

On your 2. I'm not so sure, as I understand if the use of national language in ECDIS is primarily where vessels are engaged on voyages within one countries waters rather than vessels trading internationally where the default of English would generally be used. Maybe we need more user engagement on this before we define such a solution. Although I understand that some countries have many official languages I am not aware that any producers that would wish to encode more than one national language within the same ENC.

Examples from experience be Eng - Danish - Grenlandic; Eng - Danish -Faroese. Then I am pretty sure that once more HOs learn about the possibilities of new S-101 naming options, more would be happy to use the opportunity, especially those whose first language in the country is not English. If they have second official language - that means three for ECDIS already. And even if ECDIS can be set to a national language as a default, I think there should be a further choice for the mariner - which national language. Going further, I think that in ECDIS should be a possibility to set a list of priority languages. That way could be solved the issue - if not coded, then which is next language to be displayed (when set to True) - eng or another national language, etc.

This might give an insight of potential usecases for two or more non English national languages - https://en.wikipedia.org/wiki/List_of_autonomous_areas_by_country#:~:text=An%20autonomous%20area%20is%20defined,autonomous%20areas%20are%20often%20federacies.

[DavidGrant-NIWC]

Issue 1

There is no default value defined in the DCEG for displayName.

• Encoders may make conflicting assumptions.
• The portrayal rules currently default displayName to true.

Issue 2

The modelling conflicts with the requirement that only a single instance can have displayName set to true. In the following example, when spa is selected nothing will be displayed because displayName is false for both matching entries. There is no way to figure out which spa entry matches the eng entry where displayName is true.

Example

featureName instance	name	language	displayName
1	label	eng	true
2	other info	eng	false
3	etiqueta	spa	false
4	otra información	spa	false

I recommend updating the model:

featureName       0:∞
    displayName   0:1
    text          1:∞
        name      1:1
        language  0:1

Updated example

featureName instance	displayName	text instance	name	language
1	null or true
1	label	eng
2	etiqueta	spa
2	false
1	other info	eng
2	otra información	spa

Implementation Notes

The portrayal should prioritize each instance of featureName according to the following table. For a given feature, if the highest priority is greater than zero a TextInstruction with the value of name is added to the features portrayal output.

priority	displayName	language
0	false	not evaluated
1	null or true	not present
2	null or true	eng
3	null or true	matches value of National language context parameter

[MikusRL]

3 null or true matches value of National language context parameter

Can the entry in priority 3 be updated to National language (first choice) context parameter, and then subsequentially there would be a possibility to prioritize further in the same way all encoded national languages (next choice), and this choice should be asked from the mariner as an input. If no input from the mariner ECDIS prioritizes and creates this list as it finds additional languages in the data as being used (rendered). This list then starting from priority 2 could be then changed and saved in the ECDIS user profile for each user. There would be always a possibility to reset back to the default priority ECDIS list up to and including priority 2.

@DavidGrant-NIWC , For me for the clarification - isn't displayName a Boolean attribute, so whenever there is an entry of a name it is added by default, and is either True or False. There is no null value possibility, isn't it? The only question is should it be by default True or False. The 7th Dec. DCEG version I got 2.4.5 says that "... If not populated the default rules provided in the portrayal catalogue will be used.". I think the "...if not populated..." is misleading, as it is populated by default with one of the two values always, correct? And by default I get the feeling is that default should be True, as in most cases when the choice is made to compile in the ENC the feature and it's name is, because it is considered to be significant for the navigational use. And as boolean it should be then as multiplicity 1,1 for each feature name entry.

[MikusRL]

In addition what I wrote above would need to be considered of course, that the production software should help and by default any additional entry in the same language should set displayName to False to help the production. And if eng name is set to False, then all the other language entries other than eng or empty should be set or asked if compiler agree to set to False too, for consistency. And as @TomRichardson6 mentioned earlier, of course validation check in place to check this logical consistency.

[DavidGrant-NIWC]

3 null or true matches value of National language context parameter

Can the entry in priority 3 be updated to National language (first choice) context parameter, and then subsequentially there would be a possibility to prioritize further in the same way all encoded national languages (next choice), and this choice should be asked from the mariner as an input. If no input from the mariner ECDIS prioritizes and creates this list as it finds additional languages in the data as being used (rendered). This list then starting from priority 2 could be then changed and saved in the ECDIS user profile for each user. There would be always a possibility to reset back to the default priority ECDIS list up to and including priority 2.

We could add one or more additional context parameters to implement this (National Language 2, etc.). I don't think the additional complexity is warranted though since I doubt there are many charts containing features described in more than two languages.

@DavidGrant-NIWC , For me for the clarification - isn't displayName a Boolean attribute, so whenever there is an entry of a name it is added by default, and is either True or False. There is no null value possibility, isn't it?

I wrote null (because that's what the Lua portrayal code has to check for) but I probably should have written unknown. Any attribute can have a value of unknown.

The only question is should it be by default True or False. The 7th Dec. DCEG version I got 2.4.5 says that "... If not populated the default rules provided in the portrayal catalogue will be used.". I think the "...if not populated..." is misleading, as it is populated by default with one of the two values always, correct?

see above.

And by default I get the feeling is that default should be True, as in most cases when the choice is made to compile in the ENC the feature and it's name is, because it is considered to be significant for the navigational use. And as boolean it should be then as multiplicity 1,1 for each feature name entry.

It is currently implemented in the portrayal with a default value of true. I guess encoders will learn the default value when they test the portrayal, so maybe it doesn't need to specify in the DCEG.

[alvarosanuy]

Summary of dedicated meeting held on 2/3/2023

• The use of the attribute language as a way to drive ECDIS display based on the use of the context parameter 'national language' needs further discussions at the S100 WG Level. Decisions made at that level should clarify the selector required to drive ECDIS GUI language and also the intention around using the attribute language and the context parameter 'national language' to drive (or not) the display of all instances of the attributes featureName and Information in ECDIS. Also would the language selection made by the mariner for the ECDIS GUI also apply to the data encoding (based on language) or would that be 2 independent selectors? Direction for implementation of the use of language at all levels (data display and ECDIS GUI) must be included in all relevant S100 instruments (e.g. S100 Part 18 and S-98 Annex C).
• Until further direction is developed at the S100 level, it was decided not to change the existing modelling for featureName but update encoding guidance in DCEG to restrict the use of displayName=True to one featureName instance only. To be implemented in DCEG 1.2.0 (@JeffWootton). @TomRichardson6 - Develop new Validation check (Error) to enforce implementation.
• Portrayal logic for PC 1.1.0 would be to select and display the 'first instance' of fetaureName with name populated with a value <> Unknown and displayName=True/Unknown (@DavidGrant-NIWC Please confirm this is possible). Note that the attribute language' won't be used to affect portrayal. At this point in time, it would only be discoverable using Pick report (depending on decisions made by S100WG, and if not to be used to drive portrayal, then this attribute could be removed from modelling ...).

In regards to the original intent of this Github issue (display parameters for 'new text') the decisions are:

1. For PC 1.1.0 ensure all S-101 features that have an S-57 corresponding object with text instructions linked to OBJNAM/NOBJNM in S-52 LUT have a text instruction in the corresponding S-101 Rule (identical text instruction).

2. Update portrayal rules above so name displays when populated with a value <> Unknown and displayName=True/Unknown (as per last bullet in the previous section). The idea is that the 'first' instance of this type will be displayed. Any other instance has to be ignored. Once DCEG 1.2.0 is published and Validation checks introduced, it shouldn't be possible to publish ENCs having features with more than one featureName instance having displayName=True.

3. Finalise the list of all other S-101 features that have fetaureName as a valid attribute and, as a minimum, allocate the agreed 'generic' text instruction [S-52 TX/TE instructions: TX(OBJNAM,1,2,2,'15110',0,1,CHBLK,26)] so they display when name populated with a value <> Unknown and displayName=True/Unknown. If more appropriate text instructions are identified during the compilation and review of this feature list, variations to the 'generic' text instruction should be proposed within this issue for PsWG review and endorsement.

4. Leave this issue open until # 1 above is completed (NIWC to confirm); then update this issue's label to 'PC 1.2.0 or later' and focus on resolving decision # 2.

[DavidGrant-NIWC]

For PC 1.1.0 ensure all S-101 features that have an S-57 corresponding object with text instructions linked to OBJNAM/NOBJNM in S-52 LUT have a text instruction in the corresponding S-101 Rule (identical text instruction).

Since most S-101 PC rules were generated from the S-52 LUT this should already be complete. What remains for this work item is:

• Correctly handle cases where displayName = false.
  • Currently I believe the portrayal will output a TextInstruction with no text (I don't believe this is allowed).
  • There is a lack of supporting test data.
• Correctly prioritize when there is more than a single featureName with displayName=true.
  • No test data.
  • Although it is proposed to only allow a single entry with displayName=true, that would preclude use of languages other than English.
• Correctly handle featureName.language / contextParameters.NationalLanguage.
  • No test data.
  • How to figure out which featureName to display?
• The previous two concerns (national language and multiple displayName entries) are related.
  • See Issue 2 in my previous comments: https://github.com/S-101-Portrayal-subWG/Working-Documents/issues/104#issuecomment-1444740432

[alvarosanuy]

Correctly handle cases where displayName = false.

• Currently I believe the portrayal will output a TextInstruction with no text (I don't believe this is allowed). - Needs to be fixed in PC 1.1.0 No textInstruction is needed if displayName=False
• There is a lack of supporting test data. - Test data won't be available before the end of March (feedback from @TomRichardson6. Testing will have to occur after PC 1.1.0 'release').

Correctly prioritize when there is more than a single featureName with displayName=true.

• No test data. - See my comment above
• Although it is proposed to only allow a single entry with displayName=true, that would preclude use of languages other than English. - The practical use of 'language' in data encoding and ECDIS interface is still unclear for Jeff W. and all others that attended the last focused meeting. The recommendation is to escalate to S100WG (refer to my post meeting notes). At this point in time (for PC 1.1.0) the attribute language has to be ignored (not used) by the portrayal rules.

Correctly handle featureName.language / contextParameters.NationalLanguage.

• No test data. - See my comment above
• How to figure out which featureName to display? - See my comment above

The previous two concerns (national language and multiple displayName entries) are related.

• See Issue 2 in my previous comments: Display parameters for 'New Text' #104 (comment) - I liked the proposal but people (particularly Jeff) is still not sure that the attribute language was introduced to drive display in ECDIS. He feels (and we all agreed), more discussion is required at the S100WG level and detailed performance instructions documented in the relevant instruments. Note that the use of language is bigger than featureName and also impacts the feature Information (S-57 ; TXTDSC, NTXTDS, INFORM and NNINFOM).

I have updated the label of this issue to 'PC 1.2.0 or later' but I note that @DavidGrant-NIWC first comment needs to be resolved in PC 1.10.

[DavidGrant-NIWC]

He feels (and we all agreed), more discussion is required at the S100WG level and detailed performance instructions documented in the relevant instruments. Note that the use of language is bigger than featureName and also impacts the feature Information (S-57 ; TXTDSC, NTXTDS, INFORM and NNINFOM).

This is an S-101 issue, not an S-100 issue. I believe the root issue with national language text in S-101 is that for some reason the S-57 model was changed for S-101.

S-57

In S-57 my understanding is that the (optional) National language independent mariner selector is used to toggle between OBJNAM and NOBJNM (text group 31), Specific implementation details are left up to each OEM. While a given chart could theoretically have text in more than two languages, a given feature can only have English and at most one national language equivalent. National language also must be enabled to show NTXTDS information in the pick report (implementation details are again left up to the OEM).

S-64

S-101

My understanding is that S-101 data should be encoded as follows to model the indicated purpose (edit Mar 3 to add OBJNAM/NOBJNM):	Purpose	S-57	S-101
English object/feature name	OBJNAM	featureName.name and featureName.language=(unknown or eng)
National language object name	NOBJNM	featureName.name and featureName.language is not (unknown or eng)
English text	INFORM	information.text and information.language=(unknown or eng)
National language text	NINFOM	information.text and information.language is not (unknown or eng)
English text in support file	TXTDSC	information.fileReference and information.language=(unknown or eng)
National language text in support file	NTXTDS	information.fileReference and information.language=(unknown or eng) [this should probably be better described in the DCEG...]
Picture in support file	PICREP	pictorialRepresentation

The issue is that S-101 allows features to encode an unlimited number of national language strings (note the multiplicity on the information binding):

It also allows multiple national language strings by supporting multiple methods of adding information to a feature:

• via attribute binding to complex attribute information
• via information association AdditionalInformation

For example, Berth provides an information attribute and permits AdditionalInformation (ContactDetails, NauticalInformation, NonStandardWorkingDay, ServiceHours)

I understood this support for multiple different national language representations of a single English string to be intentional, but maybe it wasn't. If the model was changed to match S-52/S-57 (a single English text string is only allowed to have one national language equivalent) then we could change the National language context parameter from a string (eng) to a boolean and make things easier on ourselves and the mariner.

If this change were to be made, the mariner wouldn't have to know to type spa to see the national language text; they would just enable the National language boolean selector. This would match the S-52 functionality as tested in the S-64 test above.

If desired, I could open an issue in S-101 Documentation and FC SWG to discuss this further.

[alvarosanuy]

If desired, I could open an issue in S-101 Documentation and FC SWG to discuss this further.

Yes, please do it. Thanks.

Agree that somebody needs to clarify why the S-57 modelling was changed. I agree that in some instances 2 options may not be enough (OBJNAM & NOBJNM // INFORM & NINFOM, etc) and we need to allow for more than 2 featureName instances (use cases put forward seem to indicate 3 options would be the maximum). Also agree that producers need to be able to select which featureName instance they want to display. I believe that not more than one should be allowed at the same time. Language should be discontinued as an attribute. If a valid use case is presented and justifies retaining this attribute, I think it should only be discoverable via pick report. Maybe the context parameter 'national language' should be renamed to 'alternative names' to move away from language (many aboriginal languages are not listed in the ISO list). IF we want to replicate the use of NOBJNM, etc in S-101 then a Boolean sub attribute for featureName (e.g alternativeName) could help but again, only one featureName can have this sub attribute encoded as TRUE. It will display only when displayName-Unknown/True and the 'context parameter' is activated in ECDIS.

Maybe we are overcomplicating thing and we just need featureName with multiplicity (0,1) and alternativeFeatureName with multiplicity (0,2) ........ Same sub attributes than featureName currently has.

[TomRichardson6]

I believe the modelling was changed to be more flexible to allow both the full and shortened names to be used to improve the display for users and to allow the language to be specifically identified. I don't think that the change fully considered the impact on the optional S-52 selector. The discussion may have predated the significant changes post Preslib 3.4 which made these selectors more explicit.

As this change is for 1.1.0 I think remodeling and discussions around display of text present on information types are out of scope and new items should be raised in the DCEG sub group. We should seek to resolve the way ahead at the PT10 meeting. As the parameter is optional in S-52 one option would be to omit this in the 1.1.0 PC and simply display feature name based on displayname only and ignore language. We can capture this as a limitation in the release notes.

@alvarosanuy the criteria for the language codes can be found here for reference. New languages may need to be proposed. https://www.loc.gov/standards/iso639-2/criteria2.html

[mikan66]

Are we deferring this one to 1.2.0, [PC #144]? Furthermore, it appears there are several similarly related open PC issues related to the theme of "text", [PC #61, #174, #175].

[alvarosanuy]

Are we deferring this one to 1.2.0, [PC #144]? Furthermore, it appears there are several similarly related open PC issues related to the theme of "text", [PC #61, #174, #175].

For PC 1.1.0

1. Ensure all S-101 features that have an S-57 corresponding object with text instructions linked to OBJNAM/NOBJNM in S-52 LUT have a text instruction in the corresponding S-101 Rule (identical text instruction).

2. Update portrayal rules above so name displays when populated with a value <> Unknown and displayName=True/Unknown (as per last bullet in the previous section). The idea is that the 'first' instance of this type will be displayed. Any other instance has to be ignored. Once DCEG 1.2.0 is published and Validation checks introduced, it shouldn't be possible to publish ENCs having features with more than one featureName instance having displayName=True.

For PC 1.2.0:

3. Finalise the list of all other S-101 features that have fetaureName as a valid attribute and, as a minimum, allocate the agreed 'generic' text instruction [S-52 TX/TE instructions: TX(OBJNAM,1,2,2,'15110',0,1,CHBLK,26)] so they display when name populated with a value <> Unknown and displayName=True/Unknown. If more appropriate text instructions are identified during the compilation and review of this feature list, variations to the 'generic' text instruction should be proposed within this issue for PsWG review and endorsement.

4. @DavidGrant-NIWC - Create new DCEG Github issue to centralise the discussions around the expected use of language in a number of features and the interaction/relationship with ECDIS selector 'National language'.

@mikan66 & @DavidGrant-NIWC - Please confirm # 1 and 2 above will be addressed in PC 1.1.0

@DavidGrant-NIWC - Please confirm a new issue has been created in the DCEGsWG (as per # 4 above). Do we need to create a 'corresponding' PsWG issue as well or should we let the conversation happen at the DCEGsWG first and then react accordingly?

Once # 1, 2 and 4 are 'closed' the goal of this issue (104) will be resolving #3.

[DavidGrant-NIWC]

@mikan66 & @DavidGrant-NIWC - Please confirm # 1 and 2 above will be addressed in PC 1.1.0

• [x] Ensure all S-101 features that have an S-57 corresponding object with text instructions linked to OBJNAM/NOBJNM in S-52 LUT have a text instruction in the corresponding S-101 Rule (identical text instruction).
• [x] Update portrayal rules above so name displays when populated with a value <> Unknown and displayName=True/Unknown (as per last bullet in the previous section).
• Note: Since this change precludes national language support, we have removed the national language context parameter from the 1.1.0 PC.

@DavidGrant-NIWC - Please confirm a new issue has been created in the DCEGsWG (as per # 4 above).

• [x] https://github.com/iho-ohi/S-101-Documentation-and-FC/issues/60

Do we need to create a 'corresponding' PsWG issue as well or should we let the conversation happen at the DCEGsWG first and then react accordingly?

• [x] This issue (#104) is the corresponding issue.

Once # 1, 2 and 4 are 'closed' the goal of this issue (104) will be resolving https://github.com/S-101-Portrayal-subWG/Working-Documents/issues/3.

Recommend either or both:

• open a new issue to implement item 3.
• open a new issue to resolve the issues with language independent text.

If you open two new issues you could close this issue.

[alvarosanuy]

• open a new issue to implement item 3.

This issue (#104) is about Display parameters for New Text (not previously exposed in S-52). There's a lot of comments that are relevant (particularly at the beginning before it derailed to the use of language). I recommend we continue using this issue for its original intended purpose.

• open a new issue to resolve the issues with language independent text

This was my question in my previous comment. Should we open a new PsWG issue now or, better let the conversation develop in the DCEG issue (#60) first? Portrayal actions would be a reaction to the decisions at the DCEGsWG level. I recommend not opening a 'language independent text' PsWG issue at this point in time.

[DavidGrant-NIWC]

Makes sense. Just note that this issue (New Text) can't be fully implemented until the DCEG issue is addressed.

[alvarosanuy]

Decisions made at Portrayal subWG meeting on 11/5/23

• [ ] NIWC to Finalise the list of all other S-101 features that have fetaureName as a valid attribute and, as a minimum, allocate the agreed 'generic' text instruction [S-52 TX/TE instructions: TX(OBJNAM,1,2,2,'15110',0,1,CHBLK,26)] so they display when name populated with a value <> Unknown and displayName=True/Unknown. If more appropriate text instructions are identified during the compilation and review of this feature list, variations to the 'generic' text instruction should be proposed within this issue for PsWG review and endorsement.

• Target is PC 1.2.0

[alvarosanuy]

Decisions made at Portrayal subWG meeting on 17/10/23

• [ ] NIWC to update the PC so all features containing the complex attribute featureName (and not currently including text instructions - usually those not containing mappings for OBJNAM/NOJNM in S-52) have the sub attribute name depicted using [S-52 TX/TE instructions: TX(OBJNAM,1,2,2,'15110',0,1,CHBLK,26)] when name is populated with a value <> Unknown and displayName=True/Unknown.
• [ ] Alvaro to create and upload to this issue a relevant S-101 Test Dataset.

[MatthewCraggs]

101AU00GITHUB104 (2).zip

Please find attached a test dataset to assist with development of Display parameters for 'New Text'

[mikan66]

@MatthewCraggs, can we get new data to support FC 1.2.0? There are modelling changes related to featureName with the introduction of attribute nameUsage

[MatthewCraggs]

@mikan66, Happy to supply as many datasets as is required. However Caris does not currently support FC1.2.0. When this changes I will be more than happy to supply as many datasets as required!

[kusala9]

hi @mikan66 , you can try the attached. This is v1.2.0 with a couple of test cases.

• single name, nameUsage=1
• single name, nameUsage=3 (pick report only)
• two names, two languages, one default (nameUsage=1), one alternate (nameUsage=2).

If this helps I can add to the cell. It's a test cell we did, working with the new FC. I think there's obviously a few more to add (and I've raised an issue in S-164 to list and add to the relevant tests).

101AA000DS032.zip

[DavidGrant-NIWC]

• [x] NIWC to Finalise the list of all other S-101 features that have fetaureName as a valid attribute and, as a minimum, allocate the agreed 'generic' text instruction [S-52 TX/TE instructions: TX(OBJNAM,1,2,2,'15110',0,1,CHBLK,26)] so they display when name populated with a value <> Unknown and displayName=True/Unknown. If more appropriate text instructions are identified during the compilation and review of this feature list, variations to the 'generic' text instruction should be proposed within this issue for PsWG review and endorsement.

Implemented as PC 334 (with a couple of minor modifications):

• Used text group 21 - Name or number rather than 26 - Geographic names. Not all of these labels are geographic names. We might want to consider adding a new text group to toggle the visiblity of these newly added labels.
• Used Vertical alignment of Top rather than Center. When the label is placed below the symbol, using Top adds some additional space.

The labels shown below are all newly added via featureName with nameUsage=1. Existing labels corresponding to S-52 TX/TE instructions are unmodified. There is the potential for labels associated with a given feature to obscure one another. We could attempt to do some automated de-cluttering, but we currently don't have sufficient test data and it may not turn out to be a big issue.

[alvarosanuy]

@DavidGrant-NIWC - It looks good to me. Happy to split Text groups as proposed and I'm supportive of using the new group to toggle visibility on/off (need to go in S-98 ?). Having said this, I would like to propose a different name for the new group # 21. Maybe 'Auxiliary names' is more appropriate and encompassing (?).

• Used text group 21 - Name or number rather than 26 - Geographic names. Not all of these labels are geographic names. We might want to consider adding a new text group to toggle the visibility of these newly added labels.

[DavidGrant-NIWC]

If we want a new VG then it should be 22, 32-49, or 80-99. Need to also decide on a VGL (see below). If a new VG is added than S-98 and the registry should be updated.

Here are the currently assigned S-52 text groups (note that 21 and 26 are pre-existing):

And the corresponding viewing group layers:

[alvarosanuy]

I would use VG 32 as 'Auxiliary names' and keep it in VGL 2.3 'All other', as is. VG 32 would cover features not previously listed that have name encoded and nameUsage = 1 or 2.

I haven't fully read the DCEG but I imagine that only one name can be displayed at any given time ..... If more than one instance of featureName, with the same language, are encoded, only one of those instances can have nameUsage=1 and only one nameUsage=2. The rest will have to be encoded as usageName=3 (the display of nameUsage 1 or 2 would depend on the language selected by the user in ECDIS). We shouldn't try to accommodate the simultaneous display of 2 or more pieces of text (name) in ECDIS, at the same time.

Having multiple instances of featureName, each of them linked to a unique language, shouldn't be a problem as name would display based on the language selected by the user in ECDIS.

[DavidGrant-NIWC]

See https://github.com/iho-ohi/S-101_Portrayal-Catalogue/issues/336

Will need to update the registry, but maybe wait until implemented.

Agree that only one name can be displayed at a time for a given feature. Note that features can be co-located though, particularly StructureEquipment relationships, and this could give the appearance of multiple names. The producer can move the labels though via TextPlacement.

[DavidGrant-NIWC]

Here's some examples of clutter added by this capability: Excerpt 1: Excerpt 2:

This is caused by naming the channels. The DredgedArea rule which was copied from S-52 doesn't show OBJNAM/featureName, so the default placement is used. This makes it harder to read the channel depth. Granted, the text viewing group (or more likely, the Other Text VGL) can be turned off to clean up the display:

In cases like this we may want to update the corresponding rule to specify a better placement (offset and alignment) for the feature name. If so, recommend opening up issues on a case-by-case basis.

[alvarosanuy]

In cases like this we may want to update the corresponding rule to specify a better placement (offset and alignment) for the feature name. If so, recommend opening up issues on a case-by-case basis.

Agree

I'll wait until you complete issue https://github.com/iho-ohi/S-101_Portrayal-Catalogue/issues/336 to close this one.

[DavidGrant-NIWC]

Implemented, and issue opened in S-98: https://github.com/iho-ohi/98-interoperability/issues/40

The new viewing group needs to be registered.

[alvarosanuy]

The new viewing group needs to be registered.

Proposal submitted on 21/2/24