Difference between revisions of "User access to satellite data"

From Earth Science Information Partners (ESIP)
Line 1: Line 1:
 +
==Use Case AQ.SatelliteData.1.a==
 +
 +
 +
==Purpose==
 +
Earth Information Exchange
 +
 +
Access to satellite data using queries over a continuous space-time-parameter domain.
 +
 +
==Revision Information==
 +
Version 0.1.a
 +
 +
Prepared by:
 +
Rudolf Husar
 +
Washington University
 +
 +
and
 +
 +
Stefan Falke
 +
Washington University and
 +
Northrop Grumman IT - TASC
 +
 +
created: February 26, 2007
 +
 +
Revision History
 +
 +
Modified by
 +
<Modifier Name/Affil>,
 +
<Date/time>,
 +
<Brief Description>
 +
 +
==Use Case Identification==
 +
 +
===Use Case Designation===
 +
 +
AQ.SatelliteData.1.a
 +
 +
===Use Case Name===
 +
Short name: Satellite data access
 +
 +
Long name: Air quality user-access to satellite data by space-time-parameter queries
 +
 +
==Use Case Definition==
 
The AQ cluster has a fundamental need for a set of CORE web services that allow meaningful user-access to satellite data. These services include:
 
The AQ cluster has a fundamental need for a set of CORE web services that allow meaningful user-access to satellite data. These services include:
 
* Data access by space-time-parameter query on granules  
 
* Data access by space-time-parameter query on granules  
Line 5: Line 47:
 
   
 
   
 
The proper chaining of these services results in a higher order service, WCS, that returns the requested satellite data for the BBOX, Time, Parameter. Not more not less. Such a WCS service was in fact used in the Web service chaining experiment. Extending that service to return numeric satellite data (not just images) is the goal.
 
The proper chaining of these services results in a higher order service, WCS, that returns the requested satellite data for the BBOX, Time, Parameter. Not more not less. Such a WCS service was in fact used in the Web service chaining experiment. Extending that service to return numeric satellite data (not just images) is the goal.
 +
 +
===Actors===
 +
 +
====Primary Actors====
 +
 +
Air quality analysts interested in using satellite data for assessing air pollution, comparing satellite and surface data, "ground-truthing" model results.
 +
 +
====Other Actors====
 +
 +
===Preconditions===
 +
*1. Satellite data are available through open interfaces
 +
*2. Data access service specifications, e.g. OGC Web Coverage Service (WCS), can be implemented by data provider or mediator
 +
*3.
 +
 +
===Postconditions===
 +
*1. Satellite data in a numeric data format (as opposed to image format) covering the spatial area, time range, and parameters that were specified in the query.
 +
 +
===Normal Flow (Process Model)===
 +
*1) The user finds a WCS serving satellite data
 +
*2) The user submits a WCS GetCoverage request that includes bounding box, time, and parameter filters
 +
*3) The satellite data server provides the data that meets the query criteria. In the process, the data provider may need to execute swath mosaicking and data subsetting services.
 +
 +
===Alternative Flows===
 +
 +
===Successful Outcomes===
 +
*1.Operation succeeds and user obtains satellite dataset adhering to the requested spatial, temporal, and parameter filters.
 +
 +
===Failure Outcomes===
 +
*1.
 +
*2.
 +
 +
===Special Functional Requirements===
 +
None
 +
 +
===Extension Points===
 +
*AQ.SatelliteAccess.1.b
 +
NASA GSFC DISC implementation of WCS for OMI NO2 access
 +
 +
==Diagrams==
 +
 +
===Use Case Diagram===
 +
 +
===State Diagram (optional)===
 +
 +
===Activity Diagram (optional)===
 +
 +
===Other Diagrams (optional)===
 +
 +
==Non-Functional Requirements (optional)==
 +
 +
===Performance===
 +
 +
===Reliability===
 +
 +
===Scalability===
 +
 +
===Usability===
 +
 +
===Security===
 +
 +
===Other Non-functional Requirements===
 +
 +
==Selected Approach==
 +
 +
===Overall Technical Approach===
 +
 +
===Architecture===
 +
 +
===Participating Organizations/Projects===
 +
 +
===Technology A===
 +
 +
====Description====
 +
 +
====Benefits====
 +
 +
====Limitations====
 +
 +
===Technology B===
 +
 +
====Description====
 +
 +
====Benefits====
 +
 +
====Limitations====
 +
 +
==References (optional)==

Revision as of 10:58, February 27, 2007

Use Case AQ.SatelliteData.1.a

Purpose

Earth Information Exchange

Access to satellite data using queries over a continuous space-time-parameter domain.

Revision Information

Version 0.1.a

Prepared by: Rudolf Husar Washington University

and

Stefan Falke Washington University and Northrop Grumman IT - TASC

created: February 26, 2007

Revision History

Modified by <Modifier Name/Affil>, <Date/time>, <Brief Description>

Use Case Identification

Use Case Designation

AQ.SatelliteData.1.a

Use Case Name

Short name: Satellite data access

Long name: Air quality user-access to satellite data by space-time-parameter queries

Use Case Definition

The AQ cluster has a fundamental need for a set of CORE web services that allow meaningful user-access to satellite data. These services include:

  • Data access by space-time-parameter query on granules
  • Subsetting that clips the data to user-specified BBOX
  • Mosaicing that splices granule mosaic into a coherent dataset

The proper chaining of these services results in a higher order service, WCS, that returns the requested satellite data for the BBOX, Time, Parameter. Not more not less. Such a WCS service was in fact used in the Web service chaining experiment. Extending that service to return numeric satellite data (not just images) is the goal.

Actors

Primary Actors

Air quality analysts interested in using satellite data for assessing air pollution, comparing satellite and surface data, "ground-truthing" model results.

Other Actors

Preconditions

  • 1. Satellite data are available through open interfaces
  • 2. Data access service specifications, e.g. OGC Web Coverage Service (WCS), can be implemented by data provider or mediator
  • 3.

Postconditions

  • 1. Satellite data in a numeric data format (as opposed to image format) covering the spatial area, time range, and parameters that were specified in the query.

Normal Flow (Process Model)

  • 1) The user finds a WCS serving satellite data
  • 2) The user submits a WCS GetCoverage request that includes bounding box, time, and parameter filters
  • 3) The satellite data server provides the data that meets the query criteria. In the process, the data provider may need to execute swath mosaicking and data subsetting services.

Alternative Flows

Successful Outcomes

  • 1.Operation succeeds and user obtains satellite dataset adhering to the requested spatial, temporal, and parameter filters.

Failure Outcomes

  • 1.
  • 2.

Special Functional Requirements

None

Extension Points

  • AQ.SatelliteAccess.1.b

NASA GSFC DISC implementation of WCS for OMI NO2 access

Diagrams

Use Case Diagram

State Diagram (optional)

Activity Diagram (optional)

Other Diagrams (optional)

Non-Functional Requirements (optional)

Performance

Reliability

Scalability

Usability

Security

Other Non-functional Requirements

Selected Approach

Overall Technical Approach

Architecture

Participating Organizations/Projects

Technology A

Description

Benefits

Limitations

Technology B

Description

Benefits

Limitations

References (optional)