Ben Domenico
Last modified:
May 21, 2009
This is an abbreviated version of the full GALEON Phase 1 Report submitted at the time of the March OGC Technical Committee meeting in Huntsville. The general descriptions have been left in the report for those not familiar with GALEON, but readers are encouraged to go to the full GALEON Phase 1 Summary Report (http://www.unidata.ucar.edu/projects/THREDDS/GALEON/Reports/GALEONphase1Report.htm) for details and for pointers to sub-reports of the individual participants.
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 traditional "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.
In general (and oversimplified) terms, the GIS community thinks of the datasets as collections of static features (e.g., roads, lakes, plots of land) with geographic footprints on the Earth's surface. The features are discrete objects with attributes which can be stored and manipulated conveniently in a database. Examples of data types in Earth sciences related GIS data collections are:
A typical example of a GIS-rendered map is shown below. It' easy to see how the items in the legend can be stored as table in a relational database system and rendered as "layers" on a map.
Figure 1: Typical GIS rendering of "features" projected onto map surface of the Earth
(Image courtesy Tiger 2000 Map Service)
To the FES community, the world is characterized by a set of parameters (e.g., pressure, temperature, wind speed) which vary as continuous functions in 3-dimensional space and time. The behavior of the parameters in space and time is governed by a set of partial differential equations. Data are simply discrete points in the mathematical function space. Examples of common data types in Earth sciences data collections related to the fluid Earth are:
An animated visualization of the output of a numerical weather forecast model is shown in the following figure. It illustrates the true multidimensionality of the dataset with the jet stream rendered as a "solid" time-varying object in 3 spatial dimensions. In addition, other variables such as temperature (at a given level) and pressure are shown as a surface and line contours in both vertical and horizontal cross-sections. The map background in this particular image was actually generated from GIS shapefiles.
Integrated visualization is one of the first things that comes to mind as a reason for making the data systems interoperable. And, it is important to be able to view the disparate datasets from within the same package. Indeed much progress is already being made in terms of being able to create integrated overlays of datasets from the two realms. However, there are other crucial capabilities in GIS and FES tools that are just as important. Because of the underlying data model that facilitates the solutions to the equations of fluid dynamics, numerical forecasting tools are a strength in the FES realm. So predicting the path of severe storms is routine. On the other hand, the underlying databases in GIS facilitate responses to queries relating to overlap among various types of georeferenced features. Thus, if the predicted path of a storm can be characterized in GIS terms, GIS tools can readily determine how many people live in the area and what infrastructure is likely to be affected. That's not to say that the need is for a data flow only in the one direction
Figure 3: Schematic of GIS-FES Inteoperability via Standard Interfaces
The overall GALEON target is this general goal of interoperability via standards-based web services interfaces. But there is one rather more specific objective that involves using these interfaces as the basis for a gateway between traditional GIS applications and datasets available in existing servers in the FES community. These servers which number in the hundreds are based on a set of client-server protocols that have evolved in the FES community over the last decade. The basic building blocks are netCDF, OPeNDAP, ADDE, and THREDDS technologies. But there are other services built on these, for example LAS, GDS, and INGRID. There are already several hundred of these servers making a wide-variety and large volume of data available to existing client applications. So a key aim of GALEON is to expand the usefulness of these servers by adding a standards-based interface to provide a gateway so that WCS clients can access the datasets.
The diagram below is a schematic of this gateway implementation as it was envisioned at the time GALEON was initiated. Since that time, development work has integrated the underlying THREDDS/OPenDAP services into a package called the THREDDS Data Server (TDS) which has a rudimentary WCS interface built in.
Figure 4: Initial Concept of WCS-interface as a Gateway to Existing FES Services
It is important to recognize that the gateway described above is not the sole objective of GALEON by any means. In fact, many of the most interesting and potentially most productive ideas have come up since GALEON was formally proposed. Some of these found their way into the initial use cases, some have been undertaken as the IE progressed, and other are just now being formulated. Not all of these augmentations will be described in this report which focuses on GALEON Phase 1, but some will be covered in the accompanying reports from participants and the remainder will be articulated in the Phase 2 Description which is yet to be described in any detail.
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://www.unidata.ucar.edu/projects/THREDDS/OGC/WCS-THREDDS%20Gateway.htm.
More detailed information about specific tasks and objectives are given in the full GALEON Phase 1 Summary Report (http://www.unidata.ucar.edu/projects/THREDDS/GALEON/Reports/GALEONphase1Report.htm)
Most of the activity of the first phase of GALEON has focused on testing the interactions between WCS clients and servers for netCDF datasets, modifying those client and server implementations based on the testing, and recommending modifications and augmentations of the relevant OGC interfaces where appropriate. The status of these implementation is described on the GALEON wiki Implementation and Progress Page: http://galeon-wcs.jot.com/WikiHome/Implementation%20Progress%20Page. The following sections list the GALEON client and server implementations.
More detailed information about specific tasks and objectives are given in the full GALEON Phase 1 Summary Report (http://www.unidata.ucar.edu/projects/THREDDS/GALEON/Reports/GALEONphase1Report.htm)
An impressive group of organizations and individuals is participating in GALEON at various levels.
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)
The GALEON experiments have resulted in many recommendations to OGC interface specifications. These are mainly to the 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-GMS 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 for a netCDF is under development.
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)
As the report indicates, GALEON Phase 1 has been very successful in bringing together an international team of experts in the field who are now working together to improve the standard specification and implement those specifications in client and server applications which will benefit the communities trying to integrated the tools and data systems of the GIS and FES communities. But some of these collaborations have gone beyond that and resulted in proposals for funding to work on the implementations. In particular:
Other possible joint proposals are being discussed as a result of GALEON collaborations, but none is far enough along to warrant mentioning here.
Many key GALEON efforts are just now getting underway and others are planned for the near future, so GALEON will continue with a Phase 2 Interoperability Experiment and, in all likelihood, as a GALEON OGC Network as well. Among the objectives of GALEON Phase 2 will be:
It is anticipated that Phase 2 GALEON will last a year, but that interim status reports and interface specification recommendation will be filed.