I'd like to add a couple of general comments:
In a broader picture, this is an interoperability experiment stemming
from the Earth & Space Science Community needs; its implementation
results, recommendations and request for change/enhancement might be
extremely valuable for the geospatial information standardization and
integration initiatives, such as the OGC and the CF-netCDF. In my
opinion, in the next future, initiatives like WCS1.0+ will be
promoted or supported by forum, such as: AGU-ESSI, EGU-ESSI, eGY, etc.
In addition to GALEON phase 1, this effort was urged by the
OGC-UNIDATA interoperability day conclusions, too. WCS 1.0 seems to
be the only implemented specification, so far. In fact, the Earth &
Space Science community asks for simple and "non-invasive"
implementations; a possible solution might be to "clean" the quite
loose WCS 1.0 specification, "slightly" improving it (Andrew
beautifully listed the main points and the solutions which are under
discussion and investigation).
In fact, the WCS1.0+ philosophy is to discuss and keep complexity at
the abstract level, coming up with "simple" implementations -based on
implementation constraints which are effective and bearable for the
A valuable case in point is the asynch issue: in my opinion, WCS1.0+
started a first, open and great forum to discuss about asynchronous
OWS, in general. As I anticipated, we're trying to summarize this
discussion in a white paper in order to provide it as a contribute to
the ESSI and OGC communities.
Another valuable example seems to be the CF-netCDF profile.
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
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?