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. Regards, --Stefano
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 coverages * 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? Regards, Andrew
wcsplus archives: