Definition of Style in SymCore

[cportele]

The recently published SymCore standard has a Style definition that is narrower than the definition that we use in OGC API Styles.

SymCore defines "style" as (see section 4.3, bolding is mine)

a set of rules of symbolizing instructions to be applied by a rendering engine on a layer of geographic features (e.g., feature, coverage…​).

In OGC API Styles, we define "style" as

a sequence of rules of symbolizing instructions to be applied by a rendering engine on one or more features and/or coverages.

First of all, I think that "sequence" is correct (not "set", the order is in general relevant).

Second, and more importantly, SymCore restricts a style to a single data layer where layer is quite vaguely defined as

an abstraction of reality specified by a geographic data model (feature, coverage…​). A layer may be represented using a set of symbols (Style). A layer contributes to a single geographic subject and may be a theme.

However, the intent seems to be clear that this excludes the use of "style" like in a Mapbox Style which can reference multiple data layers and multiple data sources. For OGC API Styles the narrow definition of SymCore is - in my opinion - not an option.

However, it raises two questions:

• Since SymCore describes itself as a conceptual model for styles in OGC, is that narrow definition an issue for OGC API Styles? Interestingly, SymCore is not an OGC Abstract Specification as one would expect from a conceptual model, but SymCore is a Implementation Standard. I guess that implies that the definition only applies to the OGC Symbology standards and OGC API Styles can use a different definition/model.
• The vague definition of layer in SymCore leaves room for interpretation, but in the OGC API context I think a layer would in general match a Collection. This would then imply that a style with a SymCore-based encoding can only be associated with a single collection. That would limit the usability of SymCore quite a bit. You need multiple, separate styles for most maps. It is also worth to note that the SymCore model has no concept of aggregations of styles, so it is unlikely that SymCore encodings will support anything else but single layer documents.

cc @jerstlouis

[jerstlouis]

I agree that the definition of one style per layer as currently specified in SymCore is very rooted in SLD/SE, and is problematic as shown by the long discussion and confusion relating to opengeospatial/ogcapi-styles#5. I guess there are two levels of styles: the sequence of rules with associated symbolizers being specified for a particular FeatureType, and the overall style as specified in a full SLD/SE file defining a map, or style sheet as we called it in the Open Protrayal Framework (including OGC API - Styles and GeoPackage Portrayal extension) -- though that usually refers to a particular encoding. I will bring this up for discussion at the Members Meeting Styles & Symbology SWG sesssion.

A related consideration might be rendering a map while specifying different styles for different collections. (e.g. for a dataset map, having a styles= for a list of styles matching the collections= order). In this case, we are selecting individual styles for each collection/layer. Those styles could still be references to global style sheets though, which may be defining FeatureType styles for multiple collections. In summary, there should be flexibility in using the style term to refer to either a style for a specific FeatureType, or for multiple FeatureTypes.

On the "sequence" of rules, while I agree that the order is in general relevant, the meaning of that order might differ for different encodings. e.g. in CMSS the order allows partially overriding rules, while in other encodings it might reflect visual priority (rendering order). That distinction / flexibility might deserve more attention at the SymCore conceptual level. Technically a sequence is an ordered set, so the definition could be clarified but is not wrong :)

[cportele]

I will bring this up for discussion at the Members Meeting Styles & Symbology SWG session.

Thanks 👍

Regarding the sequence/set issue: Well, the order of the elements in a set is irrelevant. {1, 3} and {3, 1} are identical. The style encodings that I know include some kind of ordering information (that of course a rendering engine is free to change/ignore). If it would be a pure set, the rendering engine would have no guidance what rule to process when. And I don't think that a sequence is an ordered set, it is an ordered bag.

[jerstlouis]

And I don't think that a sequence is an ordered set, it is an ordered bag.

You are probably right, and sequence is probably the best term. A bag is also called a multiset.

Wikipedia says for sequence:

In mathematics, a sequence is an enumerated collection of objects in which repetitions are allowed and order matters. Like a set, it contains members (also called elements, or terms). The number of elements (possibly infinite) is called the length of the sequence. Unlike a set, the same elements can appear multiple times at different positions in a sequence, and unlike a set, the order does matter.

[ebocher]

Hey @cportele and @jerstlouis ,

Interesting issue. As authors of SymCore with my colleague @oertz we will try to answer you quickly. Thanks

[jerstlouis]

2021-06-16 Styles & Symbology SWG: We discussed that potentially the rule extension mechanism could be a way to support a single style defining symbology for multiple layers. We would need to review SymCore with Erwan and Olivier to clarify the intent in terms of a style being associated to a single or multiple layer, as well as the distinction between a presentation layer and a data layer (e.g. Coverage or FeatureType). Considerations should be made for 3D rendering as well, where data "layers" do not simply get rendered on top of each other.

[jeffharrison]

17 June 2021 SWG discussed this Issue. It should be transferred to the Styles & Symbology SWG.

[chris-little]

@jerstlouis In my draft discussion paper on portrayal from ages ago, I preferred the term 'view' to 'layer'. It made more sense in a 3D world, and aligns with the database world use of the term. Probably we would have to distinguish between the data 'view' (which features have been chosen to be portrayed) and the graphical presentation 'view', which I called 'style'. I am relaxed about it and not going to die in a ditch for either terminology, yet. ;-)

[ebocher]

I understand the necessary to clarify definitions. This is one of the major difficulties we had with SymCore. Terminoly is a long-running story ;). But before defining concepts that would be perhaps specific to the OGC-API, do you know if there is a general OGC glossary or thesaurus? If yes we could start from there? if no, what about collecting definitions here and push/share if for the whole OGC standards and specs ? I mean about the main concepts : data, datasource, view, layer, map, style, symbol, expression, function, process. For example, I remember that Matt Sorenson shares with the Portayl group some definitions collected abut Style/Symbology concepts.

[jerstlouis]

@ebocher There is an OGC glossary of terms here.

Here is what it says for style:

Style: Styles provide the mapping from feature types and feature properties and constraints to parameterized symbols used in drawing maps

In the Testbed 15 Open Portrayal Framework, we looked at a consistent portrayal framework that spans both online and offline use cases, and the work done in OGC API - Styles is informed by that framework, so it should not be specific to OGC API. In particular, we also developed a portrayal extension for GeoPackages.

That might be what Matt had shared (engineering report here).

Definition of Style there:

Style: a sequence of rules of symbolizing instructions to be applied by a rendering engine on one or more features and/or coverages

Some of that work had also previously taken place in the Vector Tiles Pilot Extension focusing on styling (engineering report).

[ebocher]

That might be what Matt had shared (engineering report here).

After a bit of archaeology, I attached it.

portrayal_terms_2_june_2020.docx

[jeffharrison]

From the Vector Tiles Pilot long, detailed dialog...

A style organizes the rules of symbolizing instructions to be applied by a rendering engine on one or more geographic features and/or coverages. (from group consensus Jan 18, 2019)

[ebocher]

@jeffharrison sounds good for me.

[chris-little]

@jeffharrison in the VTP definition, I would prefer to remove the adjective 'geographic'. What about portraying disease incidence - a coverage certainly, but not very geographic? Ditto weather use cases. Less is more!

[jerstlouis]

@chris-little @ebocher @jeffharrison I believe the definition from the Testbed 15 Open Portrayal Framework was a refinement of the earlier VTP definition, and therefore supersedes it:

Style: a sequence of rules of symbolizing instructions to be applied by a rendering engine on one or more features and/or coverages

It does not contain geographic, and It also feels more like a definition (rather than saying what a style does).

Compared to the OGC glossary definition, it also seems like an improvement as it considers more than "maps" (e.g. 3D styling).

[jeffharrison]

Sounds good!

[jerstlouis]

SWG 2021-12-07: Today we approve that definition from Open Portrayal Framework:

Style: a sequence of rules of symbolizing instructions to be applied by a rendering engine on one or more features and/or coverages