Section 7.1

[AlexRamageScot1]

Comments from the UK:

The UK support the work that has gone into providing the document and are happy that the Inspire community is looking at the new OGC API - Features specification.

Suggested change for section 7,1:

“INSPIRE recommends that each OGC API – Features provides data from one data set. The exact composition of a data set shall be determined by the data publisher. It may be that the data set contains all that publishers’ information on one INSPIRE theme, but other compositions are allowed.

This means that one data publisher will often need to provide more than on OGC API. The result of this is that each landing page describes one data set.

This is recommended as an alternative to providing one OGC API and therefore one landing page, with a collection for each INSPIRE theme; or a landing page with a collection for each feature type, with themes not described. Both of those are valid design approaches, but not recommended for INSPIRE.”

Alex Ramage

[cportele]

Regarding the last paragraph: As long as only OGC API - Features - Part 1: Core is referenced by the document, there will be a one-to-one relationship between the API and a dataset. Additional parts may specify rules how to support multiple datasets per API, but the Core does not. This is reflected in several sections of the standard, for example, in the overview of the Core conformance class:

A server that implements this conformance class provides access to the features in a dataset. In other words, the API is a distribution of that dataset. A file download, for example, would be another distribution.

NOTE: Other parts of this standard may define API extensions that support multiple datasets. The statement that the features are from "a dataset" is not meant to preclude such extensions. It just reflects that this document does not specify how the API publishes features or other spatial data from multiple datasets.

[aaime]

I agree that having a single API/dataset with multiple collections seems a better setup, simpler in its organization, and it would allow for usage of potential future extensions, like downloading multiple collections in a single request, building multi-layer vector tiles, joining, cross layer filtering (returning features in collection A that spatially interact with features in collection B) and more.

More in general, I would not force a particular layout, allowing both single dataset with multiple collections and multiple datasets with one collection, and other types of subdivisions as well. It seems that all is needed to get there is moving the enclosure link from the landing page to the single collection description. That could be available either in the "/collections" output, or in the single "collections/collectionId" description (a server can decide to provide only a summary in the "/collections", and richer set of attributes when describing the single collection alone).

[PeterParslow]

I'm not sure I see aaime's point. I read this as about how to relate INSPIRE themes & spatial object types to OGC APIs, datasets, and collections.

I like the approach where the data publisher determines the nature of the dataset. A given publisher is likely to have multiple APIs (sticking to Core), each with one dataset. Many will choose to have one API/dataset per theme - but for my complex INSPIRE themes (e.g. Transport Networks) a publisher may want one API/dataset for each sub-theme (Road, Rail,...) - or some other mapping. The landing page allows for multiple keywords to be associated with an API/dataset, making it discoverable by keyword (theme, spatial object type, etc) whichever way it is structured.

Note: I (OS) was the source of the comment Alex posted (as our national contact point).