Open jerstlouis opened 3 years ago
@aaime @pomakis
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?
I think the new wording in the latest commit is reasonable and will help interoperability.
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'.
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 aFeatureTypeStyle
(for a feature collection) or as theCoverageName
of aCoverageStyle
(for a coverage), and/or as theName
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".
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.
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:
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:
featureType
member.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.
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.
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!)
A
Name
can be specified in aNamedLayer
, but aFeatureTypeName
can also be specified in aFeatureTypeStyle
.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 multipleUserStyle
for a singleNamedLayer
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 allUserStyle
should have the same name if provided?). Should there be a requirement to only include a singleUserStyle
perNamedLayer
, or clarify that all additional UserStyle will be ignored, that the first (or last?) will be used?