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

NOTE: The wcsplus mailing list is no longer active. The list archives are made available for historical reasons.

Hi all,

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 ESS community.

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.



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?


  • 2007 messages navigation, sorted by:
    1. Thread
    2. Subject
    3. Author
    4. Date
    5. ↑ Table Of Contents
  • Search the wcsplus archives: