search

opengeospatial / ogcapi-coverages

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

Integration of WCPS with OGC API - Coverages #97

Open jerstlouis opened 4 years ago

jerstlouis commented 4 years ago

It was agreed that a service could integrate WCPS functionality at a /wcps end-point, as per https://github.com/opengeospatial/ogc_api_coverages/pull/90. (See also discussions in #79 and #80).

It would be desirable to also support the scaling and subsetting query parameters / conformance classes at that WCPS end-point, as well as support content type negotiation so that those aspects would not have to be defined in the WCPS code itself. This would facilitate re-use of more complex WCPS queries.

A service could also offer WCPS functionality via a generic WCPS process (conforming to OGC API - Processes) taking in the WCPS code as an input parameter, or allowing to deploy new processes (conforming to OGC API - Processes - Transactions) from algorithms expressed as WCPS code.

pebau commented 4 years ago

@jerstlouis: re this part:

It would be desirable to also support the scaling and subsetting query parameters / conformance classes at that WCPS end-point, as well as support content type negotiation so that those aspects would not have to be defined in the WCPS code itself. This would facilitate re-use of more complex WCPS queries.

This would not make WCPS any more powerful as it can readily express this (and much more) in an expression. As discussed, it would only support one very special case at the expense of break the paradigm. Content negotiation could be added easily to WCPS without breaking the paradigm, retaining its flexibility.

jerstlouis commented 4 years ago

@pebau as discussed, I disagree it breaks the paradigm, and I find it interesting that you would be okay with the content negotiation aspect, because I think it is a very similar scenario.

Just like the target format could be coming from outside the WCPS query, so could the target resolution or area of interest. It really is the exact same thing.

I understand that WCPS allows to define all these things inside the query, and the proposal is not to stop it from doing so, or lose any flexibility at all. But in addition to that, this would allow to omit those aspects from the query, which by default would result in the whole processed coverage at full resolution, but would also support requesting a particular AoI and desired resolution using additional query parameters.

Also I really don't see this as one very special case, but as what could a be the key to WCPS integrating well within the OGC API family of standards. The whole point is not wanting to express AOI and resolution and format in WCPS, but wanting to re-use WCPS code for different areas etc.

pebau commented 4 years ago

@jerstlouis : oops, I was ambiguous as I realize now, my bad; just to make sure we are on the same page re content negotiation, here an example of what I had in mind: 

for $c in (MyLittleCoverage)
return encode( $c, "image/jpeg;q=0.5" )
jerstlouis commented 4 years ago

@pebau how does this example differ from the traditional WCPS encode() requests?

What I propose is still allowing the use of encode(), extend(), scale() and subsetting directly in the WCPS code, but also allowing to infer an implied version of these (for the final output coverage) from the query parameters and in the case of the format, from the Accept: header of the HTTP request.

Schpidi commented 4 years ago

Coverages SWG call: Being able to infer these parameters from the query parameters is agreed to be useful and helpful for the adoption of WCPS.

jerstlouis commented 4 years ago

We need to define a proper relation type (fully qualified URL, which should specifically refer to wcps) for linking to the /wcps end-point from the landing page.

Suggestion: http://www.opengis.net/def/rel/ogc/1.0/coverage-wcps