GALEON Status Update

Ben Domenico
Last modified: June 26, 2007

Overall Objectives

The OGC (Open Geospatial Consortium) GALEON IE(Geo-interface for Air, Land, Earth, Oceans NetCDF Interoperability Experiment) has expanded its objectives considerably beyond its initial, focused set of goals. However, the overall mission remains the same: specify and use standard interfaces to foster interoperability between data systems used by the traditional GIS community and those in community we refer to as the fluid Earth systems (FES, mainly oceanography and atmospheric science). This strategic target is becoming increasingly important as FES observations and forecasts are achieving the high spatial resolutions (a few kilometers and better) of the GIS realm. The challenge is to enable the practitioners in each realm to continue using the powerful tools available through their traditial "stovepipe" applications while allowing for integration of data and applications between the two realms by developing and employing standard, web services-based interfaces between the two.

An Overview of GALEON is also available atl:

http://www.unidata.ucar.edu/projects/THREDDS/GALEON/Reports/GALEONoverview.htm

Phase 1 Accomplishments

The GALEON Phase 1 Team

Client/Server Interaction Experiments

The many experiments between independently-developed client and server implemetations showed that the WCS protocol does indeed have the basic functionality needed to enable access to traditional netCDF datasets. Pointers to individual GALEON experiments are given in the full GALEON Phase 1 Summary Report (http://www.unidata.ucar.edu/projects/THREDDS/GALEON/Reports/GALEONphase1Report.htm)

Recommended Modifications to OGC Interface Specifications

The GALEON experiments have resulted in many recommendations to OGC interface specifications. These are mainly to the Web Coverage Service (WCS) specification where they have for the most part been folded into the recommended changes for WCS 1.1. There is work still underway on key "applications schemas" related to the GML (Geography Markup Language) specification based on the work on ncML-GML at the University of Florence and work on the CSML (Climate Sciences Modeling Language) at the British Atmospheric Data Center. However, one of the most important proposed modifications would be to do away with the list of 5 WCS encoding formats and replacing it with a requirement that WCS encoding formats be documented with a "profile" document that provides enough information for a third party developing a WCS client or server to know how to work with the dataset in that format. Such a WCS profile has been developed for netCDF.

In summary, the GALEON-related changes in WCS 1.1 are:

Pointers to documents describing recommended modifications to OGC interface specifications are given in the full GALEON Phase 1 Summary Report (http://www.unidata.ucar.edu/projects/THREDDS/GALEON/Reports/GALEONphase1Report.htm)

GALEON Phase 2 Issues

Participants have suggested a number of issues to be addressed in the second phase of GALEON.  These can be divided into two broad categories.  The first has to do with testing the new WCS 1.1 specification; the second has to do with relationships among WCS and other OGC and ISO specifications such as CSW, WFS, SWE, and a number of GML profiles that have arisen recently.

  1. Is WCS 1.1 adequate for serving netCDF datasets such as those on the servers at Unidata, the University of Florence, George Mason University, NERC, NCDC, and the PFEL?

    • The main task is to implement and test clients and servers that conform to the new WCS 1.1 spec and experiment with them on a wide range of real-world datasets. From the GALEON perspective, some of the important changes in WCS 1.1 are:

      • multiple fields in a coverage
      • 3 spatial dimensions
      • 2 time dimensions (e.g., the time a forecast was run and the forecast times within the run)
      • relative time ( e.g., the latest image, the last 5 images, ...)
      • non-spatial dimension (e.g., pressure or density)
      • irregular grids

    • It will also be important to test a wide variety of data types. Phase 1 focused on "5D" grid datasets of the sort that are generated by weather and climate forecast models. Phase 2 will include other data types:

      • point or "station" observations
      • vertical profile and trajectory datasets
      • swath data from polar orbiting satellites
      • radial data from radar stations

    • Other investigations in fact address questionable areas in the CF-netCDF encoding:

      • Documentation for the Coordinate Reference System
      • Representation of point (station) data in CF-netCDF
      • Common Data Model (CDM) augmentation of netCDF data model

  2. In the context of serving traditional netCDF datasets, what's the relationship between WCS and other standard specifications?

    • Is the CSW interface adequate for cataloging the collections of data in question 1 above and how do clients interact with both WCS and CSW?

      • Catalogs and/or WCS getCapabilities lists?
        The getCapabilities request appears to be inadequate to return a list of all the coverages on a WCS server.
      • Several people have suggested that GALEON Phase 2 include experiments that involve CS-W (Catalog Services for the Web) as well as WCS.

    • For collections of point data time series (e.g., observations from weather stations, ocean buoys, river gages), what role to WCS, WFS, and SWE/SOS play?

    • What are the roles of GML dialects (ncML-GML, CSML, GMLJP2) in the context of the GALEON WCS experiments?

      There appears to be an accelerating trend to develop new XML schemas for many subdisciplines in the geosciences. Even within the world of GML, many profiles are evolving. Within the GALEON team discussions, at least 3 have come up in the context of methods for characterizing CF-netCDF characteristics in a standard form:

      • ncML-GML
      • CSML
      • GMLJP2

    • A Change Request to OWS Common is under way, emanating from WCS, to extend the coverage model with non-spatiotemporal axes, and also to allow coverages not having x and y axes simultaneously (e.g., to have x/t slices). How does that affect the GALEON applications (and what are their requirements in this respect)?

Expanded Team

Additional organizations are planning to participate more actively in the GALEON phase 2.

GALEON 2 Update

Implementation of WCS 1.1 clients and servers has been slower than expected. However, the University of Florence team reports success using their WCS 1.1 client called GI-GO to access catalogs and datasets on a WCS 1.1 data server at George Mason University.

In addition, several new types of datasets have been recently made available via the WCS interface on THREDDS Data Servers (although the TDS is still WCS 1.0):