My issue with collectionid == coverageid might be because I'm late to the conversation. Has the case where a given data provider has a number of collections each of which have a number of coverages been covered? I'm thinking of providers like NASA, where the 'collections' are well known in the user community.
@jgallagher59701 this is somewhat covered by combining the various API elements. The API-Features can be used to describe a collection that is a number of coverages. In this case, each coverage is an individual element in the collection. Hierachies of collections is where it gets messy with generic APIs. This could be a place where best practice APIs need to be established.
@jgallagher59701 : yes, this has been discussed, but then the decision presented has been made (not unanimously). One reason is that the Features group pushed the "view" perspective, ie: some coverages might also be seen as features, and vice versa. As has been stated by experts in the room that does not always work anyway. Second, AFAIK REST is not able to describe recursively nested items, such as collections of collections, of undefined depth. Personally, I very much like the idea of nested collections, maybe we can flesh out a suggestion?
@tomkralidis thanks for posting the link!
@jgallagher59701 another reason: there is a very justified requirement to be able to retrieve geo objects on a server regardless of the type (feature, coverage, coverage sub-type, etc.). So /collections/ would retrieve all objects (filtering might limit the number of hits, just to anticipate the concern). In case of nested objects the user would get back a tree essentially, and that has not (yet?) been included in OAPI Common. Challenge: can this be done in a way that is still simple to handle for the user? Looking forward to discussion.
+1 - all users want to subset
...in the domain (spatial, temporal) and in the range, say from a coverage with 50+ climate variables.
@jgallagher59701 is the opendap server you mentioned open source?