Interoperability between OGC CS/W and WCS Protocols
This document presents lessons related to Open Geospatial Consortium (OGC) protocols that were learned in the course of developing the OGC-Geoscience Gateway. The OGC-Geoscience Gateway is a NASA ACCESS project that provides a gateway between the OGC protocols and technologies widely used within the geosciences community, in this case THREDDS. The gateway allows a user to query a THREDDS catalog using the OGC CS/W protocol, making THREDDS-served data accessible to CS/W-aware GIS clients. Since THREDDS provides OGC WCS access, our end goal was to search THREDDS catalogs for WCS coverages in a GIS Client that could then seamlessly acquire the WCS coverage for display. Although this goal was only partially realized, several valuable lessons were learned with respect to CS/W interoperability, particularly with its sibling WCS protocol. We hope these lessons will be useful to OGC client developers, as well as OGC interoperability architects.
The ESDS-RFC-014 Technical Working Group (TWG) has conducted a review of
ESDS-RFC-014 - Interoperability between OGC CS/W and WCS Protocols
with the following conclusion:
That the Standards Process Group should endorse ESDS-RFC-014 as a Technical Note.
The TWG bases its recommendation on an analysis of the following factors in a NASA context.
Strengths: 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 these technical notes:
“…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”
Weaknesses: 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.
Applicability: 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 this technical note, to make these data available seamlessly, with a wide variety of clients.
Limitations: 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.
ESDS-RFC-014 was submitted by Chris Lynnes from NASA GSFC as a NASA Standards Process Group (SPG) Technical Note. A technical note, in SPG parlance is a document that contains useful information but is not a "standard". Technical notes must be relevant to the domain of NASA Earth Science data systems, serve a useful purpose, be technically of high quality, be well written and undergo a process of review from relevant stakeholder communities to prove their relevance.
The technical note describes an implementation approach and associated issues with achieving interoperability between protocols commonly used in the GIS community (CS/W and WCS) and those used in the geo-sciences domain (THREDDS and OPeNDAP).
The ESDS-RFC-014 TWG conducted a Technical Review designed to determine the technical validity of this technical note within a NASA context. The review of the technical note was completed over a period of approximately 8 months. An initial review by the members of the pre-TWG resulted in comments that addressed minor issues with the document along with suggestions to make some concepts clearer. This feedback was provided to the RFC author, and the documents were updated to incorporate this feedback. Revised documents were then sent out to the wider SPG community, via the spg-announce e-mail list, along with a review questionnaire, to elicit feedback in evaluating their relevance and usefulness.
The reviews received were positive, and stressed the need for the SPG to publish more of these ‘lessons learned’ type technical notes.
The functionality of ESDS-RFC-014 - Interoperability between OGC CS/W and WCS Protocols is described in the excerpt below:
This technical note describes a prototype implementation of a catalog gateway called the OGC-Geoscience Gateway that mediates client/server interactions between OGC catalog clients and THREDDS servers. The gateway allows a user to query a THREDDS catalog using the OGC CS/W protocol, thus making THREDDS-served data accessible to CS/W aware GIS clients. Since THREDDS provides OGC WCS access, the end goal was to search THREDDS catalogs for WCS coverages in a GIS Client that could then seamlessly acquire the WCS coverage for display.
CS/W provides catalog services for clients to find needed data and data-related services. The CS/W server is compliant with the OpenGIS Catalog Services Specification 2.0.2 -ISO Metadata Application Profile. It specifies an application profile for ISO 19115/ISO 19119 metadata with support for XML encoding per ISO/TS19139 and HyperText Transfer Protocol (HTTP) binding.
The Ingesting component of the OGC-Geoscience Gateway is itself a THREDDS client: it sends a request to a THREDDS server and hands the response off to the Parsing component. The Parsing component is responsible for parsing the catalog content. If a catalogRef element is found in the catalog document, a new catalog XML URL reference is generated, which is handed back to the Ingesting component, triggering a recursive request to the server for the corresponding new catalog XML document. Dataset elements are passed to the Mapping component which translates the metadata from the schema of the THREDDS InvCatalog Markup Language (describing THREDDS inventory) to the schema that compliant with ISO 19115. Finally, the Registration component registers the metadata it into the CS/W database.
The CS/W server provides either real-time or pre-stored THREDDS catalog information to the clients, using the following proceess:
- The ingestor ingests THREDDS catalog information into the CS/W server on a preconfigured schedule (or on demand, as required).
- The server receives a valid CS/W request from a CS/W client.
- The server searches the CS/W database which has been pre-populated with ingested THREDDS catalog information.
- The server sends the translated response to the requesting CS/W client.
Lessons learned with respect to CS/W interoperability, particularly with its sibling WCS protocol are described and these lessons learned may be useful to OGC client developers, as well as OGC interoperability architects.