Automatic Text alignment when using TextPlacement

[TDYCARHugh]

There have been informal discussions about this in the past. It needs to be considered, quickly if we wish to propose including something into S-100 5.2. It cannot wait for the next Test Strategy meeting. It might actually be too late to add some new values and behaviour as 5.2 as it would clearly be an extension and not just a clarification.

@HolgerBothien @David

We are looking for ideas for a solution to this.

In any case the need is to be able to keep text drawing upright (screen up) whether using a North Up display or course up display.

As discussed in recent S-101 meetings it is possible to implement a solution using portrayal rules when the display is North up. To do this the portrayal logic decides which Text alignments to assign at different bearings. The logic is as follows:

Auto Placement of Text at the end of a Ray. Using the direction of the Ray to ‘push’ the text away. Meaning the ray points to the closest side/corner of the text which is display screen up from that location. Auto horizontal alignment of text on end of ray Default alignment = ‘Start’ When bearing > 355 or bearing < 5 or (bearing >175 and bearing < 185) alignment = ‘Center’ When bearing >= 185 and bearing <= 355 alignment = ‘End’

Auto vertical alignment of text on end of Ray Default = Vertical alignment = ‘Bottom’ When bearing >= 95 and bearing <=265 vertical alignment = ‘Top’ When bearing >=85 and bearing <=95 vertical alignment = ‘Center’ When bearing > 265 and bearing < 275 vertical alignment = ‘Center’

I created a portrayal that draws the Augmented Ray in Red (as well as the text) in order to visualize what is happening. The offset distance defined in the TextPlacement is 5mm

Bearing of 40

Bearing of 0

Bearing of 90

Bearing of 70

Bearing of 135

Bearing of 180

Bearing of 230

Bearing of 270

Bearing 330

What we want is to have this same sort of display when the screen is North up or course up. To have the ECDIS automatically calculate the text alignment based on the text being displayed on an AugmentedRay and using the bearing of the Ray in addition to the screen rotation to determine which alignment to set.

The question is how do we accomplish this. One proposal is to add a new value called 'Auto' to both HorizontalAlignment and VerticalAlignment of PointText. When set to Auto the bearing from the parent feature location to the Text location is used to set the alignment using logic as defined above.

Any other proposals are welcome.

[HolgerBothien]

I think that is a valid proposal. One thing I don't understand is: where comes the bearing from. Is it a kind of cartographic attribute at the feature? If yes, then there should be no 'auto' value because the existence of that attribute should trigger the way the text is placed. Off course the standard needs to be amended to describe it.

[HolgerBothien]

One more thing, in the example the ray start from the centre of the symbol where I believe is the position f the feature. What is if this position is on the bottom of the symbol (as the paper chart like buoys). Then the length of the ray needs to be not longer constant but depending of the bearing. Are mathematical expression a solution or an ellipse that defines the end of the ray?

[HolgerBothien]

I have thought a little bit on text along lines. Here I would prefer just some generic rules as:

• text should not be upside down
• text should be above the line

This rules should be the base of an implementation and followed whenever possible. And they should apply to the rotated chart if not north up.

I have prepared three SVG files that show:

1. text along straight lines - north up
2. The same for - south west up
3. text along non-straight lines.

[TDYCARHugh]

Yes, Holger, your Text on lines looks good. Text should be as readable as possible.

The case I was looking at was with TextPlacement feature which holds the bearing and offset and is associated to the real world feature. In the case of TextPlacement an AugmentedRay is used to place the text at the end of the Ray. The Ray runs from the position of the real world feature and goes out at a bearing (0 = North). In my images the red line is the Augmented Ray with a simple red linestyle. Since the portrayal does not know if the map is rotated some sort of auto calculation within the drawing engine is needed in order to adjust the text horizontal and vertical alignment accordingly. So the Ray bearing needs to be combined with the screen rotation to get the net bearing from the feature location to the text location. That bearing would be used to decide on the text alignment to keep the text away from the feature.

[DavidGrant-NIWC]

• Part 9 needs a clarification wrt drawing text at a point along a line.

  • An AugmentedRay generates a linear geometry:

  • Text at a point along a linear geometry is supposedly always oriented according to the LocalCRS:

  • Confusingly (with respect to linear geometry), the TextPoint instruction specifies a rotation angle relative to the portrayal CRS. It's easy to look at this in isolation and assume that text drawn relative to a point on a linear geometry is oriented according to the portrayal CRS.

  • To resolve this issue, recommend that TextPoint is updated to allow specifying the rotationCRS. By default, text would always be oriented so that it's drawn upright (even for linear geometries). If the PC developer wishes, they can specify LocalCRS or any other CRS they desire to use:

Name	Description	Mult	Type
TextPoint	A graphic element for depicting text relative to a point	-	-
offset	...	0..1	...
rotationCRS	Specifies the CRS used to orient the text. Default = PortrayalCRS	0..1	CRSType
rotation	Specifies the rotation angle relative to rotationCRS. Default = 0	1	double
linePlacement	...	0..1	...
areaPlacement	...	0..1	...

• Along with the previous change, recommend that 9-11.1.11 Text Instruction is updated to read: [...] The first is to draw text at a position on the referenced curve relative to the local CRS at that position. [...]

Lua portrayal already supports the capability to specify the rotation CRS for a TextInstruction via Rotation:

AugmentedRay:GeographicCRS,45,PortrayalCRS,10
LinePlacement:Relative,1
Rotation:LocalCRS,45
TextInstruction:My Text

[DavidGrant-NIWC]

I like Hugh's proposal to add auto alignment modes to VerticalAlignment and HorizontalAlignment.

I'm not sure about Holger's suggestions because they could restrict the ability to draw text along curvilinear geometries.

[HolgerBothien]

The rules should not be 'set in stone' - rather follow the rule whenever possible. You can see in my examples some characters up side down. All rules for text placements should be recommendations only.

[DavidGrant-NIWC]

I think the guidance is ok for straight lines, but trying to do something with arbitrary curves would involve analyzing the curve. Additionally, although the portrayal knows the direction of a line generated from an augmented ray, it doesn't know the direction in the general case, so it might be necessary to reverse the direction of the line/curve when drawing text. Doing this might change the appearance from that intended by the data producer.

For those reasons, I'd recommend restricting this guidance to text drawn on augmented rays, either using TextPoint (Hugh's pics) or TextLine (Holgers pics).

[TDYCARHugh]

We only got permission to add clarifying text to part 9 for S-100 5.2 The addition of a new auto placement or additional crs parameters will have to wait for Ed 6.

I have made the following change to the wording on how TextPoint and TextLine work on a curve.

I think we could also add clarification about TextLine and how the text should be readable at the reference point where the text is placed on the line. That would mean the display engine would need to calculate the bearing of the line at the reference point and if it would place the text upside down to reverse the direction to draw the text. If the text continues along the line and bends upside down then so be it. We could maybe describe that the offset could be used to place the text above or below the line by stating that the offset is defined for when the line is traversed left to right. A positive offset would be above the line and negative below. When the line is oriented in the opposite direction this will be reversed.

[TDYCARHugh]

We have a deadline of Nov 30 to provide a redline part 9 for S-100 5.2 with clarifying descriptions related to text placements. All I have so far is the snippet I posted in my previous comment.

Things like text alignment can work when designed for a North up display but we probably need some guidance for text on lines.

Perhaps we could give guidance on course up display by stating that the display engine could auto adjust the text placement/alignment when in course up mode in order to keep it readable.

[TDYCARHugh]

Part 9 Text portrayal Nov26.docx

Part 9 text portrayal section for review/discussion

[DavidGrant-NIWC]

Added some minor edits. Part 9 Text portrayal Nov28.docx

[alvarosanuy]

@TDYCARHugh - can you please confirm S100 related changes necessary for this proposal have been included in the S100 5.2.0 version currently out for S100WG approval (responses due by 19/1/2024)? Are all related changes to TextPlacement currently included in the latest S101 1.2.0 version or are you planning to submit a paper to S101PT12?

[TDYCARHugh]

The proposed wording/clarification to Text portrayal expectations was included in the 5.2 Part 9 Portrayal_5.2.0.20231212_Redline.doc section 9-11.1.11 Text Instruction

[alvarosanuy]

@DavidGrant-NIWC - Anything pending implementations in PC 1.2.0? or is this only about On-Shore ECDIS implementation?

If test data is required, can you please summarize the encoding is needed?

[DavidGrant-NIWC]

We've started looking at this and would like to get it in PC 1.2.0. We have some preliminary test data from JP but it's very simplistic; we've requested more complex data.

The main hold up has been that we haven't fully implemented featureName yet. Since this modifies how featureName works (see excerpt from DCEG below) we would like to get both working together. We don't have much data we can use for testing featureName either and the data we do have is very simple.

Ideally for testing we would have all the possibilities available, and the featureName's would contain multiple name values with different nameUsage values. TextPlacement modifies featureName (for a selection of features) TextPlacement modifies light description (for each light type) TextPlacement overrides featureName via text attribute TextPlacement with text where featureName is not populated

[DavidGrant-NIWC]

Mostly implemented, see https://github.com/iho-ohi/S-101_Portrayal-Catalogue/issues/3#issuecomment-1951568995

Still need to add support for rotation: https://github.com/iho-ohi/S-101_Portrayal-Catalogue/issues/303 and Gap analysis row C.

[kusala9]

We can do some more test data for this and also combine with featureName as well. I have a question - is the association TextPlacement->Feature or Feature->TextPlacement? I've seen both in the TdS's we ported to v1.2...

[DavidGrant-NIWC]

We can do some more test data for this and also combine with featureName as well. I have a question - is the association TextPlacement->Feature or Feature->TextPlacement? I've seen both in the TdS's we ported to v1.2...

TextPlacement must have an association to a single feature via TextAssociation A feature may have an association to a single (there is a DCEG issue on the multiplicity) TextPlacement via TextAssociation

[DavidGrant-NIWC]

PC 1.2 supports featureName.name and TextPlacement including the textRotation attribute.

Text alignment when TextPlacement is used

textOffsetDistance	textRotation	Horizontal alignment	Vertical alignment	Notes
0	true	Start (Left)	Center	Starting at TextPlacement, following along the geographic bearing
0	false or not present	Center	Center	Centered on TextPlacement, always upright
>0	true	Start (Left)	Center	Starting at the endpoint of the vector defined by textOffsetBearing and textOffsetDistance, following along the continuation of the vector
>0	false or not present	Center	Center	Centered on the endpoint of the vector defined by textOffsetBearing and textOffsetDistance, always upright

[alvarosanuy]

Decisions made at Portrayal subWG meeting on 09/04/24

Implemented in PC 1.2.3 - Close this Issue.

[alvarosanuy]

I'm reopening this issue as @TDYCARHugh and @KlasOstergren-SMA are of the opinion there are still some elements that need implementation.

Can @TDYCARHugh or @KlasOstergren-SMA expand on this please

[alvarosanuy]

Below is a copy of @TDYCARHugh email identifying the unresolved issue.

@DavidGrant-NIWC - Any comments from NIWC's side?

[DavidGrant-NIWC]

@DavidGrant-NIWC - Any comments from NIWC's side?

We agree with Hugh (and others) that automated alignment would be best, but the S-100 WG didn't approve the necessary changes. The PC is restricted to using the alignments currently available, and during our testing the alignments detailed in https://github.com/S-101-Portrayal-subWG/Working-Documents/issues/156#issuecomment-1955647135 appeared to give the most consistent results (not necessarily the best; all the options considered have pluses and minuses and are dependent on specifics of the encoding).

Guidance added to Part 9 of S-100 5.2 allows the OEM to "enhance" the portrayal of text by adjusting the placement, so I assume at least some OEM's will ignore the alignment output by the portrayal and do automated alignment based on the bearing.

Many of the points Hugh raises are dependent on how the producer chooses to place the geographic point associated with the TextPlacement feature; whether it is positioned on the associated feature or if it is placed at a specific location relative to the feature (the modeling supports both options, so the portrayal needs to support both).

I think this point is incorrect: "may as well just use x,y offset on the portrayal CRS"; using an offset on PortrayalCRS doesn't keep the text anchored at a specific geographic position.

My suggestion is to produce some (more) test data better reflecting intended usage and evaluate the results. Open a PSWG issue if the results are not satisfactory. It's easy enough to update the PC to support other alignments, but note that "auto" is not an option the PC can currently implement. If we want the 1.3 PC to use some other alignments, update the table above accordingly or suggest edits to the implementation.

[alvarosanuy]

@TDYCARHugh ; @KlasOstergren-SMA & @DavidGrant-NIWC - Not sure how to proceed with this one. I would like to close this issue and ask @TDYCARHugh /@KlasOstergren-SMA to open a new one requesting specific PC changes that are possible under S-100 5.2.0 or recommending updates to S-100 otherwise.

@TDYCARHugh & @KlasOstergren-SMA - Is this approach reasonable to you?

[mikan66]

@alvarosanuy, I believe there a related paper on this topic for PT13. We are waiting on the outcome on that then we can close this.

[alvarosanuy]

@mikan66 - Thanks, noted.

[DavidGrant-NIWC]

[alvarosanuy]

Input from PsWG meeting on 10/7/2024

Alignment of textPlacement based on textOffsetBearing values has been implemented.

• [x] @DavidGrant-NIWC to email @JeffWootton proposed amendments to DCEG guidance regarding:

• removal of restriction that only one of text or textType must be populated for each instance of TextPlacement. @KlasOstergren-SMA - This may need review of existing Validation Checks (no longer conditional mandatory ??).

• allow TextPlacement to apply to the name of a structure when the placement is associated to the equipment.

[alvarosanuy]

Portrayal has been implemented. A 'Documentation' GitHub issue may be required and should be linked to this Issue.