search

opengeospatial / ogcapi-coverages

OGC API - Coverages draft specification
https://ogcapi.ogc.org/coverages
Apache License 2.0
22 stars 13 forks source link

Change <coverageid> to <collectionid> #50

Closed matthewhanson closed 3 years ago

matthewhanson commented 4 years ago

The Commons API defines a <collectionid>, used in the path:

/collections/\

Whereas the Coverages API, where a Collection IS a Coverage, uses the term

/collections/\

However, this requires explanation that coverageid=collectionid and extra documentation that seems unnecessary.

Instead if the Coverage API uses the same field name, , that I think it is more clear that coverage is just an additional endpoint on a Collection that the Coverage API adds to the Commons API.

jerstlouis commented 3 years ago

Is there any objection to making this change as suggested? To be discussed on 2021-02-10 call.

pebau commented 3 years ago

Procrustes is calling - forcing a naming that is not semantically adequate and adding to confusion for users.

chris-little commented 3 years ago

So why not name collection as coverage? ;-)

jerstlouis commented 3 years ago

@pebau I would argue that the 'coverage' is at /collections/{collectionId}/coverage, and this has no implication of calling the coverage anything but a coverage.

The {collectionId} is merely an identifier (it could simply be called {identifier}), and naming it consistently with the /collections that comes before it makes a lot of sense. Also, OGC API - Coverages inherits this /collections/{collectionId} from Common - Part 2, so in my opinion renaming the id to something else only adds to the confusion. OGC API - Coverages defines the /coverage end-point, which can be used as one way to access a collection of data (which may also be accessible using other OGC API specifications, e.g. features or EDR), which OGC API - Common - Part 2 defines to exist at /collections/{collectionId}. When writing an OpenAPI definition, you actually need to pick a single name for the parameter, and to highlight the fact that at that level the IDs are the same, it would really be much better if the parameter was consistently called {collectionId} for all paths in the API. Realizing that different collections might be accessible using different APIs: some as a coverage, some as features, some as both.

pebau commented 3 years ago

@jerstlouis Just record my no vote, please.

jerstlouis commented 3 years ago

2021-02-10: SWG Motion: Jerome: Change coverageId to collectionId for consistency Second: Stephan Discussion: We noted Peter's no vote. It is only a documentation change with no impact on implementations. There was no objection from all members present in the SWG, with quorum. Motion passes.

jerstlouis commented 3 years ago

Addressed by #122