GALEON 2 Contributions

Unidata

Server

Upgrade WCS server interface to THREDDS Data Server to WCS 1.1 specification
Target implementation time depends on when WCS 1.1 is formally published

Client

Experiment with Python script clients to exercise specific functions in WCS 1.1 on various WCS 1.1 servers

Jacobs Unviersity Bremen (formerly: International University Bremen)

Server

- continue our WCPS server implementation (WCPS currently has Best Practice status)
- implement a WCS 1.1 server
- evaluate WCS 1.1 and WCPS in remote sensing, oceanographic, and climate modelling contexts
- ...using other partner's clients

Client

develop a WYSIWYG editor for WCPS

University of Florence / CNR-IMAA

WCS 1.1 client and server implementation plan:

We already developed a WCS 1.1 client implementation (as part of GI-go ver. 4.0)
We plan to develop a WCS 1.1 server implementation which supports ncML-Gml documents [by the end of July]

Relationship with SWE:

We are working on harmonizing Obs&Mes and Coverage data models [by the end of June]
We joined the Oceans IE as observers

GML dialects:

We plan to develop a WCS 1.1 server implementation which supports ncML-Gml documents [by the end of July]
We are planning to extend the ncML-Gml [by the end of June]

CSW.ebRIM:

We already developed a CS-W.ebRIM client implementation (GI-go ver. 3.10 and above)
We plan to develop a CS-W.ebRIM server implementation for coverage data [by the end of July]

George Mason University

GMU/CSISS has developed a WCS1.1 server.  It supports netCDF and geoTiff and will soon support HDF and HDF-EOS (both hdf4-based).  At the back end, it takes netCDF data.  We also developed a machine to machine client and will also develop GUI/Web client shortly.

The server url is http://data.laits.gmu.edu/cgi-bin/wcs110?

Request examples can be found at http://data.laits.gmu.edu/pli/reqnote.htm

The server is developed by Dr. Peichuan Li and the client by Dr. Hong Fan.

OSGeo / GDAL

The GDAL WCS client driver was recently upgraded to support WCS 1.1.0.  It is intended that it will be tested with available WCS 1.1.0 servers.  It can support netcdf return results as well as other formats (ie. GeoTIFF?).

Contact: Frank Warmerdam (warmerdam@pobox.com)

Natural Environment Research Council/British Atmospheric Data Center

ITT Visual Information Solutions (formerly RSI)

CadCorp

Washington University St. Louis

NCDC, USNational Climatic Data Center

PFEL, US Pacific Fisheries Environmental Laboratory

Northrop Grumman IT - TASC

Comparison of WCS and SOS

ESRI

Finishing WCS 1.0 client and server support for ArcGIS 9.3. Experimenting with WCS netCDF client and server support.

Alaska Ocean Observing System (AOOS)

Work on adding data sets through WCS 1.0 using UMN Mapserver and use some of the WCS 1.0 clients for testing to bring ourselves up to speed. Update (March 9, 2007): UMN Mapserver WCS server is only capable of serving RASTER type data. We will attempt to get some gridded forecast information available: GFS, FNMOC, WRF and RAMS and follow that up with some satellite data.

Maybe consider a task to upgrading the Mapserver service from 1.0 to 1.1? If this is not possible, maybe consider using Dr. Roberto De Almeida's pyDAP python module to work up a wcs response. The WxS services in UMN Mapserver require C programming. This is a higher threshold of pain over python, so developing a wcs responder in python looks more attractive at present.

One project we have with the pyDAP module is writing a GRIB2 plugin that would expose NCEP model output in a similar fashion as NOMADS/GrADS GDS service. By adding appropriate georeferencing metadata from GRIB2, these datasets should become directly available to WxS via Mapserver. A lot of heavy lifting is done by Jeff Whitaker's grib2.grib2 python module. This should have an initial release in April 2007. Grib2 plugin is nearly complete. Entering documentation phase. Connecting the plugin through Mapserver, we can now render NCEP Grids directly. Snapshots.

For the most part, satellite and model output are stored in their native formats (HDF, HDF/EOS, Netcdf). We modified the OPeNDAP driver in the GDAL library such that adding a couple metadata fields, the datasets became georeferenced and usable by Mapserver. Theoretically, once Mapserver understands the datasets, then the data becomes available in general to all the Mapserver services. However, there are drawbacks to the Mapserver/OPeNDAP arrangement. In general, if a client requests data from a WxS service, the user is ultimately getting data from the OPeNDAP server.

The best way to stay in touch with web services development at AOOS would be to check our wiki page.

AOOS is on the perhiphery of the SWE/SOS work being done with Gerry Creager. We are attempting to follow the progress of this group as it deploys perl, python and java code for delivery of salinity data to a central location. See the SOS Salinity Real-Time Maps and then you can follow links to the OOSTethys site for more information. We would be interested to see how this can tie into other services.

AOOS will also be engaged in projects with NOAA/CSC Data Transport Lab. There could be some overlap and maybe further assistance in testing WCS and other web services/clients? The next project to hit the books is an Observation Registry system which could be constrewed as a catalog or inventory system of sorts. Whether this can have impact on WCPS in the future. It may be worth dropping a note to Daniel Martin at NOAA.

WxS: Reference to various web services (WMS, WFS, WCS, etc) OPeNDAP: http://www.opendap.org/