Shipboard acoustic Doppler current profiler data collected
during the Integrated Acoustic and Trawl Surveys of
Pacific Hake, years: 1995, 1998, 2001, 2003, and 2005
Processing by: Stephen Pierce, Oregon State University
(P. M. Kosro also performed some processing steps
in the 1998 case)
Date: 16 August 2006
Data quality: Good in general
These files provide a simple ascii version of observed velocities,
useful for most purposes. The complete data sets with all configuration
and processing details and diagnostic data (e.g. error velocity, AGC,
spectral width) are available from the NODC Joint Archive for Shipboard
ADCP, or by request from S. Pierce.
Processing steps included: editing of the data using various
diagnostics, calibration of the phase and amplitude errors of the
ADCP/navigation/gyrocompass system by covariability analysis between
currents and ship velocity, reference layer velocity smoothing,
and final production of earth-referenced velocities. For more details
regarding methods, see: Pierce et al. (2000), DSR II 47, 811-829.
Versions of these data are also available from the West Coast Marine
Habitat Server (a component of PaCOOS and IOOS):
The files (one for each Hake survey) are ascii flat files with 7 columns
Column 1 : 2-digit year
Column 2 : Yearday (1.5 == Jan. 1 at 1200)
Column 3 : Depth of the bin center (m)
Column 4 : Longitude (decimal degrees)
Column 5 : Latitude (decimal degrees)
Column 6 : East velocity (m/s)
Column 7 : North velocity (m/s)
There are no null values. Missing or poor-quality data have been omitted.
Dr. Stephen D. Pierce e: email@example.com
College of Oceanic & Atmospheric Sciences o: 541-737-2425
Oregon State University Burt 293 h: 541-766-8992
104 COAS Admin Bldg f: 541-737-2064
Corvallis, OR 97331-5503 http://diana.coas.oregonstate.edu
This data is being served by a DODS Relational Database Server (DRDS), which is a somewhat unusual instance of a DODS server. All of the data served by the DRDS is stored in a relational database management system (DBMS). Queries from DODS clients are translated into SQL queries and sent to the underlying DBMS. The reuturned data is read by the DRDS and returned to the requesting client.
Because the DRDS is essentially a front end to a DBMS, the DDS's have a somewhat different meaning than in other DODS servers. Each DDS served by the a DRDS represents a table in the underlying DBMS. Since queries to the DBMS will return an unknown amount of data, each DDS basically must contain a representation of the tables contents defined as a DODS sequence. Because of this it rarely makes sense for a client to request the entire "dataset", as this request will return the entire contents of the table. When requesting data from a DRDS, it is best to get the dataset information (using the .info extension on the DODS URL) and then build a constrained request that just returns data that is actually desired. This doesn't mean that the entire table cannot be requested and sent, it is simply a caution that each dataset/DDS/table may in fact be very large.
unique(): This function gets used in the selection part of the DODS
constraint expression. It requires no parameters. Calling this funcion will
cause the return to contain only unique rows. This is useful for sifting
through numerous identical fields, for example station data that contains
instrument names. This is NOT very useful if you are trying to retrieve a
Regular Expressions: The typical DODS server supports the full range
regular expression syntax. THIS DODS server does not. Limited string matching is
available. The wild card characters '.' and '.*' may used. The '[...]' notation
for matching a range of characters may be used, but only to match a single
character to a range of possiblities.
location="Southern%20Ocean"However, if the DODS URL is formed with a space like this:
location="Southern Ocean"It will not be handled correctly by the DRDS.