GALEON IE Gateway Activity Plan

Activity Plan for the
Gateway Implementations of the
GALEON Interoperability Experiment

Title: Open Geospatial Consortium Interoperability Experiment:
“Geo-interface for Atmosphere, Land, Earth, and Ocean netCDF”

Abbreviation: GALEON IE

Last Modified: September 18, 2005

Participant ORGANIZATIONS

The following organizations will be participating in the GALEON IE. Note that not all participants need to implement full clients or servers. Some will exercise the newer aspects of the protocol; others will implement clients to determine whether the new types of dataset can be accessed, analyzed and displayed appropriately; others will provide input on improvement of the proposed NcML-GML and netCDF encoding formats.

Since the initial discussions of GALEON at the New York meeting of the OGC Technical Committee, what has evolved is a combination of the formal OGC GALEON Interoperability Experiment along with several specific implementation projects. The formal OGC IE has to be conducted by OGC members, but the implementations can involve additional organizations. Thus, for example, the WCS gateway to underlying OPeNDAP/THREDDS/netCDF technology may involve organizations that are not part of the OGC IE but will play an active role in testing the implementation in real world settings. Likewise the component of the experiment relating to WCS implmentations via database technology may also involve groups that are not part of the formal OGC experiment.

OGC Member Participants

The following organizations have expressed an interest in participating in the IE at some level. Some may submit letters of support and become full participants and others observers. A few of them have already been involved in the practical matters of creating client and server implementations.

• Unidata/UCAR (Ben Domenico, John Caron)
• IMAA-CNR (Stefano Nativi, Lorezo Bigagli)
• George Mason University (Liping DI, Wenli Yang)
• NASA Geospatial Interoperability Office (Richard Uhlmann, John Evans)
• CadCorp (Martin Daly, Frank Warmerdam)
• University of Alabama Huntsville (Mike Botts)
• Jet Propulsion Laboratory (Rob Raskin)
• University of Florence (Stefano Nativi, Lorenzo Bigagli)
• Interactive Instruments (Clemens Portele)
• ESRI, Inc (Simon Evans, Steve Kopp)
• University of Applied Sciences (Ralf Denzer)
• International University Bremen (Peter Baumann)
• NERC/CCLRC (Dominic Lowe, Andrew Wollf)
• Texas A&M University (Gerry Creager)
• Research Systems International UK Ltd (David Burridge, Norman Barker)

Other Participants

 

• University of Rhode Island (OPeNDAP group)
• Pacific Marine Environment Laboratory (PMEL)
• Center for Land, Ocean, Atmosphere (COLA)
• Marine Metadata Initiative lead by MBARI (Monterey Bay Aquarium Research Institute)
• GODAE (Global Ocean Data Assimilation Experiment) led by FNMOC (Fleet Numerical Meteorological and Oceanographic Center)
• Many current THREDDS/OPeNDAP server sites

DESCRIPTION

This WCS Interoperability Experiment (IE) will implement a geo-interface to netCDF datasets via the WCS 1.0 protocol specification. It will implement the WCS as a layer above a set of client/server and catalog protocols already widely in use in the atmospheric and oceanographic sciences communities. In particular, it will leverage the widespread base of OPeNDAP servers that provide access to netCDF datasets and accompanying THREDDS servers providing ancillary information about the datasets. The IE will investigate the feasibility of adapting data and metadata originating from OPeNDAP/THREDDS servers to the WCS specifications, in so contributing to bridge the gap between the atmospheric, oceanographic and GIS communities, by alleviating data interoperability issues.

The initial experiments will deliver collections of numerical forecast model output which consist of what are sometime referred to as five dimensional or 5D grids (multiple parameters (e.g., temperature, pressure, relative humidity) varying in three spatial dimensions with two time coordinates (model run time and forecast time). It is important to note that, while it is convenient to refer to these as 5D datasets, the 3 spatial dimensions and temporal dimensions are fundamentally different in that they are part of the domain whereas the multiple parameters are part of the range in the WCS data models and interface specifications.

This IE can be seen as a step in the direction of interoperability with data systems already in existence in the oceanographic and atmospheric sciences. These technologies include netCDF, OPeNDAP, ADDE, and THREDDS. An outline of the integration path is given in:

http://my.unidata.ucar.edu/content/projects/THREDDS/OGC/WCS-THREDDS%20Gateway.htm.

The primary objectives of this IE will be to determine whether:

1. a viable WCS getCapabilities geo-interface (gateway in earlier versions) can be built on existing THREDDS inventory catalog services
2. the ncML-G data model is adequate for providing describeCoverage responses for netCDF datasets
3. there are any solutions to the previously identified limitations to geoTIFF encoding format for representing from 5D netCDF files in such a way that the relationships among layers is preserved
4. the proposed ncML-GML encoding format is a practical solution to serving 5D data from netCDF files, either embedded (ASCII or attached binary) or linked (OPeNDAP link or other URL)
5. netCDF itself is a viable WCS binary encoding format
6. existing WCS clients are able to access analyze and display 5D data from netCDF files
7. 5D geospatial data sets can be served efficiently through standard database technology

Each objective will have a use case associated with it.

If the experiment determines the WCS specification is not adequate to support this geo-interface functionality, recommendations will be made to improve and extend the specification.

The use cases to be undertaken in the experiment are:

• Use Case #1: WCS getCapabilities based on THREDDS inventory list catalogs
• Use Case #2: WCS describeCoverage based on ncML-G data model
• Use Case #3: geoTIFF getCoverage for 5D datasets
• Use Case #4: ncML-GML getCoverage for 5D datasets
• Use Case #5: netCDF getCoverage for 5D datasets
• Use Case #6: WCS clients for 5D datasets
• Use Case #7: WCS database server for 5D datasets

The following schematic diagram shows the primary components of each use case:

GALEON Component Diagram

A detailed description of the ncML-G data model and the ncML-GML encoding are given in:

http://my.unidata.ucar.edu/content/publications/ComputersAndGeosciences2004/nativicompsandgeo04.pdf

TECHNICAL APPROACH

Specification Development

The primary focus of this IE will be on the WCS specification. The aspects involved will include:

• WCS getCapabilities
• WCS describeCoverage
• WCS getCoverage
• ncML-GML dialect of GML

Component Development

The following components will be developed concurrently by the responsible organization(s), to be completed by the execution end date.

* Both HTTP and SOAP-based WCS will be developed and tested. In particular, SOAP message attachments will be utilized. Heavy netCDF datasets will be returned, using either binary encoding (i.e. SOAP attachments) or providing a link (i.e. an OPeNDAP URL a piece of data stored on a disk) to them

Testing and Integration

Documentation

The following documentation will comprise the deliverables for the project:

• GALEON Interoperability Experiment Report (IER)
• Intermediate reports will be generated as each Use Case is implemented.
• If the experiment determines that netCDF should be added to the list of WCS encoding formats, a recommendation to extend the WCS specification will be provided. .

Demonstration

A demonstration of all functioning components will be made towards the end of the IE.

The documentation listed above will be considered the deliverable for the project. It is expected that sub-reports will be received from each of the participants; each report will describe the component(s) for which the participant is responsible, and will specifically outline any issues or problems encountered with the GALEON components. These sub-reports will then be compiled into the final deliverable, the GALEON IER.

RESOURCE PLAN

The Initiative Manager will be Ben Domenico, of Unidata/UCAR. The Initiative Technical Leadership will be shared Stefano Nativi, of the University of Florence and John Caron, of Unidata/UCAR. The Initiative Facilitator will be George Percivall, of OGC.

The following resources will be used by participant companies in testing the GALEON implementation, and thus represent contributions in kind to the encoding interoperability experiment.

In order to become a participant in this IE, an organization must be willing make a resource commitment to make a substantial contribution in one or more of the following areas:

• an implementation of a complete GALEON WCS 1.0 server to test the specifications, OR
• an implementation of a WCS client to test the specifications and new GALEON components, OR
• a netCDF or OPeNDAP client with a WCS protocol implementation, OR
• expertise in the area of WCS,GML, netCDF, OPeNDAP in order to suggest improvements to the specifications and implementation, OR
• creation or compilation of documentation into the final GALEON WCS Interoperability Experiment Report (note: all participants must also provide input on their component of the experiment for inclusion in the final report)

• Is our target WCS 1.0 or WCS 1.1? Or do we start with WCS 1.0 and commit to an effort to implement WCS 1.1 during the experiment?
  The target will be WCS 1.0 for this experiment since WCS 1.1 will be a moving target during GALEON so we will revisit the WCS 1.1 specification when it becomes stable.
  
• Is it appropriate to bring in interested organizations that are not OGC members (e.g., OPeNDAP)?
  What has evolved is a combination of the formal OGC GALEON Interoperability Experiment along with several specific implementation projects. The formal OGC IE has to be conducted by OGC members, but the implementations can involve additional organizations. Thus, for example, the WCS gateway to underlying OPeNDAP/THREDDS/netCDF technology may involve organizations that are not part of the OGC IE but will play an active role in testing the implementation in real world settings.
  
• Logistics:
  • take email addresses out of document?
  • establish a swiki?
  • code exchange mechanism?
    Regarding the code exchange mechanism, the International University of Bremen has made a generous offer to set up a "subversion" system; others have suggested we start with whatever is in place now for code sharing at participant sites and see if we need a common mechanism such the IUB has volunteered. This is an item we can revisit as the experiment evolves.