4-Dimensional Weather Data Cube Web Coverage Service Reference Implementation (WCSRI) Architecture and Design

4-Dimensional Weather Data Cube Web Coverage Service Reference Implementation WCSRI Architecture and Design Version 2.0 01/15/2010 National Center for Atmospheric Research MIT Lincoln La

4-Dimensional Weather Data Cube

Web Coverage Service Reference Implementation

(WCSRI) Architecture and Design

Version 2.0 01/15/2010

National Center for Atmospheric Research

MIT Lincoln Laboratory National Oceanic and Atmospheric Administration/Global Systems Division

DOCUMENT REVISION REGISTER

Version Date Content Changes Editors Contributors

0.1 03/16/2009 Preliminary draft Rob Weingruber

Aaron Braeckel0.2 04/10/2009 Revised to support a system design

template more closely tied to the WFSRI Design and Architecture Document Multiple other content refinements

Aaron Braeckel

1.0 04/30/2009 Updated to be more similar in format

and to include additional relevant content from WFSRI Design and Architecture Document v0.1

Incorporated comments from NNEW

PO and labs

Aaron Braeckel Rob Weingruber

1.1 12/8/2009 Initial draft of 2.0 document changes

Updated to reflect design changes and experience gathered from

implementing WCSRI 1.0, updated to reflect the current status of SWIM, and generally improved wording and content

Aaron Braeckel

2.0 1/15/2010 Finalized revisions from 1.1 Aaron Braeckel

Please direct comments or questions to:

Rob Weingruber

National Center for Atmospheric Research

Research Applications Laboratory

National Center for Atmospheric Research

Research Applications Laboratory

3450 Mitchell Lane

Boulder, CO 80301

braeckel@ucar.edu (303)497-2806

Terms of Use – NNEW DocumentationThe following Terms of Use applies to the NNEW Documentation

1 Use The User may use NNEW Documentation for any lawful purpose without any fee or cost Any modification, reproduction and redistribution may take place without further permission so long as proper copyright notices and acknowledgements are retained

2 Acknowledgement The NNEW Documentation was developed through the sponsorship of the National Oceanic and Atmospheric Administration and the Federal Aviation Administration

3 Copyright Any copyright notice contained in this Terms of Use, the NNEW Documentation, any software code, or any part of the website shall remain intact and unaltered and shall be affixed to any use, distribution or copy Except as specifically permitted herein, the user is not granted any express or implied right under any patents, copyrights, trademarks, or other intellectual property rights with respect to the NNEW Documentation

4 No Endorsements The names, MIT, Lincoln Labs, UCAR and NCAR, may not be used in any advertising or publicity to endorse or promote any program, project, product or commercial entity

5 Limitation of Liability The NNEW Documentation, including all content and materials, is provided "as is." There are no warranties of use, fitness for any purpose, service or goods, implied or direct, associated with the NNEW Documentation and MIT and UCAR expressly disclaim any warranties In no event shall MIT or UCAR be liable for any damages of any naturesuffered by any user, or any third party resulting in whole or in part from use of the NNEW Documentation

Table of Contents

Part 1: Introduction 8

1 PURPOSE 9

2 DESIGN GOALS 11

Part 2: Proposed Software Architecture 13

3 ARCHITECTURE AND DESIGN OVERVIEW 14

3.1 SYSTEM ARCHITECTURE OVERVIEW 14

4 SUBSYSTEM DECOMPOSITION (MODULES) 16 4.1 WCSRI Tiers 16

4.1.1 Protocol Tier 16

4.1.2 Domain Tier 17

4.1.3 Data Source Tier 18

4.2 SUBSCRIBER MANAGEMENT 19

4.3 LOGGING 20

4.4 MONITORING 20

4.5 AUDITING 21

4.6 WCS PROTOCOL 22

4.6.1 GetCoverage “store” attribute 22

4.7 WCS PROTOCOL EXTENSIONS 22

4.7.1 Subscription-Specific Extensions 22

4.7.2 Extended Trajectory Operations 22

4.7.3 Coordinate Reference System Extensions 24

4.7.4 Units and Measures Extensions 25

4.7.5 Geographic Subsetting Extensions 26

HARDWARE/SOFTWARE MAPPING 27 4.8 SOFTWARE ENVIRONMENT 27

4.8.1 Programming Languages 27

4.8.2 Web Application Framework 27

4.8.3 Data Management 28

4.8.4 Build and Deployment 28

5 PERSISTENT DATA MANAGEMENT 29 5.1.1 Users/Roles 29

5.1.2 Coverages 29

5.1.3 Application Data 31

5.1.4 Lifecycle Data 31

6 ACCESS CONTROL AND SECURITY 33 6.1 ACCESS RESTRICTION 33

7 GLOBAL SOFTWARE CONTROL 34

8 BOUNDARY CONDITIONS 35

APPENDIX A - ADDRESSED REQUIREMENTS 36

APPENDIX B - ACRONYMS 40

APPENDIX C - DEFINITIONS AND TERMS 42

APPENDIX D - REFERENCES 43

Table of Figures

Figure 1 4-D Wx Data Cube Components 10

Figure 2 Overview of the WCSRI 3-tiered System 15

Figure 3 Temporal Trajectory 23

Figure 4 Temporal Trajectory CRS 24

Figure 5 WCS Trajectory UML 24

Part 1:

Introduction

1 PURPOSE

To satisfy the requirements of Next Generation Air Transportation System’s (NextGen) 4-Dimensional Weather Data Cube (4-D Wx Data Cube), it is envisioned that a number of components will comprise the physical solution The Next Generation Air Transportation System (NextGen) Network Enabled Weather (NNEW) Program has recommended the adoption of several standards to be used as part of that solution

To provide a definitive interpretation of these standards, a production-quality implementation for

operational parties, and a resource for operational data providers that choose to implement these standardsdifferently, the NNEW Program will create reference implementations of key data distribution standards: the Web Feature Service and Web Coverage Service These reference implementations are developed and licensed in an open, standards-based fashion to allow broad usage

High-level requirements for the 4-D Wx Data Cube have been established over the past several years by the Joint Program Development Office (JPDO) Documents describing these requirements include the

“Concept of Operations for the Next Generation Air Transportation System [i]" document, the Dimensional Weather Functional Requirements for NextGen Air Traffic Management [ii]”, and others With these high-level requirements in mind, the lower level “NNEW IT CONOPS [iii]” captured a set of 4-D Wx Data Cube requirements relevant to network-enabled weather The NNEW IT CONOPS

“Four-document provides a representative set of use cases that are intended to aid system architects in

understanding typical usages of the 4-D Wx Data Cube Though not exhaustive, the selection of use casesrepresents an attempt to ‘span the problem domain’, covering both functional and non-functional

scenarios

The NNEW Program also developed a WCSRI Requirements Document [Error: Reference source not found] that focuses more closely on implementation issues than the NNEW IT CONOPS document and includes further context and background This document describes the high-level interaction and design ofthe WCSRI based on requirements identified

Requirements mentioned in this document that come from the WCSRI Requirements Document are

shown in bold, similar to Requirement 1.2.3 These notes refer to the version of this Requirements

Document indicated by [iv]

This document describes the architectural aspects and design of the Web Coverage Service Reference Implementation (WCSRI), which is well suited for serving geographically filtered coverage data This document has two purposes:

1 Describe the design of this phase of development in adequate detail to enable the development of the WCSRI This description will facilitate subsequent implementation and deployment phases ofthe 4-D Wx Data Cube

2 Describe how the WCSRI technology will integrate with other technology components, such as the FAA System Wide Information Management Program (SWIM) and 4-D Wx Data Cube Web Feature Service Reference Implementation (WFSRI)

Note: This document is intended to describe only high-level architectural and design concepts

Implementation details are left to other forms of documentation

Because the design and implementation of the WCSRI is iterative, this document addresses a subset of thetotal requirements of the WCSRI The initial design phase must precede implementation, but the design and implementation work may be considered to be on somewhat separate iterations after that point Therefore, the initial design work may enable several phases of implementation before further iteration is made on the design The requirements addressed by this document are listed in APPENDIX A -

ADDRESSED REQUIREMENTS

Important Note: This document is not intended to describe the functionality included in any particular

WCSRI release, merely the high-level design concepts that may be used as guidance in implementing the functionality once the appropriate WCSRI implementation phase is reached Additionally, this document describes architecture and design concepts for the WCSRI, but these concepts will almost certainly be adjusted as implementation progresses

Apart from those included in the OGC WCS specification, some requirements are imposed on the WCSRIsimply because it is intended to be a component within the 4-D Wx Data Cube This includes capabilities such as support for real-time data dissemination, flexible architectural configuration, infrastructure support for logging and monitoring, lifecycle management of data, and support for accident

reconstruction

In addition, the WCSRI must integrate with other 4-D Wx Data Cube components (see Figure 1) The 4-D Wx Data Cube’s WFSRI is intended to provide access to non-gridded data, and is relatively isolated from other 4-D Wx Data Cube components Therefore, it is not envisioned that integration between the WCSRI and WFSRI need occur However, the 4-D Wx Data Cube Registry/Repository will contain registry information about each WCSRI installation, such as coverage metadata and WCS service

endpoints Therefore some level of integration must occur between the two, though no implication is made as to the specific direction of communication or dependency between the WCSRI installations and the Registry/Repository

Figure 1 4-D Wx Data Cube Components

o Fault Tolerance The WCSRI should be fault tolerant to network and machine failures and

be able to recover gracefully from such failures Fault tolerance here implies that a WCSRI crash does not result in data corruption or any security malfunction

o Operational quality The WCS Reference Implementation is intended to guide future development of vendor implementations, as well as providing an operational server Because the WCSRI will be deployed as part of the 4-D Wx Data Cube initial operating capability (IOC), the implementation must be of production/operational quality and must support enterprise-level capabilities such as monitoring and security - either within the WCSRI itself or through its surrounding infrastructure

o Scalability It is almost certain that the 4-D Wx Data Cube architecture will be built to scale within each node by adding new pieces of hardware The WCSRI must

accommodate this architecture, and therefore the addition of a piece of hardware to a node with the WCSRI on it must scale well The primary characteristic is that the WCSRI scale horizontally (i.e it scales well as new computers are added to a group) rather than vertically (where additional CPUs, memory, and other capability are added to

a single piece of hardware)

 Usability:

o Out-of-the-box solution The intention of the WCSRI is to provide a baseline

implementation that may be used, out of the box, by any gridded data Service Provider participating in the 4-D Wx Data Cube This implementation should be easy to install andconfigure by the Service Provider This will alleviate the need for Service Providers to develop their own custom WCS solutions

 Other:

o 4-D Wx Data Cube integration There are several NNEW-foundational components that will comprise the 4-D Wx Data Cube-, including the WCSRI, WCSRI and the

Registry/Repository Though the WCSRI may be functional within an isolated

environment, it will also need to integrate with the other components in order for it to be operational within the 4-D Wx Data Cube

o SWIM and FTI integration – The FAA SWIM Program provides an infrastructure for service-oriented capabilities within the FAA The Federal Telecommunications

Infrastructure (FTI) provides a network infrastructure Since at least a portion of the 4-D Wx Data Cube- will be run within the FAA, within SWIM and over FTI, the WCSRI must integrate with that infrastructure

Part 2:

Proposed Software Architecture

3 ARCHITECTURE AND DESIGN OVERVIEW

This section provides an overview of the architecture and design of the WCSRI

This section gives a high level overview of the WCSRI architecture including a brief description of the sub-systems that comprise the overall WCSRI system and the interactions between the sub-systems

The WCSRI architecture follows the general model of a closed layered system A layered system is an

ordered set of layers or tiers, where a layer or tier is built using the functionality of the layers below it and

the layer itself provides the implementation basis for the layers above it While the objects in each layer can be independent, there is typically some coupling between the objects in the different layers

Knowledge is one-way only – a sub-system knows of the layers below it, but has no awareness of the layers above it A client-server relationship exists between the upper layers (users of services) and the

lower layers (providers of service) [Rumbaugh] In a closed architecture, each layer is built only in terms

of the immediate lower layer This reduces the dependencies between the layers and allows changes to be made easily as the interface of any layer impacts only the layer above it This is in contrast with an open architecture that allows each layer to access any of the layers below it While an open architecture reducesthe need to wrap or duplicate operations at each level, it violates the principle of information hiding and changes can ripple through the entire system To allow for future extensibility and modifications, the WCSRI is being designed as a closed, layered system

Note: More specifically, this approach corresponds to a 3-tier layered approach with the three principal

layers for enterprise applications: Presentation, Domain, and Data Source [v]

Figure 2 shows the three basic tiers, as well as major components of each tier Each tier is described in more detail in section 4

Multiple protocols may be eventually supported by the WCSRI at the same time To allow for future protocol modifications and additions, the WCSRI is designed with a pluggable protocol layer that ties intothe common functionality and data store Therefore, if newer versions of the WCS, JMBL, or OpenDAP protocols become necessary at some point in the future, they may be added with minimal changes to the remainder of the code base

Similarly, the WCSRI is designed to support a pluggable data source tier This will allow for future data store file formats (e.g., relational database), delegating access to other WCSRIs, or alternative approaches

to data storage such as a mix of relational database and files

Interactions with other WCSRI instances are planned (and are included at a high level in the design) but are left to subsequent design phases to be fully fleshed out The pluggable data source tier will assist in allowing for different communication patterns, such as delegation to an upstream WCSRI

Therefore, all user communications are handled by the protocol tier and are passed to the domain tier for

handling In the case of data notifications the domain tier Notification Engine will monitor the gridded

data file store and will notify the protocol tier of the need to send messages to subscribers using a specific technology (such as the FUSE Message Broker:ActiveMQ).

Figure 2 Overview of the WCSRI 3-tiered System

4 SUBSYSTEM DECOMPOSITION (MODULES)

This section gives a more detailed overview of the WCSRI modules In contrast to Section 3.1 and Figure

2 which provide a layered view of the overall architecture, this section takes a more functional point of view providing a more in-depth look at how sub-systems across the layers can be used to accomplish desired functionality

Note: these modules are logical groupings, and may or may not be segregated exactly as shown in the

to be implemented and plugged in to the WCSRI without directly affecting the core functionality

The protocol tier has two basic responsibilities: request parsing and response generation Request parsinginvolves taking a request (most notably a WCS 1.1.2 GetCoverage request) from a consumer and

translating it into domain objects that represent the request semantics Response generation takes domain

object results and formats them as a WCS XML response, a NetCDF file, or whatever representation is appropriate for that particular protocol

Request parsing produces a generalized set of domain objects that represent the logical intent of that

request that are independent of any particular protocol Therefore, the domain layer will make no

reference to HTTP, SOAP, WCS, or any other transmission technology and will instead represent

Requests, Constraints, and other abstract information related to serving gridded data The domain tier is described in further detail in Section 4.1.2

Each of the elements of a domain response will be appropriately transformed from their domain

representations into a protocol-appropriate response equivalent For example, a critical error in the domain tier (e.g., a simple Java string or object) will be returned through the WCS 1.1.2 protocol tier as a WCS 1.1.2-compliant error The same error from another request using OpenDAP would be translated and returned as an OpenDAP error

As protocols are added they will be encapsulated as new modules Therefore, protocol modules may be plugged in and configured relatively independently of other protocols, the core domain logic, and the backing data store

For example, protocol modules might eventually include:

CF and/or XML response.

4.1.2 Domain Tier

The domain tier is a set of objects that represent gridded data serving requests and responses

independently of a particular protocol or data storage mechanism This tier is an abstraction of the superset of functionality that is implemented by all protocols and data storage mechanisms For example,

if one implemented protocol includes support for re-gridding with a different resolution and another protocol has support for unit conversion, the domain tier would include objects for representing both functional elements

The two core concepts in the domain tier are the Request and Response Because these are part of the domain tier, neither specifically includes information on transport mechanisms, data formats, or protocols.Requests may eventually include:

 A basic gridded data Request

 A point time series Request

 A gridded dataset description Request (e.g., a list of times or its bounding box)

 Etc

Requests include information such as constraints/filters (such as temporal and spatial bounds), the desiredcoverage identifier, the desired output format identifier, and so on

Corresponding to each Request type, there will be a Response:

 A basic gridded data Response

 A point time series Response

 A gridded dataset description Response

 Etc

Responses encapsulate request status, including warnings and errors (such as when a Request does not include sufficient information or is improperly formed) and the response data (gridded data values)

4.1.2.1 Coordinate Reference System Module

The Coordinate Reference System module deals with EPSG codes, projected coordinate reference systems (e.g., Lambert Conformal, Stereographic) and transformations between different coordinate reference systems The module also includes support for defining gridded coordinate reference systems and their relationship to a base reference system This is likely to be implemented as part of the domain tier because it is a common need across different backing stores

4.1.3 Data Source Tier

This tier will be given Request objects from the domain tier, will access data storage (such as files or a relational database) and will build appropriate domain Response objects from that information This tier handles all the data storage-specific filtering, retrieval, and domain Response generation The domain tierwill make calls against the data source tier, but will not know anything about the file formats of the backing store, how data are filtered, or any of the other storage-specific details

4.1.3.1 Physical data store access

This is a module that can access a set of files on disk and in most cases perform filtering and

transformation functions against a backing data store (such as a directory of data files) The most

prominent example of this type of module is one that accesses a directory structure that contains

NetCDF-CF files

4.1.3.2 WCSRI to WCSRI Interactions

The 4-D Wx Data Cube will likely be composed of a hub and spoke architecture that requires

communication across WCSRI instances There are many topologies that may be used for the

4-D Wx Data Cube in order to optimize request performance, data flow latency, bandwidth, physical nodecapabilities, network topology, and other considerations A notional depiction of some of the roles a WCSRI may take on is described below In general, the WCSRI will be designed flexibly to

accommodate a broad range of different topologies and specific architectures This will probably require communication, intelligent data manipulation, and caching mechanisms across WCSRI nodes

In order to achieve this design goal, the WCSRI will leverage the data access façade as mentioned previously Access to data available in another WCSRI may be considered another type of data store access module, in that it can be exchanged with another module that accesses files from disk on the local machine Specific implementations of that façade may differ not only by data access mechanism, but also

by the type of WCSRI interactions supported Different façade implementations may be implemented to support the following communication patterns:

 Aggregator

A WCSRI instance may act as an Aggregator for a specific dataset This policy involves taking

pieces of the same dataset from more than one upstream node This aggregates remote files to a single (local) data source.(i.e., pull the remote files from several data sources/WCSRIs to a singledata source/WCSRI) Or aggregate dynamically, as a Delegator An example of this pattern would be a WCSRI that aggregates and stores local radar data that are available from three different sources upstream, each with a different geographic area This would be available from the aggregator as a single radar coverage with all the data available from upstream nodes

 Delegator (without caching)

The non-caching delegator pattern is one where a WCSRI will forward data requests to one or more upstream WCSRIs, and does not store data locally

 Delegator with dynamic cache

A delegator with a dynamic cache is similar to a non-caching delegator, except that frequent requests for the same remote data will sometimes be stored locally to optimize performance There are many types of caching policy that may be used The cache may manifest itself as pub/sub on a temporary or permanent basis (the latter being Repeater with Permanent Cache) This cache can reside on the data store or in memory, depending on caching policy and

performance decisions

 Repeater

A WCSRI may subscribe to an upstream WCSRI for updates to a particular coverage (such as new data arrival) This subscription may optionally include filtering information to only be notified of updates to that coverage that match the filtering criteria (such as geographic area)

SUBSCRIBER MANAGEMENT

The WCSRI will support the capability to notify data consumers when data becomes available that matches desired filtering criteria The default implementation will be based off of the FUSE Message Broker (ActiveMQ) and SOAP-related notification standards While these are the only currently

identified notification technology requirement, the WCSRI will be built to support a general capability that can be used for a broader range of notification technologies in non-FUSE environments, such as ATOM feeds, other JMS solutions, and HTTP callbacks A core WCSRI notification engine will send notifications to pluggable modules which are triggered when the WCSRI discovers new data that matchessubscription criteria The core WCSRI notification engine will be a part of the domain and/or data source tiers

This mechanism will be closely related to the WCS protocol filtering criteria, so the means to receive notifications and the means to grab data in an ad-hoc manner are relatively uniform This allows for a similar code base and protocol to identify filtered subsets of interest to consumers Therefore,

subscription requests by data consumers will include WCS-like filtering syntax

This subscription is held until it expires, and with the default notification technology a FUSE Messaging Broker channel is opened for that particular subscription When new data are discovered by the WCSRI that matches the filtering criteria for that subscription, a notification is sent to the data consumer through the channel The data consumer may then request data through typical WCSRI means.

The Subscriber Bridge and the Subscriber together manage the real-time, asynchronous dissemination ofcoverage data The Subscriber Bridge provides an interface to the data consumer, while the NotificationEngine provides the basic notification capabilities independently of a particular delivery mechanism.This relationship is shown in Figure 2

 Notification Engine: The Notification Engine is the basic, protocol-independent piece of logic

that identifies when coverage data relevant to a data consumer has arrived, and passesinformation to a Subscriber Bridge to notify interested data consumers

 Subscriber Bridge: The Subscriber Bridge handles the data encoding and format conversions

required by the subscriber, as well as the delivery of the message to the subscriber

Logging needs will potentially cross all portions of the WCSRI, and are the most prominent example of a cross-cutting concern Logging will be built on top of the Simple Logging Façade for Java (SLF4J) SLF4J is a façade that provides a flexible mechanism to support a number of underlying Java logging packages (e.g., LOG4J, central Java Logging API, etc) SLF4J with Log4J is the default logging

approach in FUSE, and is broadly applicable in any environment

There are several types of logging:

 Development/debugging Used to trace problems or behavior for specific cases or short periods

of time This will be implemented with AOP or with hard-coded calls in Java source

 Access/ traceability/runtime Used to log requests, responses, and is generally used as a way to

have a background log of accesses This can be compared to the access log of the Apache web server This will also include basic information on notifications and other non-request/response communications Implemented as AOP

 Error Used to log all errors and warnings Similar to the error log of the Apache web server

Implemented in AOP, and possibly hard-coded Java source

 Request reconstruction Extremely detailed logging sufficient to reconstruct a request and

response from a data consumer at a particular time Unclear whether this will be best

accomplished through AOP or other techniques

Monitoring information collected and exposed by the WCSRI includes:

 Available coverages with basic metadata and configuration information, such as what protocol(s) are currently offered

 WCSRI service configuration status, including the exposed endpoints

 Performance information (gathered on a per-coverage basis)

o Mean response time

o Mean backing store seek time (response time for the database layer alone)

o Mean request (user communication layer) parsing time, for incoming request translation into domain objects

o Mean response (user communication layer) generation time, for outgoing response generation after data is retrieved

 Per-coverage request counts (a count of all requests by type, broken down per coverage)

 Critical error status

Additional monitoring and management capabilities will be added as needed, particularly as SWIM information becomes available

Monitoring support is provided by the Logging sub-system in the Information Retrieval layer that logs all activities in the Logging Database The Logging sub-system provides the interface for logging at differentlevels with the ability to turn on or off different types of logging Additionally, logging information collected will be collated and common statistics computed periodically by the Logging sub-system to provide better monitoring performance

4.4 AUDITING

Auditing functionality will be supported primarily through logging mechanisms and specialized request support This will involve additions to the protocol tier to support qualified users making auditing requests It is desirable to segregate auditing functionality from the rest of the WCSRI to provide a separation of concerns, but it is not currently known whether this will be possible because of the probable close relationship between auditing requests and standard data requests

Auditing requires two components: a logging mechanism to collect information sufficient to later

reconstruct a consumer request, and request support that allows for the retrieval of this historical

information

Note: Auditing support will not save every request from and response to data consumers While the raw

data will be preserved so the responses can be replicated, the filtered response data for every request will not be kept Therefore, it is truly request reconstruction rather than a verbose logging mechanism Saving the actual responses sent to all clients over 15 days would be very prohibitive for 4-D Wx Data Cube nodes, and the responses sent to consumers can be replicated by keeping the necessary amount of raw data results rather than all of the responses

4.5 WCS PROTOCOL

4.5.1 GetCoverage “store” attribute

The WCS specification provides two mechanisms for returning the coverage binary files from a

GetCoverage request Though the GetCoverage response consists of XML, the actual coverage data file(s) can be returned in a SOAP message with attachments, or it can be stored temporarily on a server for HTTP download access

The preferred approach to returning binary data is to return the data file(s) as a SOAP message with attachments The alternative approach of storing the data temporarily on the server has implications with respect to scalability and statelessness, complicates the security requirements for a single GetCoverage request (i.e., to get a single coverage requires the initial, secure request that stores the temporary data file

on the server, and then requires an additional secure request to retrieve that temporary data file), and inherently complicates the policy used for storing the temporary data files such as configuring how long each file should be saved Therefore, the SOAP with attachments approach will be used by the WCSRI and storing result files will not be supported initially

4.6 WCS PROTOCOL EXTENSIONS

To handle GetCoverage requests in a uniform manner, while allowing for the results to be returned as astandard request/response or alternatively allowing the client to set up a persistent query/subscription, it isproposed that the OGC WCS specification be extended to allow clients to specify the method of resultdelivery This would allow seamless extension of GetCoverage without requiring any externalmodifications to the GetCoverage interface itself This approach can also be common across other OGCservice specifications, such as the WFS

4.6.1 Subscription-Specific Extensions

To adequately support persistent queries, the WCS GetCoverage operation will be extended to allow clients to specify subscription parameters, including:

 Latency: Maximum tolerable delay for the transmission of a message to the subscriber

 Window: The length of subscription time The client is subscribed from now to forever by default,

but the subscriber has the option to specify the duration

 Update Frequency: To control message frequency at the subscriber, the subscriber can specify

how often they would like to receive updates, for example once every minute, or once every hour

 Renewal: Allows the renewal of an already configured subscription

4.6.2 Extended Trajectory Operations

The WCSRI will support the coverage geometries, including the temporal trajectories, as specified previously in the WCSRI Requirements Document This section describes how trajectories, cross

sections, and other complex geometries will be specified by an extension to the WCS specification

A picture of a corridor along a temporal trajectory is shown in Figure 3 The temporal trajectory is defined

by a CRS anchored in space and time, as shown in red in Figure 4 The CRS has an origin located at the latitude, longitude, altitude, and time of the first waypoint of the trajectory The X axis of the CRS travels