Dataset Information

PrincipleInvestigator: "Stephen Pierce,Ph.D"

Variables in this Dataset

ADCP03: Sequence
year: 32 bit Integer
  • Description: "A Date and time string, 2 digit year"
yearday: 64 bit Real
  • Description: "A Date and time string, i.e. 1 January 1200 = 1.5"
  • Timezone: "GMT"
Z: 32 bit Integer
  • Description: "The center of the depth bin. Depth bins are 8m wide. The shallowest depth bin center is 22m."
  • units: "meters"
  • range: "22m - 494m, every 8m"
X: 64 bit Real
  • Description: "Longitude"
  • units: "decimal degrees"
Y: 64 bit Real
  • Description: "Latitude"
  • units: "decimal degrees"
EV: 64 bit Real
  • Description: "Eastward Velocity"
  • units: "meters per second"
NV: 64 bit Real
  • Description: "Northward Velocity"
  • units: "meters per second"


      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
 as follows:
 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.
 Questions, contact:
  Dr. Stephen D. Pierce                       e:
  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       

DODS Relational Database Server

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.

Server Functions:

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 ship track...


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.



String fields in the DBMS may contain white space (spaces). In order for a constraint to match you must include the spaces. For example, if you wish to retrieve all data where a field called location has a value of "Southern Ocean", in your DODS URL you will have to represent the space between "Southern" and "Ocean" with the symbol "%20". Like this:
However, if the DODS URL is formed with a space like this:
    location="Southern Ocean"
It will not be handled correctly by the DRDS.

Have fun!