Extending SymCore for generic expressions and symbolizer properties

[jerstlouis]

Defining a conceptual model, logical model and encodings applicable for styling any type of data, including types of expressions for use within selectors and symbolizer parameter values, as well as generic symbolizer properties.

The conceptual aspects of these be could defined as part of the SymCore standard itself, but in separate conformance classes from the minimal Core, making expressions, selectors and symbolizers less abstract concepts (but remaining at both the conceptual level, and not tying the specification to any particular type of data).

Expressions extensions

Most of these have a direct mapping to CQL2 conformance classes, and CQL2 could be used in some of the encodings for defining selectors and parameter values expressions.

Extensions for basic expressions with support for:

• comparison operators (including case insensitive text comparisons)
• conditional operator (if-then-else)
• re-prioritizing expressions (e.g. parentheses)
• literals for text, integer, real numbers, boolean and null values
• an in operator and list of expressions

Support for referencing the following as part of an expression for a selector or parameter value:

• referencing a layer ID (which could be associated with e.g. a feature type, a coverage name or an OGC API collection id)
• referencing a layer data type (e.g. map, coverage or vector)
• referencing the visualization cartographic scale
• referencing a current visualization time and/or a temporal range
• referencing pre-defined variables which may be mapped to application logic

More advanced expressions with support for:

• arithmetic operators
• invoking functions
• basic and advanced spatial operators
• temporal operators
• advanced comparison operators

Symbolizer extensions

• opacity
• visibility
• visual priority (which may or may not correspond to the order of portrayal rules, e.g. in encodings with support for cascading where order has an overriding meaning)

[chris-little]

@jerstlouis How about adding to the symbolizer extensions persistence/duration? An example is the classic weather map symbol for a lightning strike - fades away after a few minutes as irrelevant. It is relevant for the first few minutes, as the next one could be nearby.

I suppose this is moving in the direction of dynamic or transient features.

[jerstlouis]

@chris-little I think related aspects are being discussed in #7. If a symbol fades away, it seems to imply that the visualization time is changing, and this may be covered by the visibility property combined with the temporal operators, together with the temporal domain of the coverage or vector feature (possibly indicated in a property in the case of the vector feature, or e.g. the new when attribute from Features & Geometry JSON). Plus blending effects by the renderer if smooth fading is desired.

[chris-little]

@jerstlouis So this highlights the need for some explicit examples, that sit outside the traditional comfort zone of paper maps. I usually think of a visibiility property to be yes/no or perhaps with some alpha blending

[jerstlouis]

@chris-little My own comfort zone is quite outside paper maps since we do mostly 3D visualization :)

Here is an explicit example of how this could be defined (this may be close to working in pratice in our implementation):

#lightning_strikes
{
   markers = [ Image { "lightning.png", tint = yellow } ];
   visibility = abs(viz.time - rec.time) < 5;
   opacity = (5 - abs(viz.time - rec.time)) / 5.0;
}