Dataset Information

PrincipleInvestigator: "Mark Abbott"
"Ph.D"
DataCenter: "COAS Environmental Computer Facility"
DrifterType: "MetOcean WOCE/OCM"


Variables in this Dataset

Drifters: Sequence
Drifter_ID: String
  • Description: "String value used to uniquely identify each drifter instrument."
Date_Sampled: String
  • Description: "A Date and time string"
  • Timezone: "GMT"
Latitude: 64 bit Real
  • Description: "Latitude as recorded by ARGOS system"
  • units: "degrees_north"
Longitude: 64 bit Real
  • Description: "Longitude as recorded by ARGOS system"
  • units: "degrees_east"
SST: 64 bit Real
  • Description: "Sea Surface Temperature"
  • units: "degrees Celsius"
Ed_490: 64 bit Real
  • Description: "Downwelling Irradiance Sensor at 490nm"
  • Wavelength: 490
  • units: "microwatts per square cm per nanometer per steradian"
Lu_412: 64 bit Real
  • Description: "Upwelling Radiance Sensor at 412nm"
  • Wavelength: 412
  • units: "microwatts per square cm per nanometer per steradian"
Lu_443: 64 bit Real
  • Description: "Upwelling Radiance Sensor at 443nm"
  • Wavelength: 443
  • units: "microwatts per square cm per nanometer per steradian"
Lu_490: 64 bit Real
  • Description: "Upwelling Radiance Sensorat at 490nm"
  • Wavelength: 490
  • units: "microwatts per square cm per nanometer per steradian"
Lu_510: 64 bit Real
  • Description: "Upwelling Radiance Sensor at 510nm"
  • Wavelength: 510
  • units: "microwatts per square cm per nanometer per steradian"
Lu_555: 64 bit Real
  • Description: "Upwelling Radiance Sensor at 555nm"
  • Wavelength: 555
  • units: "microwatts per square cm per nanometer per steradian"
Lu_670: 64 bit Real
  • Description: "Upwelling Radiance Sensor at 670nm"
  • Wavelength: 670
  • units: "microwatts per square cm per nanometer per steradian"
Lu_683: 64 bit Real
  • Description: "Upwelling Radiance Sensor at 683nm"
  • Wavelength: 683
  • units: "microwatts per square cm per nanometer per steradian"
CHL: 64 bit Real
  • Description: "Chlorophyl Concentration"
  • units: "milligrams per cubic meter"
FLH: 64 bit Real
  • Description: "Fluoresence Line Height"
  • units: "microwatts per square cm per nanometer per steradian"
Region: String
  • Description: "Short description of study area (ex: Oregon, California, Southern Ocean, etc.)"
Decimal_Day: 64 bit Real
  • Description: "The time of the mesurement in a decimal format, useful for plots, starts on January 1st 1993 or January 1st 2000."
Calibration_File: String
  • Description: "Path to the file on our file server of the calibration file for the drifter."
Drifter_Type: String
  • Description: "Type of drifter."


Drifters Dataset

All of the drifter data in this dataset was collected by "optical" drifters. There are a number of different studies, research efforts, and geographical areas covered by the information in this dataset. The location variable contains some information with regards to the geographical area of the data.

For More Detailed Information on this dataset please goto:

The Oregon Remote Sensing Ocean Optics (ORSOO) home page

or to

ORSOO data online

The data at the above site is organized by geographical location, so you might use the value of the location variable, along with the fact that this is optical drifter data as keys to getting useful information from the site.


DODS Test Server

This data is being served by the Java-DODS Test Server. This server was created to allow any possible DODS data structure to be tested for viablity in both the client and server software components of DODS.

This server will take any DODS DDS and attempt serve it to clients with all implemented modes of functionality. It will populate it with data (created from thin air!) and hand it back to a requesting client. It can also be intergogated using the other DODS server interfaces such as the ASCII interface (.asc) the DDS (.dds) interface, the DAS interface (.das), and the HTML interface (.html, also know as the interface from hell...)

The key word in the preceding paragraph is attempt. Since the DODS dataset specification allows for a virtually unlimited range of dataset structures, it certainly possible to create datasets that break existing code, either on the client or the server side. We have, to the best of our abilities, made the DODS core software capable of handling all possible syntactically correct DODS datasets as described by a DDS. However, it is possible to construct dataset definitions (DDS's) so weird and twisted that the DODS core software cannot handle them well. Ultimately that's why this server exists:

To explore the boundaries of what DODS can and cannot do.

Hopefully, you will find it useful too.