ESDS Program

Lessons Learned Regarding WCS Server Design and Implementation


This document provides lessons learned regarding a Web Coverage Service (WCS) server implementation for the Coordinated Energy and Water Cycle Observations Project (CEOP) Satellite Data Server, a NASA Advancing Collaborative Connections for Earth System Science (ACCESS) project that provides a gateway between the Open-source Project for a Network Data Access Protocol (OPeNDAP) and WCS protocols. The gateway allows a user to use an OPeNDAP-enabled client to access satellite data held at a WCS server with services such as subsetting, reprojection, mosaicking and time series support. This Technical Note presents several challenges encountered in the design and implementation of the WCS server, mostly arising from user access patterns, as well as the approaches taken to address those challenges.



This document has been deprecated and is for informational purposes only.

The Lessons Learned Regarding WCS Server Design and Implementation was recommended for informational use as lessons learned March 2009.

NASA Earth Science Community Recommendations for Use


Interoperability prototypes such as those described in this technical note are of fundamental importance in helping developers and system architects understand the issues involved in bridging related science domains both in terms of protocols as well as information schemata. Users cite the following uses for this technical note:

“…they each provide great information to help investigation of these described services.”
“These tech notes were informative to me and boosted my confidence in discoveries I had made regarding these services.”
“This document describes a useful scenario to bridge Earth science community standards with OGC standards and combine CS/W and WCS together”
“RFC 16 not only gives developers guidance on some issues to be faced when implementing WCS servers, but also raises some thoughts on [the] OGC WCS specification.”


Ideally, developers would have liked to have source code and schema mapping files to work with, however as the prototypes described in this technical note were not billed as open-source, the issue of code sharing was not applicable.


As already mentioned, this technical note not only aids developers who may be either in the process of developing similar gateways or contemplating developing them, understand the issues involved, but also help information architects and specification implementers “measure the maturity and shortcomings of standards”.

NASA centers that have data to share are looking at alternate ways to serve up their data holdings and one way to do this is via application gateways and protocol translators such as those described in these technical notes, to make them available seamlessly, with a wide variety of clients.


The TWG realized that reviewers would request that some of the shortcomings in the underlying standards on which the prototypes were built, be fed back to the standards body, i.e., OGC. While the RFC authors did indeed itemize these issues and suggest alternate implementation approaches, recommending changes to an existing standard, published by a standards body is currently limited to information exchange only. Ensuring that the changes are incorporated into these standards is currently outside the scope of the SPG—this is a limitation of the SPG process and should not be construed as a limitation of the submitted RFC.

Last Updated