**UML Description: Level 1 Use Cases and Analysis View**

Boeing Corporation and Battelle Ocean Sciences

An IOOS Demonstration Project

July 2006

NOAA Coastal Services Center

2234 South Hobson Avenue • Charleston, SC 29405-2413\
843-740-1200 (phone) • 843-740-1224 (fax)

This Page Intentionally Blank

Table of Contents

1 Scope [1](#scope)

1.1 Identification [1](#identification)

1.2 ICOOS Use Case Overview [1](#icoos-use-case-overview)

1.2.1 Observers (Actors) [3](#observers-actors)

1.2.2 Institute Data Collections (Association)
[3](#institute-data-collections-association)

1.2.3 Collect Measurements (Use Case)
[4](#collect-measurements-use-case)

1.2.4 Consolidate Collections (Association)
[4](#consolidate-collections-association)

1.2.5 Modelers (Actors) [4](#modelers-actors)

1.2.6 Institute Modeling (Association)
[4](#institute-modeling-association)

1.2.7 Model Conditions (Use Case) [4](#model-conditions-use-case)

1.2.8 Acquire Data (Use Case) [5](#acquire-data-use-case)

1.2.9 Harvest Objective Data (Association)
[5](#harvest-objective-data-association)

1.2.10 Stage Data (Use Case) [5](#stage-data-use-case)

1.2.11 Access Standardized Data (Association)
[8](#access-standardized-data-association)

1.2.12 Store Information Products (Association)
[8](#store-information-products-association)

1.2.13 Publish Data (Use Case) [9](#publish-data-use-case)

1.2.14 Manage Storage (Use Case) [11](#manage-storage-use-case)

1.2.15 Route Standardized Data (Association)
[13](#route-standardized-data-association)

1.2.16 Invoke Information Product Storage (Association)
[13](#invoke-information-product-storage-association)

1.2.17 Employ Data (Use Case) [13](#employ-data-use-case)

1.2.18 Manipulate Data (Association) [14](#manipulate-data-association)

1.2.19 Users (Actors) [14](#users-actors)

2 ICOOS Data Source Classes [15](#icoos-data-source-classes)

2.1 Condition (Class) [17](#condition-class)

2.1.1 Variability (Condition Attribute)
[18](#variability-condition-attribute)

2.2 Stimulates (Association) [18](#stimulates-association)

2.3 Sensor (Class) [18](#sensor-class)

2.3.1 Sensor Type (Sensor Attribute) [19](#sensor-type-sensor-attribute)

2.3.2 Short Name (Sensor Attribute) [19](#short-name-sensor-attribute)

2.3.3 Long Name (Sensor Attribute) [19](#long-name-sensor-attribute)

2.3.4 Elevation (Sensor Attribute) [19](#elevation-sensor-attribute)

2.3.5 Description (Sensor Attribute) [20](#description-sensor-attribute)

2.3.6 Manufacturer (Sensor Attribute)
[20](#manufacturer-sensor-attribute)

2.3.7 Part Number (Sensor Attribute) [20](#part-number-sensor-attribute)

2.3.8 Owner (Sensor Attribute) [20](#owner-sensor-attribute)

2.3.9 Calibration (Sensor Attribute) [21](#calibration-sensor-attribute)

2.3.10 Operational Status (Sensor Attribute)
[21](#operational-status-sensor-attribute)

2.4 Creates (#1) (Association) [21](#creates-1-association)

2.5 Measurement (Class) [21](#measurement-class)

2.5.1 Name (Measurement Attribute) [22](#name-measurement-attribute)

2.5.2 Description (Measurement Attribute)
[22](#description-measurement-attribute)

2.5.3 Resolution Minimum (Measurement Attribute)
[22](#resolution-minimum-measurement-attribute)

2.5.4 Resolution Maximum (Measurement Attribute)
[22](#resolution-maximum-measurement-attribute)

2.5.5 Precision (Measurement Attribute)
[23](#precision-measurement-attribute)

2.5.6 Limits (Measurement Attribute) [23](#limits-measurement-attribute)

2.5.7 Units (Measurement Attribute) [23](#units-measurement-attribute)

2.5.8 Indication (Measurement Attribute)
[23](#indication-measurement-attribute)

2.6 Provides Measurement to (Association)
[24](#provides-measurement-to-association)

2.7 Data Collection Package (Class) [24](#data-collection-package-class)

2.7.1 DCP Name (DCP Attribute) [24](#dcp-name-dcp-attribute)

2.7.2 Description (DCP Attribute) [25](#description-dcp-attribute)

2.7.3 Owner (DCP Attribute) [25](#owner-dcp-attribute)

2.8 Assembles (#1) (Association) [26](#assembles-1-association)

2.9 Observation (Class) [26](#observation-class)

2.9.1 Short Name (Observation Attribute)
[26](#short-name-observation-attribute)

2.9.2 Long Name (Observation Attribute)
[26](#long-name-observation-attribute)

2.9.3 Description (Observation Attribute)
[27](#description-observation-attribute)

2.9.4 Period (Observation Attribute) [27](#period-observation-attribute)

2.9.5 Date (Observation Attribute) [27](#date-observation-attribute)

2.9.6 Time (Observation Attribute) [27](#time-observation-attribute)

2.9.7 Reading (Observation Attribute)
[28](#reading-observation-attribute)

2.10 Provides Observations to (Association)
[28](#provides-observations-to-association)

2.11 Station (Class) [28](#station-class)

2.11.1 Type (Station Attribute) [28](#type-station-attribute)

2.11.2 Short Name (Station Attribute)
[29](#short-name-station-attribute)

2.11.3 Long Name (Station Attribute) [29](#long-name-station-attribute)

2.11.4 Latitude (Station Attribute) [29](#latitude-station-attribute)

2.11.5 Longitude (Station Attribute) [30](#longitude-station-attribute)

2.11.6 Elevation (Station Attribute) [30](#elevation-station-attribute)

2.11.7 Date (Station Attribute) [30](#date-station-attribute)

2.11.8 Time (Station Attribute) [31](#time-station-attribute)

2.11.9 Description (Station Attribute)
[31](#description-station-attribute)

2.11.10 Operating Agency (Station Attribute)
[31](#operating-agency-station-attribute)

2.11.11 Operating Status (Station Attribute)
[31](#operating-status-station-attribute)

2.11.12 URL (Station Attribute) [32](#url-station-attribute)

2.11.13 Benchmarks (Station Attribute)
[32](#benchmarks-station-attribute)

2.11.14 Benchmark Offset (Station Attribute)
[32](#benchmark-offset-station-attribute)

2.11.15 Horizontal Datum (Station Attribute)
[33](#horizontal-datum-station-attribute)

2.11.16 Vertical Datum (Station Attribute)
[33](#vertical-datum-station-attribute)

2.11.17 Tidal Epoch (Station Attribute)
[33](#tidal-epoch-station-attribute)

2.12 Is Coordinate System Reference for (Association)
[34](#is-coordinate-system-reference-for-association)

2.13 Benchmark (Class) [34](#benchmark-class)

2.13.1 Name (Benchmark Attribute) [34](#name-benchmark-attribute)

2.13.2 Description (Benchmark Attribute)
[34](#description-benchmark-attribute)

2.13.3 Latitude (Benchmark Attribute)
[35](#latitude-benchmark-attribute)

2.13.4 Longitude (Benchmark Attribute)
[35](#longitude-benchmark-attribute)

2.13.5 Elevation (Benchmark Attribute)
[35](#elevation-benchmark-attribute)

2.14 Supplies Observations to (Association)
[35](#supplies-observations-to-association)

2.15 Calculates (Association) [36](#calculates-association)

2.16 Parameter (Class) [36](#parameter-class)

2.16.1 Name (Parameter Attribute) [36](#name-parameter-attribute)

2.16.2 Description (Parameter Attribute)
[36](#description-parameter-attribute)

2.16.3 Limits (Parameter Attribute) [36](#limits-parameter-attribute)

2.16.4 Units (Parameter Attribute) [36](#units-parameter-attribute)

2.16.5 Quantity (Parameter Attribute)
[37](#quantity-parameter-attribute)

2.17 Creates (#2) (Association) [37](#creates-2-association)

2.18 Prediction (Class) [37](#prediction-class)

2.18.1 Short Name (Prediction Attribute)
[37](#short-name-prediction-attribute)

2.18.2 Long Name (Prediction Attribute)
[37](#long-name-prediction-attribute)

2.18.3 Description (Prediction Attribute)
[37](#description-prediction-attribute)

2.18.4 Period (Prediction Attribute) [37](#period-prediction-attribute)

2.18.5 Date (Prediction Attribute) [38](#date-prediction-attribute)

2.18.6 Time (Prediction Attribute) [38](#time-prediction-attribute)

2.18.7 Value (Prediction Attribute) [38](#value-prediction-attribute)

2.19 Forecast (Class) [38](#forecast-class)

2.19.1 Name (Forecast Attribute) [38](#name-forecast-attribute)

2.19.2 Description (Forecast Attribute)
[38](#description-forecast-attribute)

2.19.3 Region (Forecast Attribute) [38](#region-forecast-attribute)

2.19.4 Type (Forecast Attribute) [38](#type-forecast-attribute)

2.19.5 Date (Forecast Attribute) [39](#date-forecast-attribute)

2.19.6 Time (Forecast Attribute) [39](#time-forecast-attribute)

2.19.7 Run Time (Forecast Attribute) [39](#run-time-forecast-attribute)

2.19.8 Grid Resolution (Forecast Attribute)
[39](#grid-resolution-forecast-attribute)

2.19.9 URL (Forecast Attribute) [39](#url-forecast-attribute)

2.19.10 Status (Forecast Attribute) [39](#status-forecast-attribute)

2.19.11 Advisory (Forecast Attribute) [39](#advisory-forecast-attribute)

2.20 Model (Class) [40](#model-class)

2.20.1 Model Name (Model Attribute) [40](#model-name-model-attribute)

2.20.2 Modeling Agency (Model Attribute)
[40](#modeling-agency-model-attribute)

2.20.3 Description (Model Attribute) [40](#description-model-attribute)

2.20.4 Extent (Model Attribute) [41](#extent-model-attribute)

2.20.5 Update Frequency (Model Attribute)
[41](#update-frequency-model-attribute)

2.20.6 Run Time (Model Attribute) [41](#run-time-model-attribute)

2.20.7 Forecast Range (Model Attribute)
[41](#forecast-range-model-attribute)

2.20.8 Forecast Frequency (Model Attribute)
[41](#forecast-frequency-model-attribute)

2.21 Provides Forecasts to (Association)
[42](#provides-forecasts-to-association)

2.22 Data Warehouse (Class) [42](#data-warehouse-class)

2.22.1 URL (Data Warehouse Attribute)
[42](#url-data-warehouse-attribute)

2.22.2 Station Inventory (Data Warehouse Attribute)
[42](#station-inventory-data-warehouse-attribute)

2.22.3 Data Type Inventory (Data Warehouse Attribute)
[43](#data-type-inventory-data-warehouse-attribute)

2.22.4 Operating Agency (Data Warehouse Attribute)
[43](#operating-agency-data-warehouse-attribute)

2.22.5 Quality Control Description (Data Warehouse Attribute)
[43](#quality-control-description-data-warehouse-attribute)

2.22.6 Interface Type(Data Warehouse Attribute)
[44](#interface-typedata-warehouse-attribute)

2.23 Builds (Association) [44](#builds-association)

2.24 Web Page (Class) [44](#web-page-class)

2.24.1 Code (Web Page Attribute) [44](#code-web-page-attribute)

2.24.2 Observations (Web Page Attribute)
[45](#observations-web-page-attribute)

2.25 Constructs (Association) [45](#constructs-association)

2.26 OPeNDAP File (Class) [45](#opendap-file-class)

2.26.1 Observation Data (OPeNDAP File Attribute)
[45](#observation-data-opendap-file-attribute)

2.27 Web Page Interface (Class) [45](#web-page-interface-class)

2.28 OPeNDAP (Class) [45](#opendap-class)

3 ICOOS IIS Classes [46](#icoos-iis-classes)

3.1 Web Page Interface (Class) [46](#web-page-interface-class-1)

3.2 OPeNDAP (Class) [47](#opendap-class-1)

3.3 ETL Program (Class) [47](#etl-program-class)

3.3.1 Timer (ETL Program Attribute) [47](#timer-etl-program-attribute)

3.3.2 Transformation Manager (ETL Program Attribute)
[47](#transformation-manager-etl-program-attribute)

3.3.3 Base Template (ETL Program Attribute)
[47](#base-template-etl-program-attribute)

3.3.4 Data Storage Interface (ETL Program Attribute)
[47](#data-storage-interface-etl-program-attribute)

3.3.5 Scraper Settings (ETL Program Attribute)
[47](#scraper-settings-etl-program-attribute)

3.3.6 Web Page Scraper (ETL Program Attribute)
[48](#web-page-scraper-etl-program-attribute)

3.3.7 Extracted Observation (ETL Program Attribute)
[48](#extracted-observation-etl-program-attribute)

3.3.8 Loader (ETL Program Attribute) [48](#loader-etl-program-attribute)

3.3.9 Relational Database Manager (ETL Program Attribute)
[48](#relational-database-manager-etl-program-attribute)

3.3.10 Working Database (ETL Program Attribute)
[48](#working-database-etl-program-attribute)

3.3.11 OPeNDAP Settings (ETL Program Attribute)
[48](#opendap-settings-etl-program-attribute)

3.3.12 OPeNDAP Interface (ETL Program Attribute)
[48](#opendap-interface-etl-program-attribute)

3.3.13 OPeNDAP Base Template (ETL Program Attribute)
[49](#opendap-base-template-etl-program-attribute)

3.4 Geospatial Interface (Class) [49](#geospatial-interface-class)

3.5 Geospatial Data Repository (Class)
[49](#geospatial-data-repository-class)

3.5.1 Geospatial Database Manager (Geospatial Data Repository Attribute)
[49](#geospatial-database-manager-geospatial-data-repository-attribute)

3.5.2 Geospatial Database (Geospatial Data Repository Attribute)
[49](#geospatial-database-geospatial-data-repository-attribute)

3.6 Web Feature Service (Class) [49](#web-feature-service-class)

3.7 Data User (Class) [49](#data-user-class)

3.7.1 Client (Data User Attribute) [50](#client-data-user-attribute)

3.7.2 Operator (Data User Attribute) [50](#operator-data-user-attribute)

List of Figures

Figure 1‑1. ICOOS IIS Level 1 Use Cases.
[2](#__RefHeading___Toc137959380)

Figure 2‑1. ICOOS Data Source Classes.
[17](#__RefHeading___Toc137959381)

Figure 3‑1. ICOOS IIS Classes. [46](#__RefHeading___Toc137959382)

Abstract

The ICOOS Integrated Information System demonstration process described
herein encompasses services that integrate mixed-content geospatial
source data into a current standardized-content collection and make the
collection available to coastal inundation models and tools employed by
user personnel on remote terminals.

# Scope

This document presents the ICOOS Level 1 object oriented use case and
analysis view for review and comment. The analysis view presents the
Level 1 policies and processes (requirements) to be applied to the ICOOS
design.

This document studies the entire ICOOS from end to end as seen from the
Level 1 viewpoint of the ICOOS IIS Data Mart. The companion document,
*Integrated Coastal and Ocean Observing Systems (ICOOS) Integrated
Information System (IIS) UML Description: Level 2 Use Cases and Analysis
View,* looks more closely at just the ICOOS IIS Data Mart.

## Identification

The formal title of the system-level entity is \"Integrated Information
System for the Integrated Coastal and Ocean Observing Systems.\" The
title is abbreviated to \"ICOOS IIS x.y\" where \"x\" represents the
version number and \"y\" represents the release number.

The ICOOS IIS is also known as \"ICOOS IIS Data Mart,\" \"ICOOS Data
Mart,\" and \"Data Mart.\"

## ICOOS Use Case Overview

The ICOOS IIS is a data integration and access system that provides
geospatial data to users in compliance with web communication standards
issued by the Open Geospatial Consortium (OGC).

The ICOOS IIS obtains mixed-content data through data warehouses,
converts the data to a standardized content, and stores the standardized
data in a relational database. The ICOOS IIS receives requests for
standardized data from users, retrieves the requested data, and
communicates the requested data to the users. The flows of requests and
retrieved data comply with OGC standards for web map context (WMC), web
coverage service (WCS), and web feature service (WFS).

Figure 1-1 (below) depicts the UML use case view of the ICOOS IIS
concept. The ovals and stick figures represent Level 1 use cases. The
ICOOS IIS functionality is shown embedded in the operating environment
that begins with data collections and ends with data users. The overall
data flow is counterclockwise around the diagram, beginning at the upper
left. The ICOOS IIS uses the Acquire Data functionality (which includes
the Data Warehouse) as its data source. The ICOOS IIS provides services
to the Employ Data functionality, which includes applications and
models.

![](media/image1.wmf)

[]{#__RefHeading___Toc137959380 .anchor}Figure 1‑1. ICOOS IIS Level 1
Use Cases.

The top-level use case consists of the following Level 1 use cases:

> 1\. Observers
>
> 2\. Modelers
>
> 3\. Collect Measurements
>
> 4\. Model Conditions
>
> 5\. Acquire Data
>
> 6\. Stage Data
>
> 7\. Publish Data
>
> 8\. Manage Storage
>
> 9\. Employ Data
>
> 10\. Users

The Level 1 use cases interact with each other through the following
associations:

> 1\. Institute Data Collections
>
> 2\. Institute Modeling
>
> 3\. Consolidate Collections
>
> 4\. Consolidate Predictions
>
> 5\. Harvest Objective Data
>
> 6\. Access Standardized Data
>
> 7\. Store Information Products
>
> 8\. Route Standardized Data
>
> 9\. Invoke Information Product Storage
>
> 10\. Manipulate Data

The Level 1 use cases and their associations represented in the diagram
are discussed in the paragraphs below, in counterclockwise order
beginning with the Observers and Modelers, and ending with the Users.

### Observers (Actors)

Observers are people and agencies who have roles in setting up
instrumentation systems that sense and record measurements of
environmental conditions in the Observers\' areas of interest. The same
people and agencies also usually have roles as consumers of the data
produced by the systems they have created. When people and agencies are
controlling the operation of the instrumentation systems, they are
defined as Observers in the context of this analysis. Their systems
produce the data used by the ICOOS.

### Institute Data Collections (Association)

Instrumentation functions require management services provided by
Observers. The services consist of actions necessary to establish
regional instrumentation functions, keep the instrumentation functions
operational, define what parameters are collected, and maintain data
archives.

Observers benefit from the measurements collection functions when they
obtain precise descriptions of the variations of targeted conditions.

### Collect Measurements (Use Case)

This includes the archiving of sensor reports as well as the reporting
of sensor outputs in realtime during data feed functions. There are many
regional sites maintaining data archives and reporting realtime in
compliance with their own needs. Consequently, there are many variations
on format, context, units, and other characteristics of the available
data.

### Consolidate Collections (Association)

This is an inflow of data swept up from the regional collection centers
by data acquisition processes. The data streams originate at a multitude
of sites and flow toward the Acquire Data functions. Components of the
data streams vary in format, units, and context. The data streams
include realtime feeds and archived data.

### Modelers (Actors)

Modelers are people and agencies who have roles in setting up modeling
systems that predict environmental conditions in the Modelers\' areas of
interest. The same people and agencies also usually have roles as
consumers of the predictions produced by the systems they have created.
When people and agencies are controlling the operation of the models,
they are defined as Modelers in the context of this analysis. Their
systems produce the predictions data used by the ICOOS.

### Institute Modeling (Association)

Modeling functions require management services provided by Modelers. The
services consist of actions necessary to obtain input data, create the
models, operate the models, maintain the models, define model output
parameters, and maintain data archives.

Modelers benefit from the modeling functions when they obtain precise
predictions (forecasts, nowcasts, and hindcasts) of targeted conditions.

### Model Conditions (Use Case)

Model Conditions functions produce predictions in the form of hindcasts,
nowcasts, and forecasts. There are a variety of agencies using different
kinds of models having various degrees of precision and special
purposes. Consequently, there are variations on format, context, units,
and other characteristics of the available predictions data.

### Acquire Data (Use Case)

A multitude of mixed-content data sources is continuously canvassed by
this process to find data collections consistent with the needs of the
ICOOS. Mixed-content data are placed in a readily accessible storage
area termed \"Data Warehouse\" in their original formats, units, and
contexts

The Data Warehouse is routinely accessed by an ICOOS IIS data integrator
process that homogenizes the mixed-content data into a
standardized-content database.

### Harvest Objective Data (Association)

Mixed-content data residing in the Data Warehouse are accessed by the
ICOOS IIS data integrator process as it constructs and manages the
standardized-content Certified Data Mart. Mixed-content data include
realtime feeds and archived data. The ICOOS IIS data integrator uses
mixed-content data acquired during the most recent 30-day period.

### Stage Data (Use Case)

This use case is principal to discovering requirements for the ICOOS IIS
specification. It is within the scope of the ICOOS IIS Statement of Work
and thus is more fully developed than the use cases summarized above.

SUMMARY.

Mixed-content data up to 30 days old are copied from the Data Warehouse
and integrated into a standardized-content dataset having consistent
formats, units, and contexts. The integrated standardized data are
stored using a relational technique termed \"Certified Data Mart.\"

The integrated standardized dataset is updated frequently to cover the
most recent 30-day period. Data over 30 days old are purged from the
dataset.

The Certified Data Mart responds to incoming data retrieval requests
consistent with OGC standards (WFS, WMC, WCS) and XML SOAP.
Standardized-content data are retrieved in accordance with
specifications carried by the requests and are made available to the
requesting function.

Standardized-content data are also made available to support data feeds.
Data feeds are set up in response to retrieval requests. A separate
request is not required for each periodic retrieval supporting a data
feed. A data feed has a limited lifespan.

The Certified Data Mart also stores User-originated finished information
products resulting from the employment of models, tools, and analyses.
Stored finished products are available through the retrieval process.

USE CASE #1.

Stage Data.

ACTOR(S).

Publish Data, Manage Storage.

DESCRIPTION.

Integrate mixed-content data to form standardized-content datasets.
Maintain and manage the Certified Data Mart for storing
standardized-content data and for accessing the standardized-content
datasets in response to retrieval requests. The Stage Data function
coordinates its activities to service the needs of the Publish Data and
Manage Storage functions.

PRECONDITIONS.

1\. Mixed-content data provided by the Acquire Data functionality have
various formats, units, and contexts. The data do not always conform to
OGC standards.

2\. Some mixed-content data provided by the Acquire Data functionality
are available as feeds.

3\. Some mixed-content data provided by the Acquire Data functionality
are defective or contain erroneous entities and attributes.

4\. Legitimate retrieval request instructions are available from the
Publish Data functionality.

5\. Legitimate storage request instructions accompanying finished
information products are available from the Manage Storage
functionality.

POSTCONDITIONS.

1\. Mixed-content data are integrated into standardized-content data
sets.

2\. The standardized-content datasets are stored in the Certified Data
Mart.

3\. Finished information products are stored.

4\. Standardized-content data are retrieved by the Stage Data
functionality to satisfy requests for data, data feeds, and finished
information products.

5\. Standardized-content data retrieved by the Stage Data functionality
conform to OGC standards.

PRIORITY.

Stage Data is Priority #1. The data integration aspect of this use case
is pivotal to desired operation of the ICOOS.

NORMAL COURSE.

Coordinate internal actions between integrating data and responding to
retrieval and storage instructions.

Periodically access mixed-content data collections in the Data
Warehouse. Copy out mixed-content data that are new since the last
access. Note that the Data Warehouse is the primary data provider to the
Data Mart and can be a distributed entity. Check the mixed-content data
for security and data assurance. Do not copy out data collected more
than 30 days ago. Convert the mixed-content data to standardized-content
units, context, and format. Store the converted data in the
standardized-content relational database. Determine whether or not the
new standardized data goes into a data feed. If the new standardized
data is part of an unexpired data feed, then present the data to the
Publish Data functionality for forwarding to subscribers. Keep track of
active data feeds.

Receive a data retrieval instruction from the Publish Data
functionality. Determine whether or not the retrieval instruction
initiates a data feed. If a feed is specified, then designate the new
standardized-content data to be reported in the feed. Initiate the feed
by presenting the last-reported data to the Publish Data functionality.
If the retrieval instruction calls for data but not as a data feed, then
perform the specified retrieval in the standardized-content database and
provide the \"static\" data to the Publish Data functionality. If the
retrieval instruction calls for a finished information product, then
perform the specified retrieval and provide the information product to
the Publish Data functionality.

Receive a finished information product accompanied by an instruction to
store from the Manage Storage functionality. Store the information
product such that the product can be retrieved in response to User
requests.

ALTERNATIVE COURSES.

1\. Some mixed-content data are OGC compliant and do not require
homogenization.

EXCEPTIONS.

1\. Requested standardized-content data are unavailable due to absence
of mixed-content input data.

2\. Data output by the Stage Data functionality is anomalous.

3\. Mixed-content data are unusable due to errors, corruption, or
infection.

SPECIAL REQUIREMENTS.

1\. Apply security and data assurance practices to ensure the integrity
of mixed-content data from the Acquire Data functionality.

2\. Store data for no longer than 30 days from the time the data is
collected.

3\. Store information products for no longer than 30 days from the time
the products are delivered for storage.

ASSUMPTIONS.

1\. A data feed sends data collected after the time of Stage Data\'s
receipt of the retrieval instruction initiating the feed.

2\. There can be two or more feeds active at the same time.

3\. Finished information products stored in the Certified Data Mart are
ICOOS-specific standardized-content creations.

4\. A data feed has limited lifespan.

5\. The association between Acquire Data and Stage Data is not secure.

6\. The association between Stage Data and Publish Data is secure.

7\. The association between Stage Data and Manage Storage is secure.

### Access Standardized Data (Association)

The Certified Data Mart receives data retrieval requests, performs the
specified retrievals, and makes the retrieved data available for
transmittal to the requesting Users in accordance with OGC standards for
access and retrieval.

### Store Information Products (Association)

This relationship consists of User-generated finished products to be
stored and instructions for storage. Examples of user-generated finished
products are computed data, reports and graphics resulting from modeling
and tool runs.

### Publish Data (Use Case)

This use case is principal to discovering requirements for the ICOOS IIS
specification. It is within the scope of the ICOOS IIS Statement of Work
and thus is fully developed.

SUMMARY.

To distribute standardized-content data to users, Publish Data processes
service user-originated requests (such as queries and subscriptions),
transmittal of retrieved data, and data feeds. Data retrieval
instructions are issued to functions in the Certified Data Mart in
response to arriving data requests. Data requests are not cascaded back
to the Data Warehouse (in the Acquire Data function), data collectors
(in the Collect Measurements function), or modelers (in the Model
Conditions function). Data retrieved from the Certified Data mart are
sent to the users who issued the requests.

The Publish Data processes manage a standardized-content data feed by
receiving a retrieval request for the feed, issuing the initial
retrieval request to the Stage Data functions to set up the feed, and
then forwarding the periodically retrieved data at intervals to users
until the feed expires. There can be two or more feeds active at a time.

USE CASE #2.

Publish Data

ACTOR(S).

Stage Data, Employ Data (multiple instantiations)

DESCRIPTION.

Publish Data functions provide communication interfacing dealing with
retrieving and disseminating integrated standardized-content data. The
functions service the Stage Data processes and a multitude of Employ
Data functional instantiations.

PRECONDITIONS.

1\. Many retrieval requests with a variety of priorities, submission
times, and other quality-of-service properties are available.

2\. Some retrieval requests are defective, infected, or unauthorized.

3\. Integrated standardized-content data are available under management
of the Stage Data functional center.

POSTCONDITIONS.

1\. Retrieved standardized-content data are provided to their respective
Employ Data requestors in compliance with OGC, SOAP, and other
applicable standards.

PRIORITY.

Publish Data is Priority #2. Decisions involving development of Stage
Data (Priority #1) are likely to affect Publish Data functions.

NORMAL COURSE.

Receive a request for standardized-content data. Check the request for
legitimacy and quality-of-service. Check the request for type (such as
data retrieval, information product retrieval, or feed subscription). If
it is for a feed, then set up feed management and pass the feed
retrieval instructions to the Stage Data functions. If it is a (nonfeed)
data request, then pass the retrieval instructions to the Stage Data
functions. If it is an information product request, then pass the
information product retrieval instructions to the Stage Data functions.
Receive retrieved data from the Stage Data functions. Provide the
requested data to the requestor in accordance with appropriate
standards, protocols, and security practices.

ALTERNATIVE COURSES.

No alternative courses of action are identified for the Publish Data
function center to achieve the postconditions.

EXCEPTIONS.

1\. Incoming request is defective.

2\. Incoming request is not authorized.

3\. Data feed is expired.

4\. Requestor is absent at the time of delivery of requested data.

5\. No data is available to satisfy the request.

SPECIAL REQUIREMENTS.

1\. Use OGC standards (WFS, WCS, WMS) and SOAP.

2\. Use web protocols.

3\. Use XML metadata.

ASSUMPTIONS.

1\. The association between Publish Data and Stage Data is secure.

### Manage Storage (Use Case)

This use case is principal to discovering requirements for the ICOOS IIS
specification. It is within the scope of the ICOOS IIS Statement of Work
and thus is fully developed.

SUMMARY.

Manage Storage serves as the feedback route from the Users back to the
Certified Data Mart. It is an interface for administering the storage of
user-generated data and finished products in the Certified Data Mart. It
handles the Users\' requests, finished products to be stored, and
storage instructions.

USE CASE #3.

Manage Storage.

ACTOR(S).

Employ Data (multiple instantiations).

DESCRIPTION.

Provide communication interfacing functions dealing with storing ICOOS
data and finished standardized-content information products that comply
with FGDC metadata requirements. The Manage Storage functions service
the Stage Data processes and a multitude of Employ Data functional
instantiations.

PRECONDITIONS.

1\. Items submitted by Employ Data for storage are ICOOS-specific data
and finished standardized-content information products. All comply with
FGDC metadata requirements and OGC standards.

2\. Some items submitted for storage are defective, infected, or
unauthorized.

POSTCONDITIONS.

1\. Finished information products are ready for and available to the
Stage Data functions for storage in the Certified Data Mart.

PRIORITY.

Manage Storage is Priority #3.

NORMAL COURSE.

Receive products (consisting of finished information products or data)
accompanied by storage requests (metadata) from instantiations of the
Employ Data functions. Check the products and requests for legitimacy
and quality-of-service characteristics consistent with data assurance
practices. Pass the products and storage instructions to Stage Data.

ALTERNATIVE COURSES.

No alternative courses of action are identified for the Manage Storage
function center to achieve the postconditions.

EXCEPTIONS.

1\. Incoming information products are defective.

2\. Incoming storage requests are defective.

3\. The Stage Data functions are unable to service storage requests from
Manage Storage.

SPECIAL REQUIREMENTS.

1\. Use OGC standards.

2\. Use FGDC metadata standards.

ASSUMPTIONS.

1\. The association between Employ Data functions and Manage Storage is
not secure.

2\. The association between Manage Storage and Stage Data is secure.

### Route Standardized Data (Association)

Users issue requests for standardized-content data as they exercise
selections on the human-and-machine interfaces on their computer
terminals. Requests for standardized-content data are converted into
retrieval requests destined for the Certified Data Mart.
Standardized-content data retrieved in accordance with the requests flow
back to the respective Users originating the requests.

Note that some of the flow toward the Users consists of User-generated
finished information products.

This data flow is characterized by the application of national transport
and content standards, particularly SOAP, WCS, WMC, and WFS.

### Invoke Information Product Storage (Association)

Users working through data employment functions issue the results of
studies, analyses, and modeling for storage in the Certified Data Mart.
This flow includes the intermediate and finished data products and the
storage requests. The flow conforms to national transport and content
standards that include SOAP, WCS, WMC, and WFS.

Finished products are stored for 30 days.

### Employ Data (Use Case)

This functionality includes controls that provide the User with access
to models, tools, and other services for manipulating and presenting
data during examination.

The functions support Users in requesting data, generating finished
information products, and requesting storage of the products. Outgoing
requests containing specifications for data and services are routed to
the appropriate supporting functional centers that are able to provide
the data and services. Some requests are accompanied by finished
products to be stored in the Certified Data Mart.

Delivered data, including User-originated intermediate and finished
products retrieved from the Certified Data Mart, are received by a
multitude of user terminals in accordance with the parameters of the
Users\' original requests. Standardized data provided by the Certified
Data Mart include static data acquired in the last 30 days and periodic
updates via data feeds.

### Manipulate Data (Association)

Users manipulate the presented data by invoking models, tools,
applications, and other service agents to operate on or with the data.
This association includes the Users perceiving presented data and
initiating requests for data and data-handling services.

Note that \"requested services\" of the previous paragraph include
web-based services provided from physical locations remote from the
Users\' terminals.

### Users (Actors)

Users are responsible for evaluating delivered ICOOS data for meaning in
the context of human interests. Delivered data are evaluated by a
multitude of human operators using applications, models, and tools to
generate information, derive conclusions, and determine courses of
action. Users create finished standardized-content information products
for storage and redistribution to other Users via the ICOOS. Users
operate the ICOOS by initiating requests for data, finished products,
and services and by submitting finished products for storage.

# ICOOS Data Source Classes

The kinds of things that the ICOOS IIS deals with are discussed in this
section. Similar things, or "objects," are grouped into categories
called "classes." This section focuses on the Level 1 analysis view,
which depicts policies and processes as classes of objects constituting
the business model of the ICOOS IIS. Figure 2-2 (below) and Figure 3-3
(in the next section) graphically depict the classes arranged to show
how they relate to one another. All Level 1 classes shown in Figure 2-2
are external to the ICOOS IIS. Level 1 classes internal to the ICOOS IIS
are shown in Figure 3-3.

All classes shown in Figure 2-2 generate data managed by the Data Mart.
The Level 1 classes of objects shown as blocks in Figure 2-2 are:

> 1\. Condition
>
> 2\. Sensor
>
> 3\. Measurement
>
> 4\. Data Collection Package
>
> 5\. Observation
>
> 6\. Station
>
> 7\. Benchmark
>
> 8\. Parameter
>
> 9\. Prediction
>
> 10\. Forecast
>
> 11\. Model
>
> 12\. Data Warehouse
>
> 13\. Web Page
>
> 14\. Web Page Interface
>
> 15\. OPeNDAP

Items 1 through 7 generate actual observation measurements data. Items 8
through 11 generate predicted observations. Items 12 through 15
transport observations (actual and predicted) to the Data Mart.

Characteristics of each class that are of interest to the ICOOS IIS are
listed within each block. These characteristics are called
\"attributes,\" and most are data items recorded in the ICOOS IIS Data
Mart.

The classes are associated with one another through the following
relationships:

> 1\. Stimulates (members of the Condition Class stimulate members of
> the Sensor Class)
>
> 2\. Creates (#1) (the Sensor Class creates members of the Measurement
> Class in response to stimulation caused by the conditions being
> monitored)
>
> 3\. Provides Measurements to (the Sensor Class provides members of the
> Measurement Class to the Data Collection Package Class)
>
> 4\. Assembles (#1) (the Data Collection Package Class uses
> measurements to assemble members of the Observation Class)
>
> 5\. Provides Observations to (the Data Collection Package Class
> provides members of the Observation Class to the Station Class)
>
> 6\. Is Coordinate System for (the Benchmark Class provides the
> positioning reference for members of the Station Class)
>
> 7\. Supplies Observations to (the Station Class uses its
> communications functions to transmit members of the Observation Class
> to the Data Warehouse Class)
>
> 8\. Calculates (instantiations of the Model Class use instantiations
> of the Parameter Class in algorithmic processing)
>
> 9\. Creates (#2) (the Model Class creates Predictions using members of
> the Parameter Class)
>
> 10\. Assembles (#2) (the Model Class constructs members of the
> Forecast Class using Predictions)
>
> 11\. Provides Forecasts to (the Model Class makes its output forecasts
> available to the Data Warehouse Class)
>
> 12\. Builds (Data Warehouse Class members create web pages as
> \"vehicles\" for sending observation data to users)
>
> 13\. Constructs (Data Warehouse Class members generate data files
> consistent with the OPeNDAP framework for sending observation data to
> users)
>
> 14\. Web Page Interface (the Data Warehouse Class provides web pages
> containing embedded observation data to the ICOOS IIS Data Mart)
>
> 15\. OPeNDAP (the Data Warehouse Class provides geospatial data to the
> ICOOS IIS Data Mart using processes recorded in the OPeNDAP framework.

![](media/image2.wmf)

[]{#__RefHeading___Toc137959381 .anchor}Figure 2‑2. ICOOS Data Source
Classes.

## Condition (Class)

The Condition Class consists of physical phenomena that are external to,
and are being monitored by, the human-created observation system. A
Condition is detected and quantized by its effect on a sensor\'s
detection mechanism.

Examples:

Some conditions targeted for monitoring by the ICOOS IIS are wind, water
levels, air temperature, air pressure, water pressure, water
temperature, water currents, salinity, and wave frequency.

### Variability (Condition Attribute)

Variability pertains to changes of the conditions. Agencies sponsoring
the observation system are interested in observing the changes. The
mission of the observation system is to detect and quantize the changes
occurring in monitored conditions to increase awareness of developing
situations in human observers.

Example:

Awareness of water level changes enable coastal managers to estimate the
effect of storm surge on coastal infrastructure using the animated
inundation model at http://photojournal.jpl.nasa.gov/catalog/PIA06674.

## Stimulates (Association)

A monitored condition stimulates a sensor by applying a change through
temperature, force, conductivity, or other physical agent.

## Sensor (Class)

The Sensor Class includes all instruments that measure prevailing
conditions.

A sensor consists of a detection mechanism, a protective enclosure
providing structure and attachment points, and a means for conveying its
measurements to the DCP computer.

Examples:

1\. Devices for measuring conditions include anemometers, barometers,
water pressure transducers, acoustic water level sensors, rain gages,
and sensors for temperature, humidity, salinity, ocean current speed and
direction, stream flow, insolation, and waves.

2\. A comprehensive list of sensors used on NDBC stations is provided at
http://www.ndbc.noaa.gov/instr.shtml.

### Sensor Type (Sensor Attribute)

Sensor Type indicates the instrument\'s measurement domain.

Examples:

1\. Anemometers measure wind speed and direction.

2\. Barometers measure atmospheric air pressure.

### Short Name (Sensor Attribute)

The Short Name is the alphanumeric designator of a \"billet\" (or job
opening) that can be filled by the appropriate type of sensor in a data
collection package (DCP).

Example:

The CO-OPS station Port Fourchon, LA (# 8762075) has a position for a
backup water level sensor called \"B1\"
(http://140.90.121.76/data_retrieve.shtml?input_code=011011111pwl&station=8762075+Port+Fourchon,+LA).
Lack of data indicates that this billet is unoccupied or is not
operational.

### Long Name (Sensor Attribute)

The Long Name is the sensor\'s full formal catalog nomenclature.

Example:

The long name for an anemometer is \"WM30 Wind Sensor\" described at
http://www.vaisala.com/businessareas/instruments/products/wind.

### Elevation (Sensor Attribute)

Elevation is the vertical position of the sensor relative to the
station\'s datum.

Examples:

1\. The COMPS nearshore tower \"N.W. Florida Bay\" has two anemometers
18 feet above MHHW (http://comps1.marine.usf.edu/nfb/instr.html).

2\. The NDBC 3-meter discus buoy \"42039 Pensacola\" measures sea
temperature at the depth of 0.6 m below the site\'s sea level elevation
(http://www.ndbc.noaa.gov/station_page.php?station=42039).

### Description (Sensor Attribute)

The Description is a multi-word word prose text that presents pertinent
facts about the sensor. It may include history, design configuration,
maintenance status, siting rationale, operating principles, and any
other topic relevant to the sensor.

Example:

The COMPS nearshore tower Station Homossassa (#43) describes its
anemometer at http://comps1.marine.usf.edu/hom/instr.html.

### Manufacturer (Sensor Attribute)

Manufacturer is the name of the sensor\'s builder.

Example:

The COMPS nearshore tower Station Homossassa (#43) states that its
anemometer is built by R.M. Young
(http://comps1.marine.usf.edu/hom/instr.html) and provides the URL to
the R.M. Young catalog.

### Part Number (Sensor Attribute)

Part Number is the manufacturer\'s model number of the sensor.

Example:

The COMPS nearshore tower Station Homossassa (#43) states that its
anemometer is R.M. Young Model 05106
(http://comps1.marine.usf.edu/hom/instr.html).

### Owner (Sensor Attribute)

Owner is the agency responsible for the maintenance and operation of the
sensor.

Example:

The COMPS nearshore tower Station Homossassa (#43) states that it has
two responsible agencies, USF and Citrus County
(http://comps1.marine.usf.edu/hom/index.shtml).

### Calibration (Sensor Attribute)

Calibration is the calibration history of the sensor.

Example:

NDBC states that sensor calibration is performed on its sensors at a
shorebased maintenance facility after two years in service
(http://www.ndbc.noaa.gov/instr.shtml).

### Operational Status (Sensor Attribute)

Operational Status consists of key parameters that indicate the ability
of the sensor to perform its mission.

Example:

Usually, the operational status is indicated by the presence or absence
of reported data from a sensor known to be onboard a station. The
discovery of a non-operating sensor is often by the owner\'s QC process.
The maintenance messages for the TCOON station \"016: Sabine Pass\"
(http://lighthouse.tamucc.edu/message/016) reveal how a balky water
level sensor\'s operational status is monitored by watching for gaps and
flatlines.

## Creates (#1) (Association)

A Sensor generates a Measurement when it outputs a signal proportional
to the magnitude of the original stimulant.

## Measurement (Class)

A measurement consists of an information item reporting a quantified
signal representing the magnitude of a monitored condition. A
measurement becomes an \"observation\" when it is associated with a
specific time.

Examples:

1\. Commonly known measurements are air pressure, relative humidity, air
temperature, water temperature, wind direction, water height,
insolation, compass directions, sensor acceleration, vibration
frequency, slope, magnetic field strength, salinity, rainfall, angular
velocity, wind speed, weight, gravity field strength, nuclear radiation
flux, strain, deflection, and visibility.

2\. Measurements collected by NDBC sensor packages and their
specifications (such as accuracy, resolution, and range) are presented
at http://www.ndbc.noaa.gov/rsa.shtml.

### Name (Measurement Attribute)

The Name identifies the measurement.

Examples:

Common names for some frequently-collected measurements are air
pressure, relative humidity, air temperature, water temperature, wind
direction, water height, insolation, compass directions, sensor
acceleration, vibration frequency, slope, magnetic field strength,
salinity, rainfall, angular velocity, wind speed, weight, gravity field
strength, nuclear radiation flux, strain, deflection, and visibility.

### Description (Measurement Attribute)

The Description is a multi-word word prose text that presents pertinent
facts about the measurement. It may include method, range, constraints,
units, interaction of physical properties, limitations, interesting
variations, biasing factors, history, interference factors, and any
other topic relevant to the measurement.

### Resolution Minimum (Measurement Attribute)

The Resolution Minimum is the lower bound of the specified range of the
measurement\'s resolution.

Example:

Resolution is the smallest change that can be detected by an instrument.
Resolution is stated as a range between a minimum and a maximum in the
instrument\'s specification requirement.

### Resolution Maximum (Measurement Attribute)

The Resolution Maximum is the upper bound of the specified range of the
measurement\'s resolution.

Example:

Resolution is the smallest change that can be detected by an instrument.
Resolution is stated as a range between a minimum and a maximum in the
instrument\'s specification requirement.

### Precision (Measurement Attribute)

Precision is a measure of the repeatability of a measurement. It is
stated as the \"coefficient of variance.\" A low coefficient of variance
means that repeated measurements of the same condition are close to the
same value.

Reference:

Precision and accuracy are explained on the Student Watershed Research
Project website
http://www.swrp.org/Student_Presentations/Preparation/Poster/posterstats.html.

### Limits (Measurement Attribute)

Limits are the upper and lower bounds of the measurement range.

Example:

The limits for wind speed measurements at 10 feet above the Earth\'s
surface in an open area clear of tall obstacles are 0 mph for the lower
limit and 250 mph for the upper limit.

### Units (Measurement Attribute)

Units consist of the components of a standard system of measure that
express the measurement. Sometimes a measurement is made in one set of
units but reported by the station in another set of units.

Example:

Typical units for wind speed are meters per second and miles per hour.

### Indication (Measurement Attribute) 

The Indication is the quantity reported by a sensor at each instant.

Example:

A digital backyard thermometer continuously senses the ambient air
temperature and reports the measurement on its electronic liquid-crystal
display as an indication.

## Provides Measurement to (Association)

A Sensor continuously indicates a quantitative magnitude (the
measurement) to the computer managing the Data Collection Package.

## Data Collection Package (Class)

A Data Collection Package (DCP) is an equipment entity defined on the
basis of one or more special differentiating characteristics, like
owner-operator, configuration, mounting location, or multiplicity, among
others. There can be one or more DCP\'s residing on a station.

A DCP normally consists of a computer and sensor suite. The computer
collects data, manages sensors, and provides data to the communications
services onboard the station. The instruments in the sensor suite
collect measurements and report them to the DCP computer, where they may
be operated on to prepare them for recording in an observation.

Examples:

1\. A buoy can have two DCP\'s: one is the meteorological package above
the hull, and the other is a subsurface pressure sensor package near the
bottom end of the buoy\'s anchor chain. The NOAA website
http://www.ndbc.noaa.gov/Dart/dart.shtml shows a 2-package station. One
DCP is the communications buoy with its weather sensors, the other is
the DART tsunami detector.

2\. A buoy usually only has one DCP. The website
http://www.ndbc.noaa.gov/wstat.shtml indicates the type of Data
Collection Package used on each station in the Hull No./Configuration
column.

### DCP Name (DCP Attribute)

The DCP Name designates the package by type, owner, project,
multiplicity, or other characteristic.

Examples:

1\. DART is the package fielded by the Deep-ocean Assessment and
Reporting of Tsunamis system (http://www.ndbc.noaa.gov/Dart/dart.shtml).

2\. Other packages hosted by NDBC buoys and C-MAN shore stations are
ARES, MARS, DACT, GSBP, and VEEP (http://www.ndbc.noaa.gov/rsa.shtml).
NDBC calls them \"payloads.\"

3\. CO-OPS stations report the package name as a single character
identifier in the \"platform\" column of the station inventory
(http://140.90.121.76/cgi-bin/co-ops_qry_direct.cgi?stn=8770570+Sabine+Pass+North%2C+TX&dcp=1&ssid=WL&pc=W1&datum=INV3&unit=0&bdate=20051101&edate=20051101&date=1&shift=0&level=-4&form=0&host=&addr=130.76.32.144&data_type=vci&format=View+Data).

### Description (DCP Attribute)

The Description contains multi-word word prose text that presents
pertinent facts about the DCP. It may include history, design
configuration, maintenance status, siting rationale, operating
peculiarities, and any other topic relevant to the package.

Examples:

1\. Descriptions for the various NDBC data collection packages are given
in terms of reported data at http://www.ndbc.noaa.gov/rsa.shtml.

2\. DART platforms are described at
http://www.ndbc.noaa.gov/Dart/dart.shtml using text and diagrams.

### Owner (DCP Attribute)

The Owner of a DCP is the agency responsible for the DCP\'s operation.

Examples:

1\. The C-MAN station \"VENF1 - Venice, FL\" is equipped with a MARS
payload (http://www.ndbc.noaa.gov/station_page.php?station=venf1). The
station\'s website states that NDBC is the owner-operator.

2\. A DCP owned by one party can be a \"tenant\" on a station owned by
another party. NWS owns weather platforms mounted on oil rigs owned by
commercial businesses.

Operational Status (DCP Attribute)

Operational Status reports the readiness of the data collection package
to perform its mission.

Example:

DCP\'s have onboard computers that can monitor and report on operation
of their components. The TCOON station configuration description at
http://lighthouse.tamucc.edu/Main/StationConfiguration shows a Sutron
9000 used to control sensors, collect data, and communicate telemetry.

## Assembles (#1) (Association)

The Data Collection Package creates an observation when it records
measurements from its sensors at a certain time.

## Observation (Class) 

The Observation Class consists of all observations generated by the DCP.

An observation is created when a measurement is coupled to a time
statement.

Example:

A thermal sensor continuously produces measurements of water
temperature. An observation is created when the DCP computer records the
temperature for a particular time.

### Short Name (Observation Attribute)

The Short Name is a shorthand indication of the specific observation
entity. It is normally an abbreviation.

Example:

There are two observations that deal with wind speed: average speed and
maximum speed. NDBC uses \"WSPD\" for average wind speed and \"GST\" for
the maximum (gust) speed at its website for the 3-meter discus buoy
\"North Mid Gulf of Mexico,\" Station 42038
(http://www.ndbc.noaa.gov/station_page.php?station=42038).

### Long Name (Observation Attribute)

The Long Name is the multi-word prose name of the specific observation..

Example:

Long names for the wind speed observations WSPD and GST are \"wind
speed\" and \"wind gust\" respectively
(http://www.ndbc.noaa.gov/measdes.shtml).

### Description (Observation Attribute)

The Description is prose text that presents pertinent facts about the
observation. It may include the definition of the observation, the
algorithmic process, interpretation constraints, and any other topic
relevant to the observation.

Example:

NDBC provides a comprehensive listing of descriptions at
http://www.ndbc.noaa.gov/measdes.shtml.

### Period (Observation Attribute)

The Period is the time interval between observations.

Example:

Observation intervals are stated as part of the data inventory listing
for the CO-OPS station \"8771341 Galveston Bay Entrance, North Jetty,
TX\"
(http://140.90.121.76/cgi-bin/co-ops_qry_direct.cgi?stn=8771341+Galveston+Bay+Entrance%2C+North+Jetty%2C+TX&dcp=1&ssid=WL&pc=W1&datum=INV3&unit=0&bdate=20051201&edate=20051201&date=1&shift=0&level=-4&form=0&host=&addr=130.76.32.23&data_type=vci&format=View+Data).

### Date (Observation Attribute)

The Date consists of year, month, and day of the observation.

Example:

The website for the NDBC 3-meter discus buoy \"Station 42039 -
PENSACOLA - 115NM East Southeast of Pensacola, FL\" reports its realtime
observations in the format Month/Day/Year
(http://www.ndbc.noaa.gov/station_page.php?station=42039).

### Time (Observation Attribute)

The Time of the observation is in hours, minutes, seconds, and time
zone.

Example:

The website for the NDBC 3-meter discus buoy \"Station 42039 -
PENSACOLA - 115NM East Southeast of Pensacola, FL\" offers several
formats for the clock time, including 24-hour, and in a variety of time
zones (http://www.ndbc.noaa.gov/station_page.php?station=42039).

### Reading (Observation Attribute) 

The Reading is the record of the measured quantity at the observation
time.

Example:

Realtime readings for the sensors onboard the NDBC 3-meter discus buoy
\"Station 42039 - PENSACOLA - 115NM East Southeast of Pensacola, FL\"
are displayed with the long names and short names in a special dedicated
table on the web page
(http://www.ndbc.noaa.gov/station_page.php?station=42039).

## Provides Observations to (Association)

The Data Collection Package transfers its observations to the Station
for transmittal to the Data Warehouse. The Station owns one or more
communication services having the ability to deliver the observations.

## Station (Class)

The Station Class consists of fixed and mobile physical entities.

A station is made up of structure, power supply, communication system,
and sometimes a mobility system (as with robotic buoys and aircraft) and
onboard control system. Sensors and DCP\'s are mounted on the station\'s
structure.

Examples:

1\. Some fixed stations are shorebased towers and moored buoys.

2\. Some mobile stations are ships, aircraft, satellites, and unmoored
robotic buoys.

### Type (Station Attribute)

Type refers to a station\'s basing mechanism. A station\'s type is
typically stated on its website and is frequently accompanied by a
photograph.

Example:

Some station types are: shorebased tower, offshore based tower,
shorebased platform, moored buoy, mobile (robotic) buoy, aircraft, ship,
satellite, and land vehicle.

### Short Name (Station Attribute)

The Short Name is the alphanumeric sequence code unique to each
particular station. A station\'s Short Name is equivalent to its
\"Station ID\" on observation system websites. Note that a station
sometimes has several different short names assigned by different
collection systems

Examples:

1\. 42003 is the short name for the NDBC 6-meter boathull buoy \"E
GULF.\"

2\. SGOF1 is the short name for the C-MAN offshore tower \"Tyndall AFB
Tower C (N4).\"

3\. The station known as \"Port O\'Connor\" is known as \"057\" by TCOON
and as \"PCNT2\" by NDBC (http://lighthouse.tamucc.edu/overview/057).

4\. NDBC explains how IDs are created
(http://www.ndbc.noaa.gov/staid.shtml).

5\. NDBC lists buoy and shore station short names as \"station IDs\"
(http://www.ndbc.noaa.gov/wstat.shtml).

### Long Name (Station Attribute)

The Long Name is a station\'s formal name. It usually consists of a
multi-word phrase that includes the place name of a nearby cultural
feature. Note that a station sometimes has several different long names
assigned by different collection systems

Examples:

1\. The long name for the NDBC C-MAN shorebased tower KTNF-1 is \"Keaton
Beach, FL\" (http://www.ndbc.noaa.gov/station_page.php?station=KTNF1).

2\. The long name for the COMPS 3-meter moored discus buoy 42021 is
\"Pasco County Buoy, FL\"
(http://www.ndbc.noaa.gov/station_page.php?station=42021).

3\. TCOON\'s shorebased tower \"057 - Port O\'Connor\" is known as
\"Station PCNT2 - 057: Matagorda Bay; Port O\'Connor, TX\" by NDBC
(http://www.ndbc.noaa.gov/station_page.php?station=pcnt2 and
http://lighthouse.tamucc.edu/overview/057).

### Latitude (Station Attribute)

Latitude is one element of a station\'s position in space and time
(given by latitude, longitude, elevation, and time).

Example:

The location for the landbased weather tower \"Galveston Scholes Field\"
(Station 413430), is given on its website as geographic
latitude-longitude in degrees and minutes, and elevation as meters above
sea level
(http://www4.ncdc.noaa.gov/cgi-win/wwcgi.dll?wwDI\~StnSrch\~StnID\~20024352).

### Longitude (Station Attribute)

Longitude is one element of a station\'s position in space and time
(given by latitude, longitude, elevation, and time).

Example:

The location for the landbased weather tower \"Galveston Scholes Field\"
(Station 413430), is given on its website as geographic
latitude-longitude in degrees and minutes, and elevation as meters above
sea level
(http://www4.ncdc.noaa.gov/cgi-win/wwcgi.dll?wwDI\~StnSrch\~StnID\~20024352).

### Elevation (Station Attribute)

Elevation is one element of a station\'s position in space and time
(given by latitude, longitude, elevation, and time).

Examples:

1\. The location for the landbased weather tower \"Galveston Scholes
Field\" (Station 413430), is given on its website as geographic
latitude-longitude in degrees and minutes, and elevation as meters above
sea level
(http://www4.ncdc.noaa.gov/cgi-win/wwcgi.dll?wwDI\~StnSrch\~StnID\~20024352).

2\. Site elevations plus heights of certain sensors above MSL are listed
for NDBC stations at http://www.ndbc.noaa.gov/bmanht.shtml.

### Date (Station Attribute)

This is the date of the reporting time. Date consists of year, day, and
month.

Example:

The shorebased tower \"057 - Port O\'Connor\" (TCOON Station 057)
reports all time components except year and seconds for each measurement

(http://lighthouse.tamucc.edu/overview/057).

### Time (Station Attribute)

This is the reporting time. Time consists of hours, minutes, seconds,
and time zone.

Examples:

1\. The shorebased tower \"057 - Port O\'Connor\" (TCOON Station 057)
reports all time components except year and seconds for each measurement
(http://lighthouse.tamucc.edu/overview/057).

2\. Data acquisition time information for NDBC stations is available at
http://www.ndbc.noaa.gov/measdes.shtml.

### Description (Station Attribute)

The Description is a multi-word word prose text that presents pertinent
facts about the station. It may include history, design configuration,
maintenance status, siting rationale, operating peculiarities, and any
other topic relevant to the station.

Example:

The text titled \"Site notes\" describes the shore based COMPS Station
\"Tarpon Springs\" at http://comps1.marine.usf.edu/tas/index.shtml. Web
descriptions often include photos.

### Operating Agency (Station Attribute)

Operating Agency is the name of the organization that owns and maintains
the station.

Example:

The NDBC website states that the shorebased tower \"Big Carlos Pass,
FL\" is owned and operated by the University of South Florida. BGCF1 is
the station\'s NDBC short name, BCP is its COMPS short name.
(http://www.ndbc.noaa.gov/station_page.php?station=BGCF1).

### Operating Status (Station Attribute)

Operating Status contains information on availability of a station\'s
infrastructure to support onboard data collection and reporting
functions. Station infrastructure includes power supply, communications
availability, and structure.

Examples:

1\. Station operating status is indicated by single-letter codes by
sensor data types at http://www.ndbc.noaa.gov/wstat.shtml.

2\. Station battery voltage is reported graphically for the TCOON
station \"057: Port O\'Connor\" at http://lighthouse.tamucc.edu/qc/057.

### URL (Station Attribute)

A station\'s data are accessible through a unique URL. The URL provides
connectivity to a data warehouse storing the station\'s data.

Example:

Sometimes a station\'s data are available at a warehouse but not through
the station\'s owner. Data from WAVECIS stations are available through
the NDBC website http://www.ndbc.noaa.gov/Maps/WestGulf_inset.shtml but
not on their home website http://www.wavcis.lsu.edu/ unless the
requestor has special permission.

### Benchmarks (Station Attribute)

Benchmarks are physical survey monuments (usually metallic disks)
fastened to the ground. They are associated with shorebased stations to
establish the local datum for the station\'s onboard instrumentation. A
station often has two or more associated benchmarks.

Examples:

1\. The CO-OPS shore station \"Sabine Pass North\" (8770570) reports
several benchmarks in its vicinity
(http://140.90.121.76/benchmarks/8770570.html).

2\. Several websites report that Gulf Coast benchmarks need periodic
resurveying because the land surface is subsiding at a geologically
rapid rate.

3\. Benchmarks are being resurveyed in conjunction with implementation
of the new 1983-2001 Epoch, according to
http://140.90.121.76/bench_mark.shtml?region=la (see also the \"Epoch\"
attribute for this Station Class).

### Benchmark Offset (Station Attribute)

Benchmark Offset is the vertical difference between a station\'s datum
and the nearby surveyed benchmark.

Example:

The TCOON nearshore tower \"031: Seadrift\" reports that the offset
between station\'s local datum and its Primary Bench Mark (PBM) 90031A
is 1.125 meters (http://lighthouse.tamucc.edu/illus/031).

### Horizontal Datum (Station Attribute)

Horizontal Datum indicates the baseline coordinate system to which the
station\'s instruments are referenced. A horizontal datum is used in
locating the station by 2-dimensional surface coordinates like latitude
and longitude.

### Vertical Datum (Station Attribute)

The Vertical Datum indicates the baseline vertical coordinate system to
which the station\'s instruments are referenced for reporting elevation.

Example:

The TCOON station \"018: Port Isabel\" (NDBC Station PTIT2 - 8779770)
relates its vertical station datum to several elevation standards at its
website (http://lighthouse.tamucc.edu/datum/018).

### Tidal Epoch (Station Attribute)

Tidal Epoch reports the National Tidal Data Epoch (NTDE) being used by
the station at the time of the reported measurements. The CO-OPS website
says, \"The NTDE is a specific 19-year period over which tide
observations are taken to determine Mean Sea Level and other tidal
datums such as Mean Lower Low Water and Mean High Water. This latest
update will define the 19-year period as 1983-2001.\"

Examples:

1\. CO-OPS stations are in the process of being updated to a new NTDE in
2006. Some are reporting in the obsolete NTDE, some are reporting in the
new NTDE. A description of the process resides at
http://140.90.121.76/datum_update.shtml. A list of stations being
updated is available through a selection on the website
http://140.90.121.76/data_res.html.

2\. TCOON station \"017: Port Mansfield\" provides a graphic showing the
various datums and its primary benchmark, and cites the 1983-2001 Epoch
as current at its website http://lighthouse.tamucc.edu/overview/017
(scroll to \"Primary Water Level\" and click on \"click here for
diagram\").

## Is Coordinate System Reference for (Association)

Benchmarks establish the position control grid for relating a station to
all other features on the Earth\'s surface. The station\'s location is
precisely surveyed relative to one or more benchmarks.

## Benchmark (Class)

The Benchmark Class consists of surveyed geodetic points on the Earth\'s
surface used to establish latitude, longitude, and elevation of
observation stations.

A benchmark is usually a metal alloy disk set into the ground on a firm
fixed foundation embossed with identification information. The position
of its center is precisely and accurately known.

Examples:

1\. Photographs of a brass marker are part of the benchmark installation
instructions at
http://www.pwrc.usgs.gov/set/installation/InstallROD.html.

2\. A closeup color photograph of the primary benchmark for the TCOON
Station 031, Sabine Pass, is online at
http://lighthouse.tamucc.edu/dnrpub/stnpics/sabine/bm0570Ea-016-081202.jpg.
The description attribute for this class cites the same benchmark.

### Name (Benchmark Attribute)

The Name is the alphanumeric stamping on the benchmark disk.

Examples:

1\. The stamping for the primary benchmark for the CO-OPS shorebased
station \"Shell Point, West Bay Florida\" (Station 8729169) is 9169 A
1976 (http://140.90.121.76/benchmarks/8729169.html).

2\. The stamping for the primary benchmark for the TCOON nearshore tower
\"031 - Seadrift\" is 90031 A
(http://lighthouse.tamucc.edu/bmarks/031?-action=showmark&markid=031.000).

### Description (Benchmark Attribute)

The Description is prose text that presents pertinent facts about the
benchmark. This includes nearby landmarks, mounting details, access
instructions, URL to the NGS PID reference (if available), and any other
topic relevant to the benchmark.

Example:

Benchmarks used to locate Station 8770570, Sabine Pass North, are
described at http://140.90.121.76/benchmarks/8770570.html.

### Latitude (Benchmark Attribute)

Latitude is one element of a benchmark\'s location on the Earth\'s
surface (given by latitude, longitude, and elevation).

Example:

The latitude of the primary benchmark for Sabine Pass is 29deg 43.8min
north (http://140.90.121.76/benchmarks/8770570.html).

### Longitude (Benchmark Attribute)

Longitude is one element of a benchmark\'s position in the Earth\'s
surface (given by latitude, longitude, and elevation).

Example:

The longitude of the primary benchmark for Sabine Pass is 93deg 52.2min
west (http://140.90.121.76/benchmarks/8770570.html).\\

### Elevation (Benchmark Attribute)

Elevation is one element of a benchmark\'s position on the Earth\'s
surface (given by latitude, longitude, and elevation).

Example:

Elevation data for the Sabine Pass station is accessed through its
benchmark website http://140.90.121.76/benchmarks/8770570.html using the
URL for the PID# AV1014. The elevation is stated as the vertical
distance from the geoid.

## Supplies Observations to (Association)

A station periodically reports its collected observations to a data
warehouse for archiving. The data warehouse buffers the station by
servicing users\' requests for the station\'s data from the archive.

## Calculates (Association)

A Model uses algorithms to compute Parameters while simulating
environmental conditions.

## Parameter (Class)

The Parameter is the measurable environmental property whose
quantification is predicted by the forecasting model.

The Parameter becomes a prediction (or, \"predicted observation\") when
it is associated with a specific time for a forecast.

Parameters correlate with realworld measurements.

### Name (Parameter Attribute)

The Name identifies the parameter.

### Description (Parameter Attribute)

The Description is a multi-word word prose text that presents pertinent
facts about the parameter. It may include method, range, constraints,
units, interaction of physical properties, limitations, interesting
variations, biasing factors, history, interference factors, generating
algorithms in the forecast model, and any other topic relevant to the
parameter.

### Limits (Parameter Attribute)

Limits are the upper and lower bounds of the parameter range.

Example:

The limits for modeled wind speed parameters at 10 feet above the
Earth\'s surface in an open area clear of tall obstacles are 0 mph for
the lower limit and 250 mph for the upper limit.

### Units (Parameter Attribute)

Units consist of the components of a standard system of measure that
express the parameter\'s quantity.

Example:

Typical units for wind speed are meters per second and miles per hour.

### Quantity (Parameter Attribute)

The Quantity is the number calculated by the forecast model\'s
algorithms for a parameter at each time step.

## Creates (#2) (Association)

The Model assembles a prediction when it records quantities stored in
its parameters for a certain time.

## Prediction (Class)

The Prediction Class consists of all predictions generated by the
forecast model.

A Prediction is created when a parameter is coupled with a time
statement.

### Short Name (Prediction Attribute)

The Short Name is a shorthand indication of the specific prediction
entity. It is normally an abbreviation.

### Long Name (Prediction Attribute)

The Long Name is the multi-word prose name of the specific predicted
observation.

### Description (Prediction Attribute)

The Description is prose text that presents pertinent facts about the
predicted observation. It may include the definition of the prediction,
the algorithmic process, interpretation constraints, and any other topic
relevant to the prediction.

### Period (Prediction Attribute)

The Period is the time interval between predicted observations.

### Date (Prediction Attribute)

The Date consists of year, month, and day of the predicted observation.

### Time (Prediction Attribute)

The Time of the predicted observation is in hours, minutes, seconds, and
time zone.

### Value (Prediction Attribute)

The Value is the record of the predicted quantity contained in a
parameter at the observation time.

## Forecast (Class)

The Forecast reports on conditions expected to occur in the future. It
consists of predicted observations over a region for specific conditions
at time intervals into the future and may include prose description,
graphics, photography, and other presentation techniques.

### Name (Forecast Attribute)

The Name identifies the forecast.

### Description (Forecast Attribute)

The Description is a multi-word word prose text that presents pertinent
facts about the forecast. It may include method, range, constraints,
units, interaction of physical properties, limitations, interesting
variations, biasing factors, history, interference factors, and any
other topic relevant to the forecast.

### Region (Forecast Attribute)

The Region is the geospatial volume covered by the forecast.

### Type (Forecast Attribute)

A forecast\'s Type pertains to its domain. Domains include winds, water
level, precipitation, barometric pressure, and over 100 additional
parameters.

### Date (Forecast Attribute)

This is the date to which the forecast applies. Date consists of year,
day, and month.

### Time (Forecast Attribute)

This is the time for which the forecast applies. Time consists of hours,
minutes, seconds, and time zone.

### Run Time (Forecast Attribute)

The Run Time is when the forecast is generated.

### Grid Resolution (Forecast Attribute)

The Grid Resolution is the distance between the regularly-spaced
locations for which predictions are produced by the model.

Example:

The RUC has two grid resolutions: 13 km and 20 km
(http://rapidrefresh.noaa.gov/).

### URL (Forecast Attribute)

A forecast\'s predicted observations data are accessible through a
unique URL. The URL provides connectivity to a data warehouse storing
the forecast\'s data.

### Status (Forecast Attribute)

A forecast\'s Status contains information on availability of the
predictions designed into the forecast. Forecasts are sometimes
incomplete, not available, or compromised in some way due to factors
affecting the model\'s performance.

### Advisory (Forecast Attribute)

Forecasts sometimes contain warnings of certain types of predicted
conditions.

## Model (Class)

Instantiations of the Forecast Model Class predict observable conditions
for discrete time intervals into the future. Forecast models produce
predicted observations.

### Model Name (Model Attribute)

The Model Name is the unique formal title of the entity performing the
modeling process.

Examples:

1\. North American Mesoscale (NAM)

2\. Rapid Update Cycle (RUC)

3\. Global Forecast System (GFS)

### Modeling Agency (Model Attribute)

The Modeling Agency is the organization operating the model to produce
predicted observations.

Example:

The National Center for Environmental Prediction (NCEP) runs the Rapid
Update Cycle numerical weather prediction model.

### Description (Model Attribute)

The Description is an overview of the model\'s mission.

Example:

The RUC provides frequently updated short-range weather forecasts within
the US for aviation and severe weather forecast users.

Additional descriptions are available through the RUC information
website at http://rapidrefresh.noaa.gov/.

### Extent (Model Attribute)

The Extent is the region for which the model generates predictions.

Examples:

1\. The RUC operates for the continental United States.

2\. The GFS is worldwide.

### Update Frequency (Model Attribute)

The Update Frequency is how often the model is operated to generate
predictions.

Example:

The RUC\'s update frequency is every 3 hours for forecasts out to 12
hours (http://rapidrefresh.noaa.gov/).

### Run Time (Model Attribute)

The Run Time is when the model was last run to generate the current set
of predictions.

### Forecast Range (Model Attribute)

The Forecast Range is the time from the run time to the prediction
farthest into the future.

Example:

One type of RUC forecast looks out to 12 hours
(http://rapidrefresh.noaa.gov/).

### Forecast Frequency (Model Attribute)

The Forecast Frequency is the time between the forecasts produced during
a model\'s run.

Example:

The RUC produces high-frequency (every 1 hour) weather forecasts out to
12 hours (http://rapidrefresh.noaa.gov/).

## Provides Forecasts to (Association)

A Model periodically makes new forecasts available to a data warehouse.
The data warehouse services users\' requests for forecasts from its own
archive.

## Data Warehouse (Class)

Each member of the Data Warehouse Class collects and stores measurement
data from two or more observation systems. In response to queries from
users, the warehouse retrieves data and communicates the data to users
via web service.

Example:

NDBC\'s data warehouse at http://www.ndbc.noaa.gov/Maps/WestGulf.shtml
collects data from eight source agencies.

### URL (Data Warehouse Attribute)

The URL provides access to overviews of the warehouse\'s holdings.
Overviews describe the warehouse, its processes of managing the data,
and the systems participating in the warehouse.

Examples:

1\. The URL for the National Data Buoy Center data warehouse is
http://www.ndbc.noaa.gov/. It contains data provided by TCOON, CO-OPS,
LUMCON, WAVECIS, COMPS, TABS, and offshore oil drilling platforms.

2\. The URL for the Center for Operational Oceanographic Products and
Services (CO-OPS) data warehouse is http://140.90.121.76/. It contains
data provided by TCOON and CO-OPS, and possibly others.

### Station Inventory (Data Warehouse Attribute)

The Station Inventory reports the warehouse\'s data sources by station.

Examples:

1\. Stations reporting water level through the CO-OPS site are shown
graphically at http://140.90.121.76/usmap.html.

2\. Fixed stations reporting wave data through the NDBC site are shown
graphically at http://www.ndbc.noaa.gov/ and as a text listing at
http://www.ndbc.noaa.gov/wstat.shtml. Moving stations (ships) are listed
at http://www.ndbc.noaa.gov/ship_obs.php.

### Data Type Inventory (Data Warehouse Attribute)

The Data Type Inventory tells what kinds of data are available from the
warehouse.

Example:

1\. NDBC summarizes the types of data available from each reporting
station at http://www.ndbc.noaa.gov/Data_availability/data_avail.php.

2\. CO-OPS summarizes the types of data available from each reporting
station at http://140.90.121.76/data_inv.html. Newly added data types
are described at http://140.90.121.76/whatsne2.html.

### Operating Agency (Data Warehouse Attribute)

The Operating Agency is the organization owning and operating the data
warehouse.

Examples:

1\. The operating agency for CO-OPS is described in a link from their
web homepage at http://140.90.121.76/index.html (select \"About
CO-OPS\")

2\. NDBC hosts a \"virtual tour\" on their web page at
http://www.ndbc.noaa.gov/Tour/virtr1.shtml describing their history,
operations, facilities, and processes with photos of stations, buoys,
and maintenance operations.

### Quality Control Description (Data Warehouse Attribute)

The Quality Control Description is prose text that tells about the QC
processes applied by the warehouse to incoming sensor measurements.

Examples:

1\. NDBC describes QC processes applied to data in its warehouse at
http://www.ndbc.noaa.gov/qc.shtml.

2\. TCOON briefly discusses its QC process at
http://lighthouse.tamucc.edu/Main/DataManagement.

### Interface Type(Data Warehouse Attribute)

The Interface Type is the data access protocol used by the Data
Warehouse.

Some data warehouses provide predictions or realtime actual observations
only as web pages. Others provide data in accordance with the OPeNDAP
interfacing framework.

Examples:

1\. Observation data embedded in web page code are provided by the NDBC
website http://www.ndbc.noaa.gov/.

2\. Observation data are provided in the form of OPeNDAP downloadable
files by the SEACOOS website
http://seacoos.org/Data%20Access%20and%20Mapping/dodsAccess.

## Builds (Association)

The Data Warehouse creates web page coding for displaying observation
data on the human-viewable display of the client computer. Observation
data, labels, and notes are embedded in the web page code.

## Web Page (Class)

Most data warehouses provide realtime observation data as \"web pages.\"

Example:

Observation data for the NDBC 3-meter discus buoy \"Station 42035 -
GALVESTON 22NM East of Galveston, TX\" is available on the webpage at
http://www.ndbc.noaa.gov/station_page.php?station=42035.

### Code (Web Page Attribute)

A web page is created on a client computer\'s display in accordance with
coding communicated through the internet as a kind of message.

Example:

To view the coding for the web page of the NDBC 3-meter discus buoy
\"Station 42035 - GALVESTON 22NM East of Galveston, TX,\" at
http://www.ndbc.noaa.gov/station_page.php?station=42035, position the
cursor over the web page display, press the right mouse button, and
select \"View Source.\"

### Observations (Web Page Attribute)

Observations are embedded within the coding that tells a client computer
how to build a station\'s web page.

Example:

To view observation data embedded in the coding for the web page of the
NDBC 3-meter discus buoy \"Station 42035 - GALVESTON 22NM East of
Galveston, TX\"
(http://www.ndbc.noaa.gov/station_page.php?station=42035), position the
cursor over the web page display, press the right mouse button, and
select \"View Source.\" Scroll down the page and toward the right in the
new window to find observation data.

## Constructs (Association)

In the OPeNDAP framework, the Data Warehouse retrieves only the specific
data items requested by a user and puts them into a file that is sent to
the user via the internet.

## OPeNDAP File (Class)

OPeNDAP-enabled warehouses prepare data files containing only the data
requested by a user communicating within the OPeNDAP framework.

### Observation Data (OPeNDAP File Attribute)

OPeNDAP files destined for transmittal across the internet contain only
the data requested by the user.

## Web Page Interface (Class)

The ICOOS IIS Data Mart obtains observation data from the web pages
provided by Data Warehouses when users connect over the internet. This
strategy keeps ICOOS IIS interface requirements completely on the ICOOS
IIS side\--the ICOOS IIS does not impose any requirements onto the Data
Warehouses.

## OPeNDAP (Class)

The ICOOS IIS Data Mart conforms to the Open-source Project for a
Network Data Access Protocol (OPeNDAP) interfacing framework. This
protocol is used by the IIS when obtaining observation data from
OPeNDAP-enabled Data Warehouses.

# ICOOS IIS Classes

On Level 1, the ICOOS IIS has all the classes shown in Figure 3-3except
for the Data User Class. The top-level classes of objects shown as
blocks in the figure are:

> 1\. ETL Program
>
> 2\. Geospatial Data Repository
>
> 3\. Web Page Interface
>
> 4\. OPeNDAP
>
> 5\. Geospatial Interface
>
> 6\. Web Feature Service

The ETL Program surveys Data Warehouses through the Web Page Interface
and the OPeNDAP framework. Incoming observations (actual and predicted)
are standardized then sent through the Geospatial Interface to the
Geospatial Data Repository for storage and user access. Data Users and
the Geospatial Data Repository exchange requests and data through the
Web Feature Service.

![](media/image3.wmf)

[]{#__RefHeading___Toc137959382 .anchor}Figure 3‑3. ICOOS IIS Classes.

## Web Page Interface (Class)

This class is shared with web page enabled Data Warehouses as discussed
in Paragraph 2.27.

## OPeNDAP (Class)

This class is shared with OPeNDAP-enabled Data Warehouses as discussed
in Paragraph 2.28.

## ETL Program (Class)

The Extract, Transfer, and Load (ETL) Program is a class of processes
within the ICOOS Data Mart. Instantiations of the ETL Program Class
periodically interface with data warehouses to request observation data
(realtime actual or predicted) for locations within the area of interest
(AOI). ETL programs capture the data provided by the warehouses, extract
the observations, and put the observations into the working database.

### Timer (ETL Program Attribute)

The Timer initiates an ETL programs\'s periodic interfacing with the
station URL\'s in a data warehouse to request the latest realtime
observation data or predictions

### Transformation Manager (ETL Program Attribute)

The Transformation Manager coordinates the internal operation of an ETL
program.

### Base Template (ETL Program Attribute)

The Base Template tells the scraper where the embedded observation data
is located in the web page code.

### Data Storage Interface (ETL Program Attribute)

The Data Storage Interface consists of processes that interface with the
relational database manager to store and retrieve data. There is an
interfacing process for each table in the internal working database.

### Scraper Settings (ETL Program Attribute)

The Scraper Settings are controls that determine the scraper\'s
functioning and relate observations to their positions in the working
database.

### Web Page Scraper (ETL Program Attribute)

The Web Page Scraper extracts embedded observation data from the
warehouse\'s web page code.

### Extracted Observation (ETL Program Attribute)

Extracted Observations are the realtime observations or predicted
observations obtained from a data warehouse, to be stored in the working
database. The observations arrive in the ICOOS IIS via web pages or
OPeNDAP file transfers.

Extracted Observations can be actual realtime measurements or
predictions from models. The actual and predicted observations are
stored in the ETL Program\'s working database.

### Loader (ETL Program Attribute)

The Loader converts observations retrieved from the working database
into geospatial data for transfer to the Data Mart\'s Geospatial Data
Repository.

### Relational Database Manager (ETL Program Attribute)

The Relational Database Manager controls operations of the ETL
Program\'s internal working database.

### Working Database (ETL Program Attribute)

The Working Database temporarily stores observations extracted either
from the web pages by the web page scrapers or from the downloaded data
files by the OPeNDAP Interface. After each scraper and OPeNDAP Interface
has completed its task, the new observations are retrieved, converted
into geospatial data, and transferred to the Data Mart\'s Geospatial
Data Repository. The Working Database is not accessible by entities
outside the Data Mart.

### OPeNDAP Settings (ETL Program Attribute)

The OPeNDAP Settings are controls that determine the OPeNDAP
Interface\'s functioning and relate observations to their positions in
the working database.

### OPeNDAP Interface (ETL Program Attribute)

The OPeNDAP Interface obtains data files from OPeNDAP-enabled
warehouses.

### OPeNDAP Base Template (ETL Program Attribute)

The OPeNDAP Base Template tells the OPeNDAP Interface where to find
actual or prediction observations data in the downloaded files.

## Geospatial Interface (Class)

The Geospatial Interface enables instantiations of the ETL Program Class
to provide geospatial data to the Data Mart\'s Geospatial Data
Repository for storage and to support data requests from users.

Storage instructions and incoming geospatial data are passed to the
geospatial database manager by the loader functions via the Geospatial
Interface.

## Geospatial Data Repository (Class)

The Geospatial Data Repository stores realtime geospatial data and
predictions data provided by the ETL programs. The repository retrieves
geospatial data in response to requests from ICOOS users.

### Geospatial Database Manager (Geospatial Data Repository Attribute)

The Geospatial Database Manager interfaces with the ETL programs for
storing geospatial data. It controls storage and retrieval operations of
the Geospatial Database. It retrieves data in accordance with requests
from users and provides the data for transfer to users.

### Geospatial Database (Geospatial Data Repository Attribute)

The Geospatial Database stores and retrieves geospatial data obtained
from the ETL programs.

## Web Feature Service (Class)

Geospatial data gathered by the ICOOS Data Mart are provided to Data
Users via the Web Feature Service (WFS) interface.

## Data User (Class)

The Data User employs the geospatial data.

### Client (Data User Attribute)

The Client is automation (typically a workstation) employed by human
operators to obtain geospatial data from the ICOOS Data Mart.

### Operator (Data User Attribute)

The Operator is the human user of the ICOOS data.

Glossary

  -----------------------------------------------------------------------
  **Acronym or            **Definition**
  Nomenclature**          
  ----------------------- -----------------------------------------------
  C-MAN                   Coastal-Marine Automated Network

  CO-OPS                  Center for Operational Oceanographic Products
                          and Services

  COMPS                   Coastal Ocean Monitoring and Prediction System

  DACT                    Data Acquisition and Control Telemetry

  DART                    Deep-ocean Assessment and Reporting of Tsunamis

  DCP                     Data Collection Package

  ETL                     Extract, Transfer, and Load

  GFS                     Global Forecast System

  FGDC                    Federal Geographic Data Committee

  GIS                     Geospatial Information System

  GSBP                    General Service Buoy Payload

  ICOOS                   Integrated Coastal and Ocean Observations
                          System

  IIS                     Integrated Information System

  NAM                     North American Mesoscale

  NCEP                    National Center for Environmental Prediction

  NCO                     Network Centric Operations

  NCO/P&T                 Network Centric Operations Programs and
                          Technologies

  NDBC                    National Data Buoy Center

  NOAA                    National Oceanic and Atmospheric Administration

  NTDE                    National Tidal Data Epoch

  OGC                     Open Geospatial Consortium

  OPeNDAP                 Open-source Project for a Network Data Access
                          Protocol

  QC                      Quality Control

  RUC                     Rapid Update Cycle (a forecast model)

  SOAP                    Simple Object Access Protocol

  TCOON                   Texas Coastal Ocean Observing Network

  UML                     Unified Modeling Language

  URL                     Uniform Resource Locator

  US                      United States

  USF                     University of South Florida

  VEEP                    Value Engineered Environmental Payload

  WA                      Washington (state)

  WMC                     Web Map Context (pertains to the document
                          titled *OpenGIS(R) Web Map Context
                          Implementation Specification*)

  WCS                     Web Coverage Service (pertains to the document
                          titled *OpenGIS(R) Web Coverage Service (WCS)
                          Implementation Specification*)

  WFS                     Web Feature Service (pertains to the document
                          titled *OpenGIS(R) Web Feature Service (WFS)
                          Implementation Specification*)

  XML                     Extensible Markup Language
  -----------------------------------------------------------------------