Figure 1: Typical GIS rendering of "features" projected onto map surface of the Earth
(Image courtesy Tiger 2000 Map Service)
Ben Domenico
Last modified:
February 21, 2006
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.
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 differental 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 show 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, indeed, 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 FIS 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 it's the need is for a flow of data 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://my.unidata.ucar.edu/content/projects/THREDDS/OGC/WCS-THREDDS%20Gateway.htm.
The primary objectives of this IE will be to determine whether:
These use cases are show schematically in the component diagram below.
Figure 5: Component Diagram for Initial GALEON Use Cases
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 Implemenation and Progress Page: http://galeon-wcs.jot.com/WikiHome/Implementation%20Progress%20Page. The following sections list the GALEON client and server implementations.
WCS Gatway to THREDDS Data Server: see http://motherlode.ucar.edu:8080/thredds/docs/WCS/index.html, especially "Notes for Clients."
WCS 1.0 server (WCS-G) capable of serving (subsets of) netCDF-CF datasets, in binary netCDF format as well as in ncML-GML. The server is based on an underlying OPeNDAP server instance and on the ncML-GML Java API, performing the conversion from netCDF-CF to ncML-GML. See: http://athena.pin.unifi.it:8080/galeon/ and for the SOAP binding WSDLs URL: http://athena.pin.unifi.it:8080/galeon/services.
IUB is researching on geo services for large multidimensional rater data, based on the rasdaman raster server which maintains n-D raster data in standard relational databases and gives access via rasql, a raster-extended SQL. In GALEON, IUB will set up a 4-D/5-D database using rasdaman and the open source DBMS PostgreSQL to serve climate data via WCS 1.0, using data imported into PostgreSQL from netCDF files.
RSI have implemented a netCDF to GeoTiff conversion interface using the Java netCDF libraries. The atmospheric levels (z-levels) of the data are represented by the bands of the GeoTiff data. There is a tutorial on
http://mapserver.gis.umn.edu
/docs/howto/WCSServerFormatHow To describing how to serve temporal ranges of netCDF data using MapServer WCS.
A NWGISS WCS server which can generate netCDF CF-1 output is now available at:
In planning stages. Oceanographic datasets will be distributed via the POET data server at PO.DAAC
Java/Webstart implementation of a WCS 1.0 client (WCS Browser Lite), mainly to test our WCS-G server prototype (see above). WCS Browser Lite features include: SOAP and HTTP bindings support, netCDF and ncML-GML format support. URL: http://zeus.pin.unifi.it/projects/wcsClientLite/
GDET is a pure IDL Web Coverage Service client, support the operations getCapabilities, describeCoverage, and getCoverage.
RSI Boulder (Louie Genduso) is testing a second RSI WCS client. A draft report of experiences with that client is given at: http://www.unidata.ucar.edu/projects/THREDDS/GALEON/Reports/GALEONReportRSIboulder.htm
SIS (Spatial Information System) is a WCS client, using GDAL (www.gdal.org) for processing returned netCDF and other raster results.
NERC (Natural Environment Research Council)
British Atmospheric Data Centre - implemented basic Mapserver WCS, with NetCDF converted to GMT grid format prior to serving. Tested successfully with RSI and CadCorp's WCS clients. Available to test GALEON implementations. Also developing WCS interfaces to netCDF as part of a project to deliver environmental web services (www.dews.org.uk).
test client
WMS client to WCS services
Integrated Data Viewer (IDV): when resources allow WCS interface development.
test client
MyWorld. Participating initially as an observer, but would like to implement Java MyWorld as WCS client if resources can be found.
Plan to test netCDF capability via WCS interface
Currently "Observer" Plan to implement a WCS server using Mapserver shortly, probably serving Level II radar data from a selected group of sites.
An impressive group of organizations and individuals is participating in GALEON at various levels.
The status of individual client/server interaction experiments is too detailed for this summary report, but is provided in the GALEON reports of participants.
The following reports were added after the original report was submitted on February 13, 2006 (to satisfy the 3-week rule for the March 2006 OGC Technical Committee meetings. The assumption here is that these are being accepted as modifications to the Phase 1 Report based on information provided during the comment period.
In addition to the results of WCS Client/Server interaction experiments, some of the most important outcomes of GALEON are recommendations to modify OGC interface specifications. Several such recommendations have already been made by Prof. Peter Baumann of the IUB as a result of their GALEON experiences:
Some of the other recommended interfacd specification changes were embedded in the more general status reports, so they are repeated here:
Another simple but significant recommendation will be made to include netCDF as an additional item in the list of WCS format specifications:
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 Interoperabilility Experiment and, in all likelyhood, 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.