Conflicting strict requirements for Part 3 collections

[fmigneault]

In https://docs.ogc.org/DRAFTS/21-009.html, most definitions indicate something in the form or (emphasis mine):

SHALL link to at least one OGC API data access mechanism such as OGC API — Tiles, DGGS, Coverages, Features, EDR, Maps

This implies that providing a collection as, for example, ONLY an OGC API Features (or STAC) endpoint would be valid. However, that API does not necessarily handle all sub-requirements for input field modifiers. For example, filter and sortBy could be handled relatively easily in this case, but not properties, since it involves a more advanced set of capabilities to compute derived values.

Similarly, the Collection Output has prerequisites that enforce support of all OGC API data access mechanisms:

https://docs.ogc.org/DRAFTS/21-009.html#_requirement_class_collection_output

http://www.opengis.net/spec/ogcapi-processes-1/1.0/req/core
http://www.opengis.net/spec/ogcapi-common-2/1.0/req/collections
http://www.opengis.net/spec/ogcapi-tiles-1/1.0/conf/geodata-tilesets
http://www.opengis.net/spec/ogcapi-features-1/1.0/conf/core
http://www.opengis.net/spec/ogcapi-coverages-1/0.0/conf/core
http://www.opengis.net/spec/ogcapi-coverages-1/0.0/conf/coverage-scaling
http://www.opengis.net/spec/ogcapi-coverages-1/0.0/conf/coverage-subset
http://www.opengis.net/spec/ogcapi-coverages-1/0.0/conf/coverage-rangesubset
http://www.opengis.net/spec/ogcapi-dggs-1/0.0/conf/data-retrieval
http://www.opengis.net/spec/ogcapi-dggs-1/0.0/conf/zone-query
http://www.opengis.net/spec/ogcapi-edr-1/1.0/conf/core
http://www.opengis.net/spec/ogcapi-edr-1/1.0/conf/collections
http://www.opengis.net/spec/ogcapi-maps-1/0.0/conf/core
http://www.opengis.net/spec/ogcapi-maps-1/0.0/conf/spatial-subset
http://www.opengis.net/spec/ogcapi-maps-1/0.0/conf/datetime
http://www.opengis.net/spec/ogcapi-maps-1/0.0/conf/scaling

Another example is the Nested Processes, which requires:
http://www.opengis.net/spec/ogcapi-processes-3/0.0/req/nested-processes

http://www.opengis.net/spec/ogcapi-processes-1/1.0/req/core
http://www.opengis.net/spec/ogcapi-processes-3/0.0/req/input-fields-modifiers
http://www.opengis.net/spec/ogcapi-processes-3/0.0/req/output-fields-modifiers
http://www.opengis.net/spec/ogcapi-processes-3/0.0/req/collection-input
http://www.opengis.net/spec/ogcapi-processes-3/0.0/req/remote-collections

However, if a nested process happens to return a GeoTiff, for example, and the parent process in the chain receiving it supports this media-type, there is no reason to go through Collection Input, Remote Collection, or apply any Input/Output Fields Modifiers. A Nested Process definition would be valid on its own. Although these capabilities could be combined simultaneously with a nested process that returns a collection output applied for a particular processing chain, they are not required.

I believe it would much more beneficial for the adoption of these capabilities to reduce the "combined set" of requirements. They define much more granular combinations. This would allow implementers to gradually add more support, without having to implement everything all at once, especially that not all capabilities are necessarily desired. It would also better align with the mention of "at least one" OGC API data access mechanism that must be supported, not all of them.

[jerstlouis]

@fmigneault I don't see a conflict there, but the current "prerequisites" are not reflected as intended.

It definitely is the intent that OGC API - Feature is an access mechanism for the collection output/input.

Regarding the sub-requirements for input field modifiers (which is a particular requirement class that an implementation can conform to or not), there is a plan to potentially define that as well in Features as a conformance class of Part 6 (see opengeospatial/ogcapi-features#927).

Similarly, the Collection Output has prerequisites that enforce support of all OGC API data access mechanisms:

The Prerequisites there are wrong. There should be a "one of" the "Core" requirement class of the different access mechanisms, plus a bunch of optional dependencies.

Same thing for the Nested Process. There should only be a dependency on Part -1 Core, + an "optional" dependency on the others (to indicate that these capabilities also work with Nested Processes).

I believe there may actually be a note in the source ASCIIDoc at the moment that does not get reflected in the HTML / PDF output. We should look into fixing that. Thanks!

[fmigneault]

The conflict is really between the "at least one" mention vs the full list of explicit coverage/features/tile/dggs/edr/maps prerequisites. As you highlighted, it cannot be both. If "oneOf" the data access methods is sufficient, all others cannot be required at the same time. Therefore, none of them can be a prerequisite, beside maybe http://www.opengis.net/spec/ogcapi-processes-1/1.0/req/core and http://www.opengis.net/spec/ogcapi-common-2/1.0/req/collections that are shared by all.

Regarding opengeospatial/ogcapi-features#927, I think my concern still stands. One could relatively easily support filters and sortBy with features, but I think properties support implies a lot more complexity, since the derived names can be reused elsewhere in the processing chain. It requires more advanced capabilities than "only" filtering/sorting the referenced collection.

[jerstlouis]

@fmigneault

Yes the full list should not be a pre-requisite, but "one of them" is still (at least conceptually) required.

I think my concern still stands.

Potentially we could split the "Input/Output" field modifiers into separate requirement classes for filtering vs. deriving values (as would likely also be done in Features, and as we're also planning to do in Coverages).