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

jerstlouis · 2021-03-26T00:41:00Z

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 ( Default map at /map; move current metadata to /styles and {collectionId} ogcapi-maps#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.

The text was updated successfully, but these errors were encountered:

serich · 2021-03-26T05:18:46Z

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 · 2021-03-26T05:52:54Z

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 · 2021-03-26T08:28:35Z

@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 · 2021-03-26T12:54:38Z

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 · 2021-04-20T14:38:43Z

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 -

Styles under Collections, and
Use Maps and Tiles as a sub Resource of Styles
Keep Styles Metadata and not remove it

(SWG will review Issues that are open and adjudicate)

SWG discussed and there was NOTUC

- updated requirements so that a Styles resource is not tied to the landing page and can also be, for example, associated with a feature collection resource (closes #1, starts to address #8) - use of Common Core instead of referencing Features Core - use of the general req classes Create/Replace/Delete and Update currently in Feature Part 4 as the basis for the req class `manage-styles` - use of `Prefer` header preference "handling" in the req class `style-validation` - editorial updates and clarifications - removed req classes for file resources, this is not really necessary and such a capability can be implemented in various ways without interoperability issues - removed req classes `queryables` (no longer needed - tiles and features have mechanisms to describe the schemas of attributes) and `style-info` (no longer needed)

jeffharrison · 2021-05-04T15:03:47Z

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

Stylable Layer Set topic moved over to OGC NA.

cportele self-assigned this Apr 20, 2021

cportele mentioned this issue Apr 30, 2021

implement changes discussed in April 20 SWG call and more #10

Merged

jeffharrison closed this as completed May 4, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

jerstlouis commented Mar 26, 2021 •

edited

Loading

serich commented Mar 26, 2021 •

edited

Loading

jerstlouis commented Mar 26, 2021

cportele commented Mar 26, 2021

serich commented Mar 26, 2021

jeffharrison commented Apr 20, 2021

jeffharrison commented May 4, 2021

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

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

Comments

jerstlouis commented Mar 26, 2021 • edited Loading

serich commented Mar 26, 2021 • edited Loading

jerstlouis commented Mar 26, 2021

cportele commented Mar 26, 2021

serich commented Mar 26, 2021

jeffharrison commented Apr 20, 2021

jeffharrison commented May 4, 2021

jerstlouis commented Mar 26, 2021 •

edited

Loading

serich commented Mar 26, 2021 •

edited

Loading