MVCO ADCP SOS, version 2.1

Posted March 2nd, 2009 by jfredericks

These files reflect changes made to the MVCO profile after version 1.0 (deliverables) was reviewed. All documents are draft implementations. The services for real-time wave data from MVCO are currently hosted through an SOS at UAH.

1. SOS implementation

MVCO Processing Diagram

1.1 GetCapabilities - Returns service metadata and information about the Offerings provided.

Link to GetCapabilities

 

1.2 GetObservation - returns the observation data. Currently, 6 offerings are provided:

  • ADCP_DATA - Latest measurement of all Wave data parameters, including QC flags
  • ADCP_DATA - Archived Time Series of all Wave data parameters, including QC flags
  • ADCP_DATA_QC- Only wave data which has passed the timeContinuity test
  • PRESSURE_ALL- All wave data derived from pressure measurement, including QC flags
  • PRESSURE_QC - Pressure-derived parameters that have passed percentGood test and Qartod tests
  • VELOCITY_ALL - All wave data derived from the ADCP 2HZ velocity measurements
  • VELOCITY_QC - Velocity-derived paramters that have passed beamIntensity Test, Correlation Coeff test, Qartod Velocity tests

1.3 DescribeSensor - return info about the sensor, provenance, and qc processes Here is a sample request for the ProcessChain that generates the ADCP_DATA offering:

"A HREF="http://vastserver.nsstc.uah.edu/vastGC/adcp?service=SOS&version=1.0&request=DescribeSensor&procedure=http://vast.uah.edu/downloads/sensorML/v1.0/examples/sensors/ADCP_2.1/ADCP_System.xml ">ADCP_System.xml describes the processing/sensor system used at the MVCO for computing waves.

The remainder of the SensorML documents for the instrument and various QC Processes are detailed in Sections 2 & 3.

 

2. Sensor Description Files, v 2.0

There are two new files that comprise the main Description of the Instrument. They are:

RDI_Workhorse_1200.xml - A general SensorML description of the RDI instrument

MVCO_Workhorse_1200.xml - SensorML description entailing specific details about the MVCO installation of an RDI Workhorse.

These two were encapsulated in a single document (MVCO_Workhorse) in the 1.0 version. It is better to split them up like this, so that any Data Provider using the RDI could reuse the general SensorML description, and they need only fill in details about their particular installation in a separate SensorML doc.
Work is still ongoing on the SensorML description for the RDI_Workhorse_1200. This work is being done with the assistance of Teledyne RDI to ensure accuracy. Working documents with comments from the Stennis meeting inline and the latest changes are available here:

RDI_Workhorse_1200_commented_0.xml - RDI_Workhorse_1200_commented_0.xml

MVCO_Workhorse_1200_commented_0.xml - MVCP_Workhorse_commented_0.xml

 

3. Process Files

A number of different files comprise the complex process chain for the ADCP now.

 

3.1 Generic Test Modules

The test files contain the ProcessChain (Composite) and ProcessModel (Atomic) definitions of the various QC tests performed on the ADCP data. In general, the ProcessChain files operate on a TimeSeries of data, and the ProcessModels operate on individual data points. The Test files are:

  • DataGapTest - Test to make sure data meet time continuity requirements (the upper left block in Janet's figure 3). This test operates on a time series of data.
  • RangeSeriesTest - Test to determine if a data point lies between an upper and lower bound. Operates on a data series
  • RangeTest - The atomic Process for Range checking a single point. This is used in several places in the ADCP Q2O framework.
  • MinThresholdSeriesTest - Like RangeTest, but only operates on a lower bound. Operates on a data series.
  • MinThresholdTest - The atomic Process for testing if a data value exceeds a lower bound.
  • SpikeTest - ProcessChain for SpikeTest as described in Chapter 4. The basic blocks are there, but the atomic pieces need to be finished
  • PUV_Analysis - Perform PUV analysis on interpolated series data. Some of the basics are there, but needs work.

 

3.2 ProcessChain Modules

 

This are the big blocks in the Chapter 4 diagram. Each chain encapsulates one or more <components> which may be either another ProcessChain or a generic Test. The ProcessChain describes a flow of data via <inputs>, <outputs>, and <parameters>. A series of <connections> serves to describe the linkage between components.

 

  • ADCP_System - The main SensorML System description. This is Fig 2 in Janet's Chapter 4
  • Pressure_QC_Chain - General ProcessChain for Pressure time series data
  • Velocity_QC_Chain - General ProcessChain for Velocity time series data
  • Pressure_QC_Chain_Values - ProcessChain for Pressure time series data with parameters configured for MVCO setup
  • Velocity_QC_Chain_Values - ProcessChain for Velocity time series data with parameters configured for MVCO setup
  • Pressure_Obs_Process - Chain that generates a number of observable properties from the cleaned, interpolated time series that is output from Pressure_QC_Chain.
  • Velocity_Obs_Process - Chain that generates a number of observable properties from the cleaned, interpolated time series that is output from Velocity_QC_Chain
  • TimeSeriesChain - ProcessChain composed of several individual processes that perform time-related QC checks on the Pressure and Velocity Series data. Figure 3 in Chapter 4

 

3.3 Parameter values for tests

For several of the tests/processes above, certain parameters can be included inline, or declared externally and coupled to the appropriate process by SensorML-aware software. Examples of this include minimum and maximum wave height for a wave height range check, or the number of Standard Deviations to be used for a SpikeTest. The MVCO SOS serves these parameters as another SOS offering, so that the parameter values used for any time in the archive can be retrieved at a later date:

PARAMS

4. SensorML Tools - A couple of development tools are in the works for viewing and editing SensorML Tools. These can be found on the UAH website at:
SensorML Tools
These are described breifly below.
4.1 PrettyView
UAH has developed a basic web application for displaying SensorML files in a tabular form for human consumption. The tool allows the display of remote files via a URL, or files on the user's local system. It can be found here:
SensorML PrettyView
It is actually not all that pretty yet, but we are working on adding bells and whistles. More elaborate SensorML display and editing tools are also being developed.
4.2 SensorML Editor - The Editor is a stand-alone application which must be downloaded to the user'slocal machine to run. Details and downloads are available at the SensorML Tools page at UAH:
SensorML Editor
TODO

  • Continue to add dictionary URIs for terms as they become available
  • Detail the other options for enabling different parameter values in a ProcessChain
  • Discuss format of CodeSpace entries and ramifications for mapping betweeb CodeSpaces
  • Add latest diagram of ProcessChain
  • ???