SLD/SE: Clarify how styles are applied to collections

[jerstlouis]

A Name can be specified in a NamedLayer, but a FeatureTypeName can also be specified in a FeatureTypeStyle.

Which of these associate a style to a {collectionId}? Is it either or both, and which one should be required in the SLD conformance class? Also clarify how multiple UserStyle for a single NamedLayer should be handled, and whether multiple styles within a single SLD/SE make sense. In the Styles API, the style sheet should define a single UserStyle (so all UserStyle should have the same name if provided?). Should there be a requirement to only include a single UserStyle per NamedLayer, or clarify that all additional UserStyle will be ignored, that the first (or last?) will be used?

[jerstlouis]

@aaime @pomakis

[jerstlouis]

Styles & Symbology SWG 2021-06-16: As both approaches (NamedLayer's Name and FeatureTypeName) have been used, we should keep supporting both. Therefore the recommendation would be for servers to provide both, and having both of them consistent. Clients should be prepared to understand either of them, with the more specific one (FeatureTypeName) taking priority (as in some cases the NamedLayer's name may refer to a particular symbolization, e.g. casing or center line). @aaime @pomakis Could you please review and comment on this approach?

[pomakis]

I think the new wording in the latest commit is reasonable and will help interoperability.

[jeffharrison]

SWG reviewed the status of this potential merge on 13 July 2021. Consensus is this update looks good. SWG requested Clemens review the wording to ensure it is more 'Normative'.

[jerstlouis]

PR #28 has been revised to clarify the relationship between OGC API collections and UserStyles in SLD/SE content. However one requirement still poses a problem for APIs implementing support for hierarchical collections as proposed in https://github.com/opengeospatial/ogcapi-common/issues/11#issuecomment-677947387 .

B) names corresponding to collection ids SHALL be specified as the FeatureTypeName of a FeatureTypeStyle (for a feature collection) or as the CoverageName of a CoverageStyle (for a coverage), and/or as the Name of a NamedLayer (for compatibility with this alternate approach to associate styles with collections)

The issue is that with hierarchical collections, a collection id would be something like Daraa:AgricultureSrf, but the FeatureTypeStyle's FeatureTypeName (and/or the NamedLayer's Name) would be simply AgricultureSrf. I am wondering if we could perhaps add a permission that could acknowledge this use case?

A practical example that has been up on our server since the Vector Tiles Pilot is found here:

https://maps.ecere.com/ogcapi/collections/Daraa:AgricultureSrf https://maps.ecere.com/ogcapi/collections/Daraa/styles/night.sld

Such a permission could read something like:

If an API implements support for hierarchical collections, e.g. using : as a hierarchy separator, then the FeatureTypeStyle's FeatureTypeName (and/or the NamedLayer's Name) MAY correspond to the differentiating portion of the collection ID, omitting its parent collection prefix.

This is also related to the layer names found e.g. inside vector tiles, as well as to the layer IDs inside OGC API - Tiles TIleSet metadata, which would also omit such parent prefix (e.g. https://maps.ecere.com/ogcapi/collections/Daraa/tiles/WebMercatorQuad.json).

One notable use case for such hierarchical collections allows offering both multi-layer vector tiles as well as individual layer as separate collections of the same dataset, e.g.

https://maps.ecere.com/ogcapi/collections/Daraa/tiles/WebMercatorQuad/{tileMatrix}/{tileRow}/{tileCol}.mvt https://maps.ecere.com/ogcapi/collections/Daraa:AgricultureSrf/tiles/WebMercatorQuad/{tileMatrix}/{tileRow}/{tileCol}.mvt

As well, it enables a publisher to organize and publish different data layers, which may consist of multiple multi-layer vector tiles and/or coverage collections, as a single "dataset API".

[jeffharrison]

On 5 Oct 2021 SWG reviewed this Issue with a focus on the comment concerning support for hierarchical collections. There was NOTUC to 1) merging the revised PR #28 and then 2) using that as a basis to address support for how styles are applied to feature types.

Clemens P took an action to draft text that describes the relationship between OGC API Collection and the concept of feature type. (may be relevant to SymCore, JSON - FG, OGC API Features Schema Extension etc as well)

Note - Features, Tiles, Styles and Common may be interested in this Issue.

[cportele]

Here is draft text for discussion:

In OGC Web APIs, geospatial data is organized in collections. For example, the features in a dataset are shared via one or more feature collections. The relative path of a collection from the landing page is collections/{collectionId} where collectionId is the identifier of the collection.

This text discusses the relationship between features and their collections. This discussion uses the following terms and definitions in addition to the terms specified by OGC API Features:

• A feature is described by a set of properties, where each property is a key-value pair.
• A feature may be associated with one or more feature types that classify the semantics of the feature.
• Often, a feature type is associated with a schema that specifies the set of properties that are provided for feature instances of that type. This is done to support applications that depend on knowledge about the properties of features. For example, to style road features depending on the road classification or road width, the application that renders the features needs to know the property keys and value ranges that convey this information.

It is the decision of the API provider how the features of a dataset are organized into collections.

There is no requirement to provide information about feature types or schemas in the distribution of a feature dataset. Styling such data will typically require knowledge about the data and will often require that styles are published with the data.

If feature types and schemas are supported by the distribution of a dataset, the following is recommended to support map generation:

• The feature type should be available as a queryable.
• The list of feature types that a feature implements should also be included in the feature representations. The details will depend on the format. In JSON-FG, for example, there is the featureType member.
• The feature types should also be listed in the Collection resource.
• It is also recommended to include information about the dimension of the geometries in the collection in the Collection resource.
• If schema resources are provided, it is recommended to provide a schema for each feature type and construct a schema that uses oneOf to compile a single schema that describes all features in the collection.

The extensions in the Collection resource should be specified by OGC API - Features - Schemas.

Rule expressions in style languages should support selecting features by their feature type(s) as well as the geometry dimension.

[jeffharrison]

SWG discussed on 30 November... Comment made that in the absence of a Feature Type then Collection ID may be used.

SWG discussed that different Style encodings have different concepts (Ex. MBStyle uses "Layers" and 'Source Layers").

Additional discussion scheduled for future meetings and members agree this is a key topic for harmonization.

[jeffharrison]

SWG discussed again on 7 December... Comment made that OGC API - Styles still needs to deal with challenge where you have one set of data and multiple Style encodings. For example, OSM data as a 'TDS' may need to be styled using MBStyle and SLD.

Question - For vector tiles would we need to specify in OGC API - Tiles, Tile Set Metadata 'Layers' the same type of functionality as the extensions in the Collection resource specified by OGC API - Features - Schemas? Answer - YES

Note - In OGC API - Common: Part 2 the integration point would be Collection.

In the OGC API - Styles candidate specification we need to explain 1) what are the key concepts that all styles have (in Styles Metadata) and 2) the mappings (by ID/special property) for these to the data schema in Features API or the layers in Tile Set Metadata

NOTE - NEED TO CHANGE 'STYLE LAYER' IN STYLE METADATA TO 'DATA LAYER' (SHOULD BE DONE ALREADY!)