Presentation

Download Report

Transcript Presentation

®
OGC Web Services Initiative,
Phase 9 (OWS-9):
Innovations Thread - OPeNDAP
James Gallagher and Nathan Potter, OPeNDAP
© 2012 Open Geospatial Consortium
Goals
• Compare WCS 2.0 and DAP 2.0
• Investigate using OPeNDAP’s Hyrax data server
as a backend for WCS 2.0 by…
• evaluate the effort in upgrading an existing
server from WCS 1.x to 2.0
• evaluating the complexity of supporting
several of the formats commonly used with
GIS systems.
WCS and DAP: data models
• DAP (Data Access Protocol) supports a domainneutral data model, both for data and metadata
• This enables it to serve as a transport for many
kinds of information and…
• data that use many different metadata
standards/conventions.
• Subsetting takes place using common
programming operations like choosing array
slices, structure fields, and so on
… data models
• WCS uses a domain-aware data model and
interface
• It provides an integrated way to describe
(metadata) coverages (data) and…
• subset them in the geospatial and temporal
domains
• It also provides range subsetting operations
Hyrax (DAP) as a backend for WCS
• A DAP server (e.g., Hyrax, TDS) makes a good backend for WCS
• It provides a subsetting interface that abstracts many different ad hoc
data stores
• The WCS service can focus on mapping between the WCS data model and
the DAP data model
• The DAP server can provide uniform access to many different data
formats
Does the DAP data model provide
useful abstractions for a WCS service?
• Adding support for new response formats was
straightforward.
• Reading new data (source) formats was
similarly easy
• Since each format was accessed uniformly
using DAP, the WCS service required no
change for the new source formats and
minimal changes for the new response
formats.
Modular BES Processing Plans
What was coded in the WCS Service?
• The metadata information in the data sources
is not abstracted by DAP, instead it is adapted
to a common representation but the content
is not altered at all.
• The WCS service had to be coded for the
specific metadata standards and conventions
used by the underlying data sources
WCS 1.x  2.0
• Substantially different XML meant that we had
to rework the software that (automatically)
builds WCS XML
• The WCS 2.0 XML schema set is much easier
to use than the 1.x XML; it validates and is
better organized
• Heavy reliance on GML does not reduce the
number of distinct specifications that must be
read, however!
Issues in serving science data
• Phrases like ‘Science data’ oversimplify…
• However, many scientific data sets for multiinstrument platforms use complex hierarchical
formats like HDF5 or NetCDF4
• Files in these formats often hold tens or
hundreds of variables
• Meanwhile, widely-supported WCS response
formats are typically limited to a single or
small number of ‘variables’ (aka ‘fields’)
…and not all science data is
georeferenced and projected
• This is true even for ‘Earth science data’
• In OWS-9 NASA provided a collection of data
sets that were in ‘satellite’ coordinates and
had to be projected by the WCS.
• Note that WCS supports coverages that could
be used to represent these data, but clients
would be hard pressed to make use of them.
Summary
• WCS 2.0 and DAP 2.0 differ in some key ways that
make them complementary
• DAP servers provide good interfaces to data for
WCS service implementations
• In this project, support for new data formats was
abstracted almost completely by the DAP server
• However, metadata standards/conventions,
however, were not abstracted by DAP
• Some response formats for WCS require complex
transformations for some kinds of data