Open fmigneault opened 1 month ago
@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 https://github.com/opengeospatial/ogcapi-features/issues/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!
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 https://github.com/opengeospatial/ogcapi-features/issues/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.
@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).
In https://docs.ogc.org/DRAFTS/21-009.html, most definitions indicate something in the form or (emphasis mine):
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
andsortBy
could be handled relatively easily in this case, but notproperties
, 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
Another example is the Nested Processes, which requires: http://www.opengis.net/spec/ogcapi-processes-3/0.0/req/nested-processes
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.