Template Format

From Earth Science Information Partners (ESIP)

Use Case AQ.SatelliteData.1.a[edit | edit source]

Purpose[edit | edit source]

Earth Information Exchange

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

Revision Information[edit | edit source]

Version 0.1.a

Prepared by: Rudolf Husar Washington University


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[edit | edit source]

Use Case Designation[edit | edit source]


Use Case Name[edit | edit source]

Short name: Satellite data access

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

Use Case Definition[edit | edit source]

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[edit | edit source]

Primary Actors[edit | edit source]

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

Other Actors[edit | edit source]

Preconditions[edit | edit source]

  • 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[edit | edit source]

  • 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)[edit | edit source]

  • 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[edit | edit source]

Successful Outcomes[edit | edit source]

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

Failure Outcomes[edit | edit source]

  • 1.
  • 2.

Special Functional Requirements[edit | edit source]


Extension Points[edit | edit source]

Diagrams[edit | edit source]

Use Case Diagram[edit | edit source]

State Diagram (optional)[edit | edit source]

Activity Diagram (optional)[edit | edit source]

Other Diagrams (optional)[edit | edit source]

Non-Functional Requirements (optional)[edit | edit source]

Performance[edit | edit source]

Reliability[edit | edit source]

Scalability[edit | edit source]

Usability[edit | edit source]

Security[edit | edit source]

Other Non-functional Requirements[edit | edit source]

Selected Approach[edit | edit source]

Overall Technical Approach[edit | edit source]

Architecture[edit | edit source]

Participating Organizations/Projects[edit | edit source]

Technology A[edit | edit source]

Description[edit | edit source]

Benefits[edit | edit source]

Limitations[edit | edit source]

Technology B[edit | edit source]

Description[edit | edit source]

Benefits[edit | edit source]

Limitations[edit | edit source]

References (optional)[edit | edit source]