Variables in this Dataset

CORAL_1980_2005: Sequence
INSTITUTION_ID: 64 bit Real
  • Description: "Unique ID from Institution."
INSTITUTION: String
  • Description: "Institution is either: Northwest Fisheries Science Center (FRAM Division) or Alaska Fisheries Science Center (RACE Division)"
YEAR_SURVEY: 64 bit Real
  • Description: "Year of Survey."
LONGITUDE_DD: 64 bit Real
  • Description: "Longitude (in decimal degrees) with negative indicating West Degrees"
LATITUDE_DD: 64 bit Real
  • Description: "Latitude (in decimal degrees North)."
DEPTH_METERS: 64 bit Real
  • Description: "Water depth (in meters)."
SPECIES_CODE: 64 bit Real
  • Description: "Unique identifier for species."
TAXA_SCIENTIFIC: String
  • Description: "Scientific name of taxa"
TAXONOMIC_ORDER: String
  • Description: "Taxonomic order."
ORDER_ABBREVIATION: String
  • Description: "Order abbreviation."
TAXONOMIC_FAMILY: String
  • Description: "Taxonomic family."
FAMILY_ABBREVIATION: String
  • Description: "Family abbreviation."
TAXONOMIC_GENUS: String
  • Description: "Taxonomic Genus."


Coral Data - 1980-2005

Coral Data collected during 1980-2005 off West Coast of US

 

This data contains the locations (in latitude, longitude, and water depth) of some observations of cold-water/deep-sea corals off the west coast of the United States. Records of coral catch originate from bottom trawl surveys conducted from 1980 to 2001 by the Alaska Fisheries Science Center (AFSC) and 2001 to 2005 by the Northwest Fisheries Science Center (NWFSC). Locational information represent the vessel mid positions (for AFSC survey trawls) or "best position" (i.e., priority order: 1) gear midpoint 2) vessel midpoint, 3) vessel start point, 4) vessel end point, 5) station coordinates for NWFSC survey trawls) conducted as part of regular surveys of groundfish off the coasts of Washington, Oregon and California by NOAA Fisheries. Only records where corals were identified in the total catch are included. Each catch sample of coral was identified down to the most specific taxonomic level possible by the biologists onboard, therefore identification was dependent on their expertise. When postive identification was not possible, samples were sometimes archived for future identification by systematist experts. Data were compiled by the NWFSC, Fishery Resource Analysis & Monitoring Division

 

Purpose

Examination of the spatial and temporal distributions of observations of cold-water/deep-sea corals off the west coast of the United States, including waters off the states of Washington, Oregon, and California. It is important to note that these records represent only presence of corals in the area swept by the trawl gear. Since bottom trawls used during these surveys are not designed to sample epibenthic invertebrates, absence of corals in the catch does not necessary mean they do not occupy the area swept by the trawl gear.

 

Data Credits

NOAA Fisheries, Alaska Fisheries Science Center, Resource Assessment & Conservation Engineering Division (RACE) NOAA Fisheries, Northwest Fisheries Science Center, Fishery Resource Analysis & Monitoring Division (FRAM)

 

Years

1980-2005

 

Bounding 

West  -125.992029

East -114.930799

North 49.005988

South 32.451719

 

Format

The Oracle view contains the following columns:

INSTITUTION_ID

INSTITUTION

YEAR_SURVEY

LONGITUDE_DD

LATITUDE_DD

DEPTH_METERS

SPECIES_CODE

TAXA_SCIENTIFIC

TAXONOMIC_ORDER

ORDER_ABBREVIATION

TAXONOMIC_FAMILY

FAMILY_ ABBREVIATION

TAXONOMIC_GENUS

 

Contact

Curt Whitmire, NOAA Fisheries

NOAA Fisheries, Northwest Fisheries Science Center

2725 Montlake Blvd E

Seattle, WA 98112-2097

Email: Curt.Whitmire@noaa.gov

Phone:  206-302-2417

 


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...
Example:

          http://nasty.dods.url/server/dataset.dods?var1,var2&unique()
  

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.
Examples:

          http://nasty.dods.url/server/dataset.dods?var1,var2&var3~=".*south.*"
          http://nasty.dods.url/server/dataset.dods?var1,var2&var3~=".south."
  

NOTE:

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:
    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.

Have fun!