OGC/GALEON November 28, 2007 Teleconference Summary

Russ’ Notes with Ben's Edits

Original Agenda Topics:

Attendees:

• Carl Reed of the OGC
• Roy Mendelssohn of the US Pacific Fisheries Environmental Lab
• Dominic Lowe and Andrew Woolf of the British Atmospheric Data Center
  
• Greg Rappa and Oliver Newell of MIT Lincoln Labs
• Karen Millard of HR Wallingford
  
• Stefano Nativi of the University of Florence and CNR/IMAA
  
• Peter Bauman from Jacobs University
  
• Aaron Braeckel of NCAR Research Applications Lab
  
• Bruce Wright of the British Met Office
• Russ Rew, John Caron, Ethan Davis, Ben Domenico of UCAR Unidata
  

Goals of the telecon:

Ben leading:

Primarily what to do about GALEON & WCSplus at the OGC TC meeting in Stresa?

What role can/should GALEON play in the evolutions of CF conventions?

What clients & servers can experiment with WCS 1.1 should we expend effort?

WCSplus Initiative:

Andrew leading:

Initial discussions started at a "Scientific Feature Types" meeting at Rutherford Appleton and follow up discussion at last OGC TC and Interop Day meeting.  Many GALEON participants having difficulty implementing WCS 1.1 spec.  Very few implementations got very far with 1.1 in contrast with 1.0; 1.1 twice as large a spec in terms of pages; lack of connection to GML; includes much of its own Coordinate Reference System (CRS) definitions.  The overall sense was that WCS 1.0 was pretty good, especially with the GALEON community in spite of the fact that several shortcomings were uncovered in GALEON Phase 1.  The thought underlying WCSplus is: Can we come up with minimal extension of 1.0 to address GALEON problems:

• asynch data access,
  
• multiple "coverages" in single access
  
• irregular grid issues

The concern is that WCS 1.1 is too heavy and complex, 1.2 has too many new things and is moving toward a core and extensions model anyway so it will likely be quite different from 1.1.  We should work toward something closer to 1.0 that’s simple and works and deals within GALEON phase 2 issues.  This may then feed into the WCS 1.2 -- some into the core and perhaps some into extensions needed by the GALEON community.

OGC Architecture Board (OAB) Discussion:

Carl leading:

OAB has a 30 minute discussion last week about issues raised by WCSplus.  Several OAB members have similar concerns with WCS 1.1 functional overloading and complexity; want a core plus extensions approach.

Discussion:

Ben: The intention of WCSplus is NOT to define a competing standard.  It sounds like OAB concerns similar to GALEON and we want to work within the OGC framework to influence the evolution of the standard at least some OAB members are suggesting..

Aaron: The key issue then is: What is the relationship between 1.2 and WCSplus?

Stefano: Aaron has identified the main point, WCSplus group keen on pushing interoperability and another standard would not be useful. WCS+ should try to work to help define the WCS core and to define one or more extension profile(s) within our geosciences realm. First WCS+ should determine what is minimum useful functionality for our community and that determination should go into WCS revision working group (WCS.RWG).

WCS Revision Working Group:

Peter (co-chair of the WCS.RWG) leading:

The position of the WCS WG (or maybe just Peter’s opinion) 1.0 – 1.1 added complexities to make things more exact.  For example,

• a WCS that always returns a black image is 1.0 compliant. 
  
• 1.0 always assumes 2D is (x,y) but may be (x,t)
  

1.2 is working toward a layered approach with a core plus a set of extensions. 1.1.1 and 1.1.2 also include:

• editorial improvements.
  
• 1.2 includes grid coverage definitions,
• minimal 2D coverages,
  
• reduced complexity in cordinate reference systems,
  
• only gray scale images (simple range) extension:
  
• WCS transactions
  
• complex range profile
• trying to harmonize asynch processing

Note that ISO is doing something in parallel for composing dimensions on the fly.

WCS.RWG wants to integrate W3C stuff but needs help because the RWG doesn’t have resources.

On the other hand WCSplus has a goal of a simple interface specification, but at the same time wants:

• inhomegenous range,
• async access,
• irregular grids,

It's not easy to develop a spec that's both simple and powerful.

Discussion:

Andrew: Concern with lack of connection of WCS 1.1 to underlying theoretical ISO coverage standard 19123, all of GML and moving forward toward restricting to 2D in the core.  But nothing in the 19123 coverage spec restricts dimensionality.  It would be better to base WCS on the general 19123. 1.0 used GML but 1.1 did away with that.

Peter: the ISO approach may be so general it can’t be useful and you don’t get n-dimension for free; there is additional complexity.   Satellite imagery servers don’t need more than 2 dimensions.

Oliver:  Based on recent experience implementing WCS 1.1 server,  maybe we should take even a further step back because the fundamental base + extensions approach applies to specs other than WCS.  It doesn't matter whether you  are dealing with a feature or coverage.  The same issues will come up with WFS.  And it is not clear why one should use the bounding box specification rather than the GML envelope.

Stefano: There are so many different kinds of coverage data in different realms.  Any geospatial dataset may be seen as a coverage, so it is very difficult to implement a server for all needs for all coverages. Different disciplines need very specific specialized servers.  ISO 19123 very general and it needs specializations to specific domains.  With WCS+, we are starting  from the needs of a  specific domain and  attempting to extend the basic spec.  Thus far, WCS 1.0 is the currently the only interoperable service in terms of actual experimentation by the geosciences community..

Aaron: WCS+ group should be heavily involved in WCS revision working group.   Otherwise there will be divergence.

Ben: CF conventions arena should be considered too. Hard for any one individual to stay on top of both sides (WCS WG and GALEON/WCS+?).  Perhaps we need to identify specific liaisons?  WCS+  should work on certain minimal needed functionality needed in WCS and feed that into WCS RWG.

Peter : Can we meet at next OGC TC in Stresa?   There are places on the agenda in both the Coverages session and the WCS.RWG session.  Both are on Monday.  Async  access and irregular grids need discussion.

This was followed by a general discussion of who from the WCS+ group would be at the December OGC TC.  There is a conflict for many with the AGU Fall meeting.   Since it appears that no one from WCS+ can be at the TC on Monday, Peter agreed to summarize the GALEON/WCS+ concerns and objectives if we can come up with a concise, coherent summary of the requirements in advance.  Several mechanisms were suggested for constructing such a summary and the group settled on a wiki page as the best approach, but the OGC wiki will not work because it is only accessible to OGC members. Aaron suggested using a UCAR wiki.

Closing Discussion:

John: Intention of WCS+ to explore space by implementing, not competition of two groups on data models and theoretical constructs, contribution is implementation experience.

Peter: Yes, experience implementing is very interesting aspect, need to fee in experience soon, don’t wait until finished implementing.

Ben: Yup, we should be feeding implementation experience continuously.

Summing up: Almost out of time, have beginning of process to deal with issues, putting mechanisms in place to work together.

Post Telecon:

Ben realized (after hanging up) that, if we are going to use a wiki to work collaboratively on a summary of WCS+ requirements, we might as well use the one that's already set up for GALEON

http://galeon-wcs.jot.com/WikiHome

so that's where Ben has started by placing this document there.