Possibility to attach /styles to other end-points such as /collections/{collectionId}

jerstlouis commented 3 years ago

As discussed at the March 25, 2021 Members Meeting SWG session:

We identified use cases for providing styles usable with a specific collection, such as:

Attaching /map, /map/tiles, /tiles (e.g. vector tiles filtered by style) to these end-points ( https://github.com/opengeospatial/ogcapi-maps/issues/56 )
Retrieving a style specific to a particular collection, including the use case of the server filtering the styling rules from a dataset-wide style whose rules are filtered to only keep the ones pertaining to the collection
This fits well with SLD/SE practice, although a separate issue concerns how rules are associated with specific collections
For MapboxGL styles, this provides a mechanism for sourcing tiles for a specific layer (e.g. collection tiles) vs. multi-layer vector tiles for the whole dataset.

It would also be good for servers to have the option to independently decide whether to support any of the following capabilities at either end-points, or both:

Listing available styles (only thing required to support the Maps & Tiles use cases)
Retrieving a style (if the publisher wishes to share the styles source)
Creating / Updating / Deleting styles (if the server wishes to support styles management & the user is authenticated)

As discussed, users might only have the styles management option at the dataset level, while the styles available for individual collections are automatically updated by the server, e.g. filtering rules to the collection to which they apply.

Similarly, the styles management API might be at available at a "multi-datasets" end-point (e.g. a landing page of landing pages), while the individual dataset and collection might automatically populate available styles based on styles / data association.

Two mechanisms for that styles / data association were defined in previous initiatives, including:

The style metadata, which describes the properties which must be available, their data types and optionally their semantics. Doing a deep comparison of the style metadata and properties available from a dataset allows to establish compatibility.
The Stylable Layer Set concept, which both datasets and styles can be tagged with, and provides a quick single text string comparison mechanism to determine style / dataset compatibility. It was clarified that the concept of SLS expects well-defined URIs, and that it would be useful to manage a repository of stylable layer sets on the OGC definition server.

However, any mechanism could be used for deciding how the styles offered are selected for individual datasets and collections (e.g. if not explicitly managed by the user at these levels), and none of this should impact the Styles API itself.

Example implementations of the collection-level Styles API, as well as associated maps and tiles sub-resources, have already been successfully deployed so far by both CubeWerx and Ecere:

CubeWerx

Ecere

The /collections/{collectionId}/styles end-point was the one implemented by Ecere in Testbed 15 - Open Portrayal Framework.

See also the "follow the link" OGC API map by @joanma747 for how this supports the Maps & Tiles use cases to retrieve maps & tiles for a specific style.

serich commented 3 years ago

The March 25 recording and chat log are in this meeting folder.

My stupid question: is the latest version of the draft spec settled (and making its way through the approval process)? Or still open for substantial modifications?

jerstlouis commented 3 years ago

Thanks @serich

I believe it is fairly early in the standardization process... I don't think it ever went through an OAB review. The specfications I think reflect mostly the work that was done in Testbed 15 - Open Portrayal Framework (http://docs.opengeospatial.org/per/19-010r2.html).

That being said, and the API being quite straightforward (basically as simple as .../styles/{styleId}), I don't expect very substantial changes.

cportele commented 3 years ago

@serich - As @jerstlouis has said, the Styles API has been tested quite a bit in the innovation program (testbed 15, vector tiles pilots), but we still have to build up more momentum in the standardization process. For most parts, the Styles API is straightforward and just follows the HTTP semantics. There are a few aspects that will need more discussion (style metadata) or that were a bit awkward (links between collections and styles) and that need to be addressed by the SWG. Regarding the last point, I think the proposal in this issue is a good step to make the API more intuitive / "natural".

serich commented 3 years ago

Thanks @cportele and @jerstlouis .

I think everyone else in the SWG is already aware of this, so I hope it doesn't drain too much energy to address it.

One of the risks that we might want to mitigate is that we settle on a spec that can be implemented by two different providers, each of which asserts conformance, but the two implementations don't interoperate (or one interoperates with a conformant 3rd-party client and the other doesn't).

The approaches to mitigating this risk might differ depending on which of the three approaches (from yesterday's meeting) is being assumed. Perhaps we could identify a set of "core" conformance criteria based on one of the definitions, and then two additional sets to accommodate the other two definitions. Then hopefully the path to building the compliance testing would be easier later. I guess the difficult problem would be to figure out which is most suitable as the core. (Or maybe all three would need to remain independent?)

Anyway, my selfish interest is to better understand them as we proceed through Testbed-17, where we're building at least three new API specs (Aviation, Geo Data Cubes, and Moving Features). The idea will be to try to bake the mitigation in at the foundational level.

Thanks.

P.S. I'm sure there's a much briefer expression for what's in my lengthy description above, but I can't think of what it is right now... "transportable endpoint compliance test design" seems too heavy.

jeffharrison commented 3 years ago

From 20 April 2021 Styles SWG Mtg:

Clemens takes action to ensure that, in addition to having Styles as a top level Resource, we can have -

1) Styles under Collections, and

2) Use Maps and Tiles as a sub Resource of Styles

3) Keep Styles Metadata and not remove it

(SWG will review Issues that are open and adjudicate)

SWG discussed and there was NOTUC

jeffharrison commented 3 years ago

SWG recommends closing this Issue. Addressed by Pull Request #10

Stylable Layer Set topic moved over to OGC NA.

opengeospatial / ogcapi-styles

Possibility to attach /styles to other end-points such as /collections/{collectionId} #8