Washington University, CAPITA, Dec 6, 2005 , rhusar@me.wustl.edu
This is progress report on THREDDS/ WCS-DataFed interoperability. The DataFed client can access the WCS data sets from the U. Florence and from the UNIDATA THREDDS WCS test servers.
U. Florence WCS server: sst(time-lat-lon
http://athena.pin.unifi.it
UNIDATA WCS server: TREDDS_CDM dataset
The spatial queries that return spatial grids to both servers yield expected return. Within DataFed, the received WCS (NetCDF) data from both servers, is easily transformed into data views and used in distributed web applications by chaining appropriate web services.
Our enthusiasm is tempered by the fact that substantial hurdles are still ahead of us before we reach (our) desired level of interoperability.
- the temporal aspects of the WCS queries needs more work both on server and client side
- we have not yet tested 3-4D datasets with Elevation and Forecast time dimensions with the WCS protocol (e.g. ETA model )
- automatic (loosely coupled) registration of WCS services in to the DataFed catalog needs work (using ncML-GML ?)
- we are in need of geo-re-projection services (preferably web services) to make may of the grids usable for us
We recognize that many of the current inadequacies are due to our own limited understanding of the current sate of affairs. We are looking forward pursuing these and related issues as part of this IE or through alternative venues.
This progress report contains the finding on interoperability between the GALEON WCS test servers and the DataFed WCS client. The GALEON Interoperability Experiment (Geo-interface to Atmosphere, Land, Earth, Ocean netCDF). GALEON aims to aid the data flow between GIS and Earth Science communities. I is a joint initiative between UNIDATA, OGC and involves an international group of collaborating institutions.
This brief report was prepared by the Center for Air Pollution Impact and Trend Analysis (CAPITA) group:
Stefan Falke who pursued the general WMS/WFC/ WCS client-server connectivity
Kari Koijarvi the programmer/ implementer of the WCS client services and
Rudy Husar, who's primarily interest is in the access and applications of the THREDDS datasets for air quality analysis.
We see this IE as an opportunity to advance air quality research by accessing the rich virtual data holdings brokered through THREDDS. At the same time this IE can advance the interoperability of Earth Science data systems, which is a specific goal of our NSF ITR grant (Final) , the 2004-09 NASA REASoN grant and related projects. Finally, on a more personal level, we are eager to interact with a group with whom we share a belief... ...
From the point of view of the GALEON IE, DataFed is a client of Earth Science datasets presented through the THREDDS delivery system using the OGC Web Coverage Service (WCS) protocol. DataFed itself is an application framework for accessing, processing and browsing distributed datasets using loosely coupled web service components. Within DataFed, the interface to distributed data is through data wrappers, which deal with the dataset-specific physical data access. The the subsequent data access services use the wrappers and
(1) impose a semantically homogeneous global multi-dimensional data model (e.g. lat-lon-datetime-elevation) and
(2) turn all data into strongly typed SOAP services, that can be loosely coupled to downstream services.
Along the processing chain, intermediate data can be extracted, transformed to other formats and delivered as services (SOAP, WCS, WMS, other forms of REST etc) to other consumers. Ideally, a subset of the air quality-related datasets mediated through DataFed could/should(?) be registered in and accessible through the THREDDS Catalog (Ideas?).
In the DataFed framework, web-applications are created in two stages:
1. First, specific data views (e.g. MapView, TimeView) are created by chaining web services (e.g. DataAccess, Process, Render, Ovelay, Annotate etc.)
2. The views are then embedded in a web page which provides the frame, controllers and the glue code that links controllers to the chained services
The main web app of DataFed is the generic Viewer of spatio-temporal datasets. Since all datasets registered in DataFed follow a global multidimensional data model, the same viewer can be used for all the federated datasets in DataFed. Further on DataFed General Description, Mediation and Architecture.
The easiest way to explain the WCS data consumption is by showing the two datasets through the Data Viewer
http://webapps.datafed.net/dvoy_services/datafed.aspx?dataset_abbr=SeaTemp_OL
The data navigation is by clicking on the desired grid location or time.
Note that the form of the queries for map and time views are identical. The difference is in the shape of the requested data cubes:
Map View: TIME=2001-01-01T00:00:00Z
Time View: TIME=2001-08-01T00:00:00Z
Sub-cube: TIME=2001-08-01T00:00:00Z
So, as long as the WCS servers recognize 'point' queries, time-lat-lon datacubes can be meaningfully queried. We appreciate that the Florence server responds like that.
The THREDDS WCS server data can be viewed through the generic DataFed browser as
http://webapps.datafed.net/dvoy_services/datafed.aspx?dataset_abbr=THREDDS_CDM
Example WCS getCoverage query from the THREDDS server for map view
This returns a NetCDF file, which is translated to GML and rendered as shaded grid.
The THREDDS server does not respond to WCS queries with a time range or point BBOX, hence we could not create the Time View. Time navigation is still possible changing the DateTime and clicking on GO button. Also, note that the list of parameters (variables) is derived from the getCapability and GetDescription queries (but not yet automatically). The multiple data layers is THREDSS_CDM can be browsed through the Analysts Console web-application. The app renders a user-selectable set of 'Views' and facilitates time and spatial zoom navigation, image size and other settings.
