What to do when a collection can be accessed as an EDR resource and as features or coverages?

[dblodgett-usgs]

(edit to update my understanding of the issue)

Currently, API-Features specifies that a collection has itemType Feature which is a typing mechanism for the items from the feature. There is no typing mechanism(s) for collections themselves.

What do we want to do in the case that a collection is both accessible as a feature collection or via an EDR query pattern?

It's easy to imagine a world where we would want to support Features, Coverages, and some EDR query patterns. Once we get out to the /collections/{collectionid}/items or /collections/{cooverageid}/coverages or /collections/{collectionid}/area resource, things are fine, but the cataloging of coverages that have multiple overlapping types needs to be solved.

I'm asking this as a leading question related to #38 and opengeospatial/ogcapi-common#140 to provide some food for thought and to reiterate the distinction between the two options I offer in opengeospatial/ogcapi-common#140:

1. Will the collections end point be a container (catalog) for flexibly typed resources that are ostensibly datasets?
2. Will the collections end point be reserved for collections of things that are ostensibly features?

Records is saying that the itemType of a collection that conforms to the records API is catalog. Which works because a catalog is also conformant to and is an extension of Features.

This itemType only tells us the type of items available from a collection. For other endpoints under /collections/{collectionid}, such as .../area or .../coverage we would need an additional typing mechanism. Let's call it accessType for the sake of this issue.

So for EDR, we could have a itemType of edrFeature (or some such) that would be our extension of Features and have accessType of items, area, position, etc.

[dblodgett-usgs]

1. as discussed in: Collections Discussion ogcapi-common#140 we will use link relations to describe the availability of alternate distributions of a collection -- not an accessType element in a json-schema for collection info.
2. How itemType will be used is still an open question but does not need to block EDR from moving forward. Presumably we would need an itemType for our schema for the items feature collection.

[dblodgett-usgs]

This issue was discussed in https://github.com/opengeospatial/Environmental-Data-Retrieval-API/wiki/2020-06-04 -- we agreed that opengeospatial/ogcapi-common#140 and the summary I gave just above is good and we can move forward.