KlasOstergren-SMA
commented
1 week ago The first thing to remember is that the idea of TextPlacement is to allow the compiler to decide where a text should be placed. This means that the TextPlacement basically holds a position (by bearing and distance) and textType is used to declare what text it should be used for.
Some comments:
- What does the textType value 2 featureCharacteristic refers to? How do we map this feature dependent relationship in the PC? The attribute value definition in DCEG 27.180 (Remarks) is very loose.
textType value 2 (featureCharacteristics) is used for existing texts/labels describing the characteristics for the feature (e.g. communication channel, clearance etc.).
- Could textType be renamed textBlock and become a Complex attribute with 2 sub-attributes: textType and 'textLine' (RE) to drive the compilation of the block of text to be portrayed? textBlock mutiplicity could be larger than (0,2).
I would say no. As written above, the TextPlacement should hold the position for an existing text. If I understand the idea of a complex attribute correctly, all the text would have to be redundant for both the parent feature and for the TextPlacement feature. This would add an extra burden on the data producers and increase the risk of changing attributes for one feature but not for the other.
- Wouldn't be better to discontinue featureCharacteristic and instead grow the list of meaningful attributes we could use to build a text block (e.g shapeInformation; communicationChannel, etc)?
In my opinion, this would add extra complexity that is not needed. This was discussed at PT13 and it was concluded that a hole lot of extra values are not needed.
- How can the TextPlacement portrayal rule decide what name attribute value to use when TextPlacement is linked to 2 or more features all having featureName as a valid attribute (same applies to 2 collocated Lights if we were to use lightCharacteristic)?
Our (SE) proposal, which was accepted by PT13, is to use featureName from the feature to which the TextPlacement is associated to, if a featureName exists. If it does not exist, then the featureName from the parent feature is used. With this solution, the hierarchy is already defined.
Important Note: None of this is expected to be mapped during S-57 to S-101 conversion but would provide the building blocks for data producers to have more 'cartographic' control in regard to textual ENC content display in ECDIS and potentially assist them when looking at the automated creation of Paper Charts from ENC.
Agree. However, the issues discussed at PT13 need to be resolved for 2.0.0 to avoid a lot of extra work for those who choose to implement TextPlacement in edition 2.0.0 if this changes later.
DCEG and FC 1.4.0 have been updated to:
Fact: There's an expectation S-101 portrayal will combine attribute values from one or more associated features into one text block and hide the portrayal of the corresponding values from the 'source' features. The classic example would be collocated features such as Landmark (Lighthouse) and LightAllAround where we would like to see a unique text block that combines, aligns and presents the name of the Lighthouse on the first line of text and the light description on a second line.
Discussion points:
Important Note: None of this is expected to be mapped during S-57 to S-101 conversion but would provide the building blocks for data producers to have more 'cartographic' control in regard to textual ENC content display in ECDIS and potentially assist them when looking at the automated creation of Paper Charts from ENC.
Related Documentation GitHub issues (Pre 1.4.0 - for context only): https://github.com/iho-ohi/S-101-Documentation-and-FC/issues/128 https://github.com/iho-ohi/S-101-Documentation-and-FC/issues/129