Geo Data Class (Stylable Layer Set) URIs

[jerstlouis]

Proposing to have a registry of stylable layer sets for use with portrayal.

A StylableLayerSet is a URI which would resolve to metadata including the schema for any data layers found within a particular dataset. The metadata associated with this SLS allows the creation of new style sheets even in the absence of data available, and can readily be used to fill the schema portion of the style metadata.

The SLS provides a simple identifier for quickly identifying whether a style is suitable for a particular dataset or data layer (collection), avoiding a deep dive comparison of the dataset schema vs. the style metadata.

See also:

http://docs.opengeospatial.org/per/19-023r1.html#_styleable_layer_sets https://docs.ogc.org/per/19-088r2.html#terms_definitions

[jerstlouis]

Better name for this as it is not specific to styling... e.g. discovering input data suitable for a particular process. Geo Data Class?

[jeffharrison]

It might be best to call this something other than Stylable Layer Set (?). Styles SWG is working on suggestions...

[ghobona]

@jeffharrison I'm glad the OGC API - Styles SWG is working on suggestions.

Ideally the name should avoid potential confusion with https://medium.com/@stylable.io/introducing-stylable-and-a-musical-3626ebe41a53

[jerstlouis]

This concept is very similar in principle to ISO 19110

Geographic information — Methodology for feature cataloguing

In ISO 19115 this is covered by MD_FeatureCatalogueDescription (e.g. featureCatalogueCitation).

[ghobona]

@jeffharrison @oertz @jerstlouis The OGC-NA will wait for the Styles and Symbology Encoding SWG and the OGC API - Styles SWG to agree on a definition.

@BrooksDown I would suggest getting the topic into the next Portrayal DWG meeting so that the two SWGs can discuss in a common space.

[jerstlouis]

@ghobona The concept is also not limited to Styles SWG, which is partly why we suggested the new "Geo Data Class" name. It would also work equally great for discovering datasets suitable as input for a particular Process.

[jeffharrison]

Yes, the OGC API- Styles SWG is recommending that we need to find a better designator for this than "Stylable Layer Set".

Specifically, the thing under discussion is an "Encoding of Data Conforming to an Application Schema that can be Styled".

For example, OS Zoomstack has vector tiles and GPKG encodings with slightly different FeatureTypes, but they are both representing the same Application Schema.

Thoughts welcome...

[ghobona]

If the subject of a statement is the Style, then the relationship to the Data could be just DatasetStyled.

[jerstlouis]

If the subject of a statement is the Style, then the relationship to the Data could be just DatasetStyled.

@ghobona The idea with a GeoDataClass is to not be tied to any specific dataset, or any specific style (or process), but to have a URI describing a class of data which a dataset can belong to, a style can portray, or a process can use as an input.

This URI / class can be established before any data set, style or process is created. And any number of additional Styles, Processes or DataSets can be created conforming to it, and discovered, after it has been published.

A single relationship pointing to a single "DataSet styled" misses the objectives.

[ghobona]

The difficulty is that what is being proposed is not specified in detail in any OGC Standard, profile, nor extension. I would prefer to transfer this GitHub Issue to a repository of a SWG or DWG that is tasked with specifying the concept of a Geo Data Class (Stylable Layer Set) so that the concept can be more formally specified.

@jerstlouis Would the Styles & Symbology SWG be the place to discuss and formally specify this concept?

[jerstlouis]

@ghobona That might actually be a good idea.

Perhaps we could include this on the roadmap for the next minor revision to SymCore that we will be discussing at the OSGeo Community Sprint in a couple weeks. @ebocher

It is also not specific to Styling, so perhaps if we could also involve the Architecture DWG and perhaps the Workfows DWG/Processes SWG it would be great as well.

The Testbed 15 Metadata Conceptual Model for Styles ER details the concept a little bit, specifically the metadata about the layers and expectations about them that are used by a style, as well as the GeoDataClass (called StyleableLayerSet in the ER) which would be a URI allowing for a quick search / discovery / comparison without doing a deep comparison into the detailed metadata of the layers to be styled or provided as a process input. When the GeoDataClass URI is a match, the deep comparison is expected to be equivalent.

A registry on the definition server allowing to both register URIs for classes of commonly used geo data sources, as well as ideally allowing to retrieve the corresponding metadata (title, description, the data layers / collections and their associated properties (measured or observed i.e., data record fields / range type / schema) is mainly what would be required so that OGC API - Common - Part 2: Geospatial Data, OGC API - Processes process description, OGC API - Styles styles metadata, GeoPackage portrayal extension, and all other other OGC API specifications depending on these could become aware that a particular collection will work well as an input to a given process or to be portrayed in a given style.

[ghobona]

Thanks @jerstlouis .

I am transferring the Issue now.

[chris-little]

@jerstlouis @jeffharrison @ghobona Let me add a few cents' worth. I envisage the data collections exposed through the API-EDR to be good candidates for a geodata class or stylable layer set or whatever. The key factors from the EDR point of view are:

1. Number of dimensions, such as x,y,z,t plus others which may be continuous (e.g. frequency)
2. Whether any dimensions are ordered discrete or categorical (no instrinsic ordering)
3. Whether the variables/observations/parameters are scaalr, vector, tensor or something else.
4. Whether the variable range is continuous or discrete or categorical HTH

[jerstlouis]

@chris-little Thanks, agreed, such aspects of the domain (though not the bounds/extent) as well as the fields/properties (observed or measured) (CIS range type) can be described in the Geo Data Class as well.

I think it should also be possible to add extra dimensions without breaking compatibility with a GeoDataClass.