Getting a tar ball instead of a CSV response: Difference between revisions

From OPeNDAP Documentation
⧼opendap2-jumptonavigation⧽
Line 21: Line 21:


== Actors ==
== Actors ==
<font size="-2" color="green">''List actors, people or things outside the system that either acts on the system (primary actors) or is acted on by the system (secondary actors). Primary actors are ones that invoke the use case and benefit from the result. Identify sensors, models, portals and relevant data resources. Identify the primary actor and briefly describe role.''</font>
; A developer building a 'response URL' from a user's data search request
: This person must write software that will translate the search request into the Hyrax server's (to-be developed) aggregation request syntax.  
; A person making a data request to the Hyrax server
: This actor will need to a similar understanding of the new aggregation mechanism as the 'developer' but will be writing the URLs 'by hand'.
; The Hyrax data server
: This is an important actor because the server will have to be updated to realize the new software's benefits.
; Level 2 satellite swath data, stored in multiple files (file == granule == 'pass')
: This use case is limited to a particular kind of data, although the resulting software might be useful for Time Series data too.


== Preconditions ==
== Preconditions ==

Revision as of 18:44, 5 February 2015

<-- Back

'Point Of Contact: James

Description

Satellite_Swath_2

Goal

NB: This use case is very similar to the Satellite_Swath_1 use case. The differences in the goals are highlighted in bold.

The user wants to get data from several granules of a many-granule data set using a single request. The user is willing to iterate over several response objects/files so long as those files are delivered in a single response and are netcdf files. However, this aggregation operation must work with Swath data from a satellite, which poses special problems. Furthermore, the aggregation should require little or no effort by the data provider to configure.

Summary

Principal actor: A person who wants to access level 2 satellite swath data from a number of granules using a single URL. The person may be an end user who issues a data request or they may be the developer of a system that will build a URL to return to an end user. In either case, an end-user dereferences the URL to get data.

Goal: Eliminate users having to use many URLs to get these data.

The data are Satellite Swath data (e.g., MODIS, level2) where each granule contains a number of dependent variables are matched to lat and lon arrays, all of which are 2D (this is the general case for a 2D discrete coverage). The data set is made up of a number of these granules, organized in a hierarchy of directories by date. Each of the granules holds one 'pass' of the satellite from one pole to another. When a user searches for data, they use a spatial and time box to choose values from the whole data set. Currently the response to that search is a list of granules, where each contains some of the data in the users query. The complete granules, or subset versions, may be downloaded. In the either case, the user must access/download a number of files and then the values combined somehow - the exact mechanism being left up to the end user, including reading the files that contain the data.

In this use case, the user instead uses a single URL to access all of the data that match the selection criteria. Those values will be returned using a collection of netCDF files bundled in a tar.gz file, so there is very limited file decoding burden put on the user. The URL will be one that a system developer can easily build in software as well as one that a person could write by hand, at least in many cases.

Actors

A developer building a 'response URL' from a user's data search request
This person must write software that will translate the search request into the Hyrax server's (to-be developed) aggregation request syntax.
A person making a data request to the Hyrax server
This actor will need to a similar understanding of the new aggregation mechanism as the 'developer' but will be writing the URLs 'by hand'.
The Hyrax data server
This is an important actor because the server will have to be updated to realize the new software's benefits.
Level 2 satellite swath data, stored in multiple files (file == granule == 'pass')
This use case is limited to a particular kind of data, although the resulting software might be useful for Time Series data too.

Preconditions

Here we state any assumptions about the state of the system that must be met for the trigger (below) to initiate the use case. Any assumptions about other systems can also be stated here, for example, weather conditions. List all preconditions.

Triggers

Here we describe in detail the event or events that brings about the execution of this use case. Triggers can be external, temporal, or internal. They can be single events or when a set of conditions are met, List all triggers and relationships.

Basic Flow

Often referred to as the primary scenario or course of events. In the basic flow we describe the flow that would be followed if the use case where to follow its main plot from start to end. Error states or alternate states that might be highlighted are not included here. This gives any browser of the document a quick view of how the system will work. Here the flow can be documented as a list, a conversation or as a story.(as much as required)

Alternate Flow

Here we give any alternate flows that might occur. May include flows that involve error conditions. Or flows that fall outside of the basic flow.

Post Conditions

Here we give any conditions that will be true of the state of the system after the use case has been completed.

Activity Diagram

Here a diagram is given to show the flow of events that surrounds the use case.

Notes

There is always some piece of information that is required that has no other place to go. This is the place for that information.

Resources

In order to support the capabilities described in this Use Case, a set of resources must be available and/or configured. These resources include data and services, and the systems that offer them. This section will call out examples of these resources.


Resource Owner Description Availability Source System
name Organization that owns/ manages resource Short description of the resource How often the resource is available Name of system which provides resource