Re: [wcsplus] WCS 1.0+ interoperability and application profiles

  • To: "Woolf, A (Andrew)" <A.Woolf@xxxxxxxx>
  • Subject: Re: [wcsplus] WCS 1.0+ interoperability and application profiles
  • From: Ethan Davis <edavis@xxxxxxxxxxxxxxxx>
  • Date: Wed, 31 Oct 2007 15:09:33 -0600
Hi Andrew,

Thanks for putting this together. A few comments and questions:

1) I agree it would be easy to get bogged down in the details of further spec-ing out asynch capabilities. To that end, I agree we should move forward with the WPS approach as DEWS WCS implemented and you spell out in your WCS 1.0+ document.

My only concern with taking the WPS approach is that it doesn't seem to allow the server to provide estimates for process completion time/duration. Unless I missed it the only estimate was a "percent complete" integer value. I really see asynch capabilities as requiring negotiation (or at least access to time estimates) before the actual request.

Oh, I see you have added a creationTime to the Status element. Sorry, I'm loosing track of these details -- is that from the DEWS spec or a new addition? I'm assuming that is an estimate for creation of the output rather than the time of process creation/request. Is that right? A similar addition would allow for ProcessAccepted processing duration estimates or even pre-request estimates.

2) You mention that 1.1 allows nested coverage but it doesn't look like you use that anywhere. Is that correct? I'm not suggesting we do as it does seem of little use (sharing metadata). Just wanted to double check.

3) I find the 1.0 description of RangeSet and axisDescription (especially what multiple occurrences means) a bit confusing and unclear. In 1.1, RangeSet is replaced by Field and the multiple occurrences of Axis are for multiple dimensional vector parameters. That seems much clearer than 1.0. So, I'm wondering if we should modify rangeSet to allow multiple RangeSet-s (or use the 1.1 Field) rather than using multiple axisDescription-s.

4) I like your alternate option for GetCoverage KVP encoding. More 1.1 than 1.0 but seems to make more sense.

5) HTTP response codes.

At a minimum, I'd like to propose we agree to:

   200 response codes for successful responses
   400 response codes for exception report responses

Clients might want to think about (but probably not important for 1.0+)

   3xx for redirects (301, 302, and 307, at least)
   401 for authorization capabilities

6) Google Docs works for me.

7) OK, that's it for now. I'll have some CRS questions soon. In particular, I'm in the middle of trying to understand GML CRS stuff, OGC CRS URNs, and how the CF "grid mappings" and GRIB grids would map into that.


Woolf, A (Andrew) wrote:
Hi Jon,

My perspective: The effort initially was proposed as an 'implementation
interop' experiment between Unidata, CNR-IMAA, STFC, and the Met Office.
Of course if something useful comes out, then that will be fed back to
OGC membership and WCS RWG.

The motivation is very definitely to avoid lengthy 'specification
develpment' arguments and get on with actual implementations that do
what we need. Unidata and STFC hope to develop servers, and CNR-IMAA a
client, with Met Office playing a role in review against operational
requirements (I hope I'm not misrepresenting anyone's intentions).

The aim also is to stick as closely as possible to WCS 1.0 and avoid as
much as possible inventing new things. The key issues identified from
GALEON 1, and targets of this exercise are: asynch, heterogeneous
coverages, irregular grids.

To that end, I'm sending an initial draft outline of capabilities that:
 * adopts a WPS approach for asynch, proven in the DEWS WCS (Jon I stole
some of your words here)
 * minimally 're-interprets' 1.0 AxisDescription for heterogeneous
 * adopts 07-112 proposal for 19123 irregular grids in GML (details to
be added)

Regarding the asynch, I think there's a danger in trying to make 1.0+
solve the full spectrum of use cases, that we might get too bogged down
in 'designing the spec' to actually get on with the implmentations that
are the focus of this exercise. Given DEWS success, and the existing
approach of WPS, it seems to me that's a good thing to focus on. I've
adopted the WPS ExecuteResponse as Jon indicated would work.

My suggestion is that we try and converge on an agreed spec as quickly
as possible - sticking with the 'minimal change' and 'implementation
focus' principles agreed, even to the detriment of functionality.

Ben suggested Google docs as a mechanism for collaborative work on the
spec doc - what do people think?


Ethan R. Davis                                Telephone: (303) 497-8155
Software Engineer                             Fax:       (303) 497-8690
UCAR Unidata Program Center                   E-mail:    edavis@xxxxxxxx
P.O. Box 3000
Boulder, CO  80307-3000