Content Negotiation

[cmheazel]

Requests such as "/collections/{coverageid}/coverage/all" return a mixture of "metadata" and range set data. In most cases this collection cannot be represented using a single format. So multi-part mime-types are required. While API-Common provides two conformance classes to identify the supported encoding formats, that approach will not scale to API-Coverages. The draft of API-Coverages has attempted to address this issue. Please review, comment, and provide suggestions for improvement.

[pebau]

well, they return a coverage - which is a concise, complete description. Down-scaling to OAPI is no problem, keeping in mind that the result of a coverage request (as per OAPI Core) is a coverage representation (see WCS section on result encoding, and the slide decks and tutorials on http://external.opengeospatial.org/twiki_public/CoveragesDWG/WebHome#Educational_Material ).

May I suggest that we discuss this in Bethesda as we will have ample time and can scribble stuff?

PS: The issue has been addressed by the WCS.SWG earlier, culminating in the 2012 coverage standard ;-)

[cmheazel]

@pebau I agree that this is an issue for Bethesda.
A couple places where we may have difficulties: 1) /all, as currently defined, does not support all possible coverages. So just pointing to CIS is not enough. 2) Each part of the coverage can now be accessed and used independent of the other parts. This also means that different encodings can be used for each part.

I believe that the "requirements class for each encoding" approach used in Features is too heavy handed for our needs. We need a more finessed approach to content negotiation. Not a hard problem, but we need to agree on a solution and how to document that solution.

[pebau]

ad 1: there is no restriction AFAIK - /all returns a coverage of whatever type. ad 2: yes, naturally - after all, every component is of a different structure.

[Schpidi]

Coverages SWG call: OBE - Overcome by events (Accept http header, f parameter, etc.)