Optimization of vendor-specific rendering of a symbol on a line

[stephanr]

In the process of rewriting the pr #1204, where originally additional rendering code was added, I am now in the process to extend the current implementation of <PositionPercentage> to include anchor-point, displacement, perpendicular-offset and better control over fill, stroke and rotation.

The current Implementation of deegree for the stroke renderer [1] uses a currently undocumented vendor-specific configuration element <PositionPercentage> [2] to configure a position where a single, non-repeated symbol has to be rendered on a line.
This feature is currently undocumented [3] and also lacks handling of anchor-point and displacement and also has no way of to rotate a symbol facing to top of the rendered image.

The Current-Implementation [1] sets the color or image paint for the stroking and then implements rendering of SVG's and marks different.

• Strokes form SVG's
  • No perpendicular offset, displacement relative to the SVG
  • Anchor-point is 0.5/0.5
  • Closed Elements are filled with the associated stroke color or graphic-fill
  • Lines are not rendered at all
  • Rotation is relative to current line segment
• Strokes from Mark
  • Can have a perpendicular offset
  • No displacement relative to the Mark
  • Anchor-point is 0.5/0.5
  • Are filled according to Mark/Fill (contains default value), not un-setable
  • Are stroked according to Mark/Stroke (with default value), not un-setable
  • Rotation is relative to current line segment

While working on extending the current behavior, the following Questions raised:

• Should the configuration of PositionPercentage be kept as it is (keep the xml-schema extension) C or be changed to E where no schema-changes is required (the values of the name attribute of CssParameter or SvgParameter is not checked strongly) ?
• How should the setting to not align a symbol to the line before applying the rotation be configured D (name to be defined) or F ?
• What is the best way to disable the filling of the mark, proposal to not render when A is configured ?
• What is the best way to disable the stroking of the mark, proposal to not render when B is configured ?
• If E is implemented should, the parser for C should be keept and log a warning ?

XML config as reference:

<LineSymbolizer>
	<Stroke>
		<GraphicStroke>
			<Graphic>
				<Mark>
					<WellKnownName>triangle</WellKnownName>
					<Fill>
						<SvgParameter name="fill-opacity">0</SvgParameter><!-- A -->
					</Fill>
					<Stroke>
						<SvgParameter name="stroke-opacity">0</SvgParameter><!-- B -->
					</Stroke>
				</Mark>
				<Size>20</Size>
				<Rotation>-45</Rotation>
			</Graphic>
			<PositionPercentage>99.9</PositionPercentage><!-- C -->
			<RotationFacingUp/><!-- D -->
		</GraphicStroke>
		<SvgParameter name="stroke">#FFD300</SvgParameter>
		<SvgParameter name="stroke-graphic-position-percentage">99.9</SvgParameter><!-- E -->
		<SvgParameter name="stroke-graphic-rotation">0</SvgParameter><!-- F -->
	</Stroke>
	<PerpendicularOffset>20</PerpendicularOffset>
</LineSymbolizer>

[1] https://github.com/deegree/deegree3/blob/main/deegree-core/deegree-core-rendering-2d/src/main/java/org/deegree/rendering/r2d/Java2DStrokeRenderer.java#L93-L150
[2] https://github.com/deegree/deegree3/blob/main/deegree-core/deegree-core-style/src/main/java/org/deegree/style/se/parser/StrokeSymbologyParser.java#L258-L265
[3] https://download.deegree.org/documentation/3.4.32/html/

[stephanr]

The TMC discussed this topic in the TMC meeting on 03.11.2022 and came to the following conclusions.

• It will be appreciated to document this feature.
• That "A" and "B" could be a suitable way to disable filling or stroking in this situation
  • This may also be seen as an optimization function, i.e. instead of drawing a transparent line, there would be no drawing.
• When deviating from the official specification, it should be clear that these options are "deegree" specific. If these can be made without schema adjustments this would be a welcome side effect.

[stephanr]

The current planning is to aim for a configuration as follows.

<LineSymbolizer>
	<Stroke>
		<GraphicStroke>
			<Graphic>
				<Mark>
					<WellKnownName>triangle</WellKnownName>
					<Fill>
						<SvgParameter name="fill-opacity">0</SvgParameter>
					</Fill>
					<Stroke>
						<SvgParameter name="stroke-opacity">0</SvgParameter>
					</Stroke>
				</Mark>
				<Size>20</Size>
				<Rotation>-45</Rotation>
			</Graphic>
		</GraphicStroke>
		<SvgParameter name="stroke">#FFD300</SvgParameter>
		<SvgParameter name="deegree-graphicstroke-position-percentage">99.9</SvgParameter>
		<SvgParameter name="deegree-graphicstroke-rotation">0</SvgParameter>
	</Stroke>
	<PerpendicularOffset>20</PerpendicularOffset>
</LineSymbolizer>

And if the old <PositionPercentage>99.9</PositionPercentage> is used, this will still be accepted, but a warning message will be generated.

[copierrj]

Small remark: css browser prefixes are formatted like -vendor- (with an additional dash in front). Something to consider here?

[stephanr]

Small remark: css browser prefixes are formatted like -vendor- (with an additional dash in front). Something to consider here?

After further research I came across the page of Mozilla MDN Web Docs Glossary: Vendor Prefix which describes the semantics also for properties and methods.

After reading this I would say that with a prefix of deegree- we have transferred this semantics relatively well to the syntax of SLD/SE where words are not separated through Camel Case but rather by a dash.