U.S. Geological Survey, Great Lakes Science Center 2019 Tabular Digital Data Reston, VA U.S. Geological Survey https://doi.org/10.5066/F75M63X0 All mensuration data represented here expand upon vessel operations (OP table) data, all of which are collected by the United States Geological Survey, Great Lakes Science Center and its partners. The Mensuration Tables contain data collected from the research vessel deploying various gear used for mensuration data collection. The database uses sample_type to indicate the gear deployed. The tables relating to Mensuration are: Mensuration.csv, MS_head_rope_depth.csv, MS_FOOT_ROPE_DEPTH, MS_Primary.csv, MS_Temperature.csv, and MS_Wingspread.csv Data Quality: Note that the following data release is a snapshot of the database at the time of release. Some data quality checks are still being undertaken after the time of release. Also, a large section of this database includes legacy data that if issues arrise for cannot be addressed, but nevertheless adds great value to the database. When approaching the following data release, it is strongly suggested to approach the Great Lakes Science Center's researchers for input. Distribution Liability Statement: Unless otherwise stated, all data, metadata and related materials are considered to satisfy the quality standards relative to the purpose for which the data were collected. Although these data and associated metadata have been reviewed for accuracy and completeness and approved for release by the U.S. Geological Survey (USGS), no warranty expressed or implied is made regarding the display or utility of the data on any other system or for general or scientific purposes, nor shall the act of distribution constitute any such warranty. These data were collected and used in connection with numerous research projects, reports to various organizations on Great Lakes' ecosystem health, and for longitudinal data about environmental conditions and species inhabiting the Great Lakes. The tables described in this metadata record are part of a larger database with details pertaining to each operation's sampling process. An updated version of the data will be published at least yearly, which will include new operations data, show any changes to the database structure, and have more QC applied to the data from previous releases. The metadata will also be updated alongside these data releases in order to describe the data at that time of publication. The database has been structured to have not null (required) columns and nulls allowed (optional) columns. In general, where fields remain null indicates that data was not collected. 19580810 20181204 ground condition Complete As needed -92.6748046874996 -75.4833984375042 49.2158955317088 40.8334534227341 ISO 19115 Topic Categories biota environment inlandWaters Great Lakes Science Center Defined Deepwater Gillnet Trawl Zebra Mussel Ichthyoplankton Zooplankton Mysis Mensuration Hydroacoustic Benthos Prey fish fall forage fish Bathythermograph Lake Trout Population Dynamics Prey fish population dynamics Alewife Lake Trout Bloater Rainbow Smelt Cisco Round Goby Sea Lamprey Walleye Emerald Shiner White Perch Yellow Perch Deepwater Sculpin Spoonhead Sculpin Slimy Sculpin USGS Biocomplexity Thesaurus trawling freshwater fishes biological sampling field sampling USGS Thesaurus geospatial datasets time series datasets transect sampling biogeography age estimation methods fishery management food web Data Categories for Marine Planning Habitat National Agricultural Library Thesaurus age structure gillnets trawl nets biomass population dynamics water temperature surface water temperature invasive species acoustics USGS Metadata Identifier USGS:5ca76502e4b0c3b0064df1f1 Geographic Names Information System Laurentian Great Lakes Saint Clair River Detroit River Lake Saint Clair Getty Thesaurus of Geographic Names Lake Michigan Lake Erie Lake Superior Lake Huron Lake Ontario None. Please see 'Distribution Info' for distributor information. none Scott Nelson Great Lakes Science Center, United States Geological Survey mailing and physical

1451 Green Road

Ann Arbor MI 48105 US 734 214 7243 snelson@usgs.gov Contributors to the database outside of the Great Lakes Science Center: Michigan Department of Natural Resources, New York Department of Environmental Conservation, United States Fish and Wildlife Service Environment as of Metadata Creation: Microsoft Windows 7 Version 6.1 (Build 7601) Service Pack 1; Esri ArcGIS 10.3.1 (Build 4959) Service Pack N/A (Build N/A) No singular formal attribute accuracy tests were conducted. Due to the collaborative and dispersed spatial and temporal nature of data entry into the RVCAT database, no one attribute accuracy assessment can be listed. For information on QA/QC processes, contact individual researchers at the Great Lakes Science Center in Ann Arbor, MI; Ashland, WI; Sandusky, OH; and Oswego, NY and collaborators at the Fish and Wildlife Service. No singular formal logical accuracy tests were conducted. Due to the collaborative and dispersed spatial and temporal nature of data entry into the RVCAT database, no one logical accuracy assessment can be listed. Quality control is a regular part of data entry into the database. For information on QA/QC processes, contact individual researchers at the Great Lakes Science Center in Ann Arbor, MI; Ashland, WI; Sandusky, OH; and Oswego, NY and collaborators at the Fish and Wildlife Service. Data set is considered complete for the information presented, as described in the abstract. Users are advised to read the rest of the metadata record carefully for additional details. No singular formal horizontal positional accuracy tests were conducted. Due to the collaborative and dispersed spatial and temporal nature of data entry into the RVCAT database, no one horizontal Positional accuracy assessment can be listed. For information on QA/QC processes, individual researchers at the Great Lakes Science Center in Ann Arbor, MI; Ashland, WI; Sandusky, OH; and Oswego, NY and collaborators at the Fish and Wildlife Service can be contacted. No singular formal vertical position accuracy tests were conducted. Due to the collaborative and dispersed spatial and temporal nature of data entry into the RVCAT database, no one vertical positional accuracy assessment can be listed. For information on QA/QC processes, individual researchers at the Great Lakes Science Center in Ann Arbor, MI; Ashland, WI; Sandusky, OH; and Oswego, NY and collaborators at the Fish and Wildlife Service can be contacted. Data Structure History: Before 1958, the data sheets that were filled out by hand on the boat were not necessarily standardized between lakes. The data collected by the GLSC from 1958 forward were punched on IBM keypunch cards after the data was collected on the boat. This year corresponds to the earliest data points currently stored in RVCAT. 1958 Data Structure History: A lakes-wide revision to the data entry sheets occurred at the Great Lakes Science Center (at that time called The Great Lakes Fishery Laboritory) which began the systematic lake-wide assessments. Note that the Great Lakes Science Center had been part of the Bureau of Land Management up until 1971 when it joined the Fish and Wildlife Service. The revision to data entry methods was part of the transition into a new department. Keypunching of data continued. 1973 Data Structure History: (approximately 1985) Key to disk data entry system started. Data were entered in an 80 column ASCII format identical to the card formats previously punched. 1985 Data Structure History: Oracle version 5 purchased for Data General MV4000 minicomputer. Shortly after, a relational database design was established to contain the card image data created up to that point. The database was called Research Vessel Catch (RVCAT). Routines were created to import the card images into the database. SQLLDR (SQL Loader) was used to import the 80 column card formats and SQL scripts were used to distribute the data into the corresponding tables and columns. 1988 Data Structure History: First iteration of RVCAT data entry into Oracle was created in Ann Arbor. Lakes Michigan and Huron started entering data directly into the database on the research vessel (Vessel: Cisco, Cruise: 6) using laptop computers. Data were then imported into the main database on the Data General MV4000 minicomputer. 1991 Data Structure History: Four instances of Oracle version 7 hosted on Netware servers beginning in Ann Arbor (Lakes Michigan and Huron). The database forms and reports were converted from version 5 to version 7. Then instances in Oracle were stood up at stations / vessel bases in Ashland (Lake Superior), Sandusky (Lake Erie), and Oswego (Lake Ontario). This meant all four stations had their own Oracle databases to contribute to. 1994 Data Structure History: Oracle 9i stood up on Windows Server 2003. 200305 Data Structure History: Oracle version 10g stood up on Windows Server 2003. 200610 Data Structure History: Databases from Ashland, Sandusky, and Oswego were incorporated into the Ann Arbor Oracle database. Some editing to tables and columns occurred in order for the incorporation to be completed. Ashland integrated their database into Ann Arbor’s server. The integration process had been worked on for a few years up to this point. Some tables were altered in order for data from Ashland to be brought in with the rest of the databases. When combining the databases, a number of issues were resolved: (1) orphaned data that existed in some trawl tables without a parent record in the OP table, (2) Non-unique keys making it appear there are duplicate records in GN_EFFORT and TR_CATCH, (3) Variables existing in the main table where there was no correlated value in the reference table, (4) Differences between the different lakes usage of reference tables. For example, maturity does not line up between Ann Arbor and Ashland. Other reference table mismatching existed as well, (5) tables where columns exist for one lake and not the others. Examples being in the TR_LF and GN_LF tables – Ashland had columns called exp_n and fin_clip. In the GN_EFFORT table Ann Arbor used the panel column and Ashland did not. 200704 Data Structure History: Oracle version 11g stood up on Windows 2008 R2. 201307 Data Publication/Release History: Metadata creation project leads to QA/QC and structural changes to the database. Some columns that contained no data were removed, some possible fields never used were removed, and some orphaned data was fixed. Column changed to GONAD_WEIGHT in table TR_FISH from column OVARY_WEIGHT. 201706 Data Publication/Release History: Version two/ second release of data and metadata made public, which includes QA/QC and structural changes to the database. The Digtal Object Identifier (DOI) for the release stays the same while version control is represented in the citation. See the RVCAT-Revision-History PDF for full description of changes to the database. 201803 Data Publication/Release History: Version three/ third release of data and metadata made public, which includes QA/QC and structural changes to the database. The Digtal Object Identifier (DOI) for the release stays the same while version control is represented in the citation. See the RVCAT-Revision-History PDF for full description of changes to the database. 201903 QA/QC Methodology: Lake Michigan, Lake Huron; Description by technician Patricia Armenio - Compare original physical data sheets to all entries in RVCAT and making changes as needed. 201903 QA/QC Methodology: Lake Michigan, Lake Huron; Description by technician Patricia Armenio - In more current years, also spot check data in the database with SQL queries and make changes as needed. 201903 QA/QC Methodology: Lake Michigan, Lake Huron; Description by technician Steven Farha - 1. Conduct preliminary review on vessel for consistency among serials, missing data, etc. Timeline: Last day of cruise. Usually done on vessel, once cruise is complete, prior to departure back to GLSC-A2. 2. Line by line manual review with vessel log and paper datasheets. Ensure all vessel fields are entered, and species codes, counts, length frequency, times, weights, etc. are correct. Timeline: Once returned to station, prior to move (move statement described later in processing steps)/upload, approximately 1 week post-cruise. 3. QA/QC for miskeys/typos using self made R program once data uploaded to database. Timeline: approximately 1 month post-cruise 201903 QA/QC Methodology: Lake Michigan, Lake Huron; Description by Research Fisheries Biologist David Warner - After lead technician initially reviews the data, he/she follows up with plots and summary tables in R to spot check data. 201903 QA/QC Methodology: Lake Michigan, Lake Huron; Description by Supervisory Fish Biologist Timothy P O'Brien - (1) Reviews data sheets and any calculations made in the field against what was entered in RVCAT (2) Run "Cruise Check" or Explore program written by GLSC statistician Jean Adams. (3) When erroneous values are identified from "Cruise Check" (usually through plots of length, weights, etc) corrections are made to the database. 201903 QA/QC Methodology: Lake Michigan; Description by Research Fisheries Biologist Charles Madenjian - On a yearly basis runs the long-standing SAS program called "Cruise Check" on the Lake Michigan Bottom Trawl survey. "Cruise Check" locates errors in recording lengths of fish, coordinates for trawl locations, weights in fish, etc. 201903 QA/QC Methodology: Lake Superior; Description by technician Lori Evrard - After all data is entered into RVCAT on ship, at the office I then use SQL scripts to compare RVCAT data to paper records. I make any needed corrections, then "MOVE" data and send to Limei to import. 201903 QA/QC Methodology: Lake Ontario; Description by Research Fisheries Biologist Brian Weidel - First, data are entered via offline and online RVCAT portals, meaning data will be entered into an Oracle form or as one big csv upload into the database. At least once, sometimes more times a year, all bottom trawl data qa/qc'd with scripts that check: (1) OP, TR_OP, table entries, looking for "odd" values (2) TR_CATCH: checks that species recorded are actually in the lake, or at resonable depths. Also verifies that species average length ranges and species weight ranges are within reason. (3) TR_FISH: Checks length/ weight relationships, clips, total length ranges, and total weight ranges are within reason. (4) Runs a script that checks TR_LF against TR_CATCH against TR_FISH 201903 QA/QC Methodology: Lake Erie; Description by Supervisory Research Fisheries Biologist Richard Kraus [Note that this description is for post 2014 Lake Erie data not in the database. Saving information here in anticipation of encorporating these data into RVCAT] - (1) During processing of the catch on-deck, we use graphical (histogram plots generated in real time) and predictive checks (length-weight regression predictions in real-time) to ensure that fish measurements are correct. (2) The captain and the scientific staff record navigation and weather condition data independently, and the values are compared after the cruise. (3) net mensuration is monitored in real-time to evaluate whether the trawl is functioning correctly; ultimately we plan to establish values for acceptable/unacceptable tows, but this has been a low priority because the net functions as predicted by scale-modeling in flume trials at Memorial University (4) Water quality sensors are calibrated annually by the manufacturer and compared with other calibrated instruments intermittently throughout the field season. (5) net mensuration devices are checked via "harbor testing" recommended by the manufacturer and are serviced every 24 months to have batteries replaced and to be recalibrated (6) a "work-in-progress" R package has been constructed that extracts data from the native Access format and runs a suite of diagnostics (graphs, summary statistics, and internal consistency checks); the results are reviewed within two-weeks of each cruise by participants to develop consensus decisions for handling suspect or erroneous values 201903 Move Statement - Oracle "Alter Table" process from Oracle form: [Table: TR_CATCH / Column: N] There are two move statements that affect the total count of fish caught. The first move statement enacted is an UPDATE to the N column and the second move statement is an insertion of data including data into the N column. Upon the first move statement, TR_CATCH runs an UPDATE query that sets the value TR_CATCH.N to equal to the value already in TR_CATCH.N plus the value TR_CATCH.LF_N. In other words, the number of fish counted (N) and the number of fish measured (LF_N) when added together equal the total number of fish caught, which is the end value for N after the move statement is complete. The second move statement that occurs on TR_CATCH takes data from TR_SUB and BUCKET. That statement is as follows: The data added into TR_CATCH populate the columns OP_ID, LIFE_STAGE, SPECIES, N, LF_N, and WEIGHT from TR_SUB. Columns N and WEIGHT are calculated from TR_SUB and BUCKET into TR_CATCH. The formulas for TR_CATCH counted number (N) and weight (WEIGHT) use a total of the BUCKET table's weight for an OP_ID and a total of the TR_SUB table's weight for an OP_ID. In other words this move statement expands the counted number (N)of each lifestage, species, and OP_ID by the total weight of the catch and the total weight of the subsample. When the COMPLETE field in the OP table (OP.COMPLETE) is null this means no data has been moved between tables for that OP_ID. Then, when the move statement is initiated, those rows with OP.COMPLETE set to null will be affected by the move statement. After the move statement is completed, the OP.COMPLETE field will be set to 1. 201903 Move Statement - Oracle "Alter Table" process from Oracle form: [Table: TR_CATCH / Column: Weight] The move statement that occurs on TR_CATCH from TR_SUB and BUCKET is as follows: The data added into TR_CATCH populate the columns OP_ID, LIFE_STAGE, SPECIES, N, LF_N, and WEIGHT from TR_SUB. Columns N and WEIGHT are calculated from TR_SUB and BUCKET into TR_CATCH. The formulas for TR_CATCH counted number (N) and weight (WEIGHT) use a total of the BUCKET table's weight for an OP_ID and a total of the TR_SUB table's weight for an OP_ID. In other words this move statement expands the weight of each lifestage, species, and OP_ID by the total weight of the catch and the total weight of the subsample. When the COMPLETE field in the OP table (OP.COMPLETE) is null this means no data has been moved between tables for that OP_ID. Then, when the move statement is initiated, those rows with OP.COMPLETE set to null will be affected by the move statement. After the move statement is completed, the OP.COMPLETE field will be set to 1. 201903 Move Statement - Oracle "Alter Table" process from Oracle form: [Table: TR_CATCH / Column: LF_N] LF_N is part of a move statement that updates the data in the N column. Upon this move statement, TR_CATCH runs an UPDATE query that sets the value TR_CATCH.N to equal to the value already in TR_CATCH.N plus the value TR_CATCH.LF_N. In other words, the number of fish count (N) and the number of fish measured (LF_N) when added together equal the total number of fish caught, which is the end value for N after the move statement is complete. When the COMPLETE field in the OP table (OP.COMPLETE) is null this means no data has been moved between tables for that OP_ID. Then, when the move statement is initiated, those rows with OP.COMPLETE set to null will be affected by the move statement. After the move statement is completed, the OP.COMPLETE field will be set to 1. 201903 Move Statement - Oracle "Alter Table" process from Oracle form: [Table: Bucket / Column: Weight] BUCKET.WEIGHT along with TR_SUB.SUB_WEIGHT are used together in a move statement to calculate the total count (TR_CATCH.N) and the total weight (TR_CATCH.WEIGHT) in TR_CATCH. This weight (Bucket.Weight) and the weight in the TR_SUB table (TR_SUB.SUB_WEIGHT) equal the total weight of the catch (TR_CATCH.WEIGHT) for that OP_ID. When the COMPLETE field in the OP table (OP.COMPLETE) is null this means no data has been moved between tables for that OP_ID. Then, when the move statement is initiated, those rows with OP.COMPLETE set to null will be affected by the move statement. After the move statement is completed, the OP.COMPLETE field will be set to 1. 201903 Move Statement - Oracle "Alter Table" process from Oracle form: [Table: TR_SUB / Column: NM_N] This not measured count of fish is used in a move statement to calculate the total count of fish caught (N) in the TR_CATCH table (TR_CATCH.N). The move statement uses: the total bucket weight (Bucket.Weight) for that OP_ID, the total TR_SUB weight (TR_SUB.SUB_WEIGHT) for that OP_ID, the not measured count (TR_SUB.NM_N), and the measured fish count (TR_SUB.LF_N). When the COMPLETE field in the OP table (OP.COMPLETE) is null this means no data has been moved between tables for that OP_ID. Then, when the move statement is initiated, those rows with OP.COMPLETE set to null will be affected by the move statement. After the move statement is completed, the OP.COMPLETE field will be set to 1. 201903 Move Statement - Oracle "Alter Table" process from Oracle form: [Table: TR_SUB / Column: LF_N] This count of fish that are measured is used in a move statement to calculate the total count of fish caught (N) in the TR_CATCH table (TR_CATCH.N). The move statement uses: the total bucket weight (Bucket.Weight) for that OP_ID, the total TR_SUB weight (TR_SUB.SUB_WEIGHT) for that OP_ID, the not measured count (TR_SUB.NM_N), and the measured fish count (TR_SUB.LF_N). When the COMPLETE field in the OP table (OP.COMPLETE) is null this means no data has been moved between tables for that OP_ID. Then, when the move statement is initiated, those rows with OP.COMPLETE set to null will be affected by the move statement. After the move statement is completed, the OP.COMPLETE field will be set to 1. 201903 Move Statement - Oracle "Alter Table" process from Oracle form: [Table: TR_SUB / Column: SUB_WEIGHT] This total weight of counted and measured fish is used in a move statement to calculate the total count (TR_CATCH.N) and the total weight (TR_CATCH.WEIGHT) in TR_CATCH. The move statement uses: the bucket weight (Bucket.Weight) and the weight in the TR_SUB table (TR_SUB.SUB_WEIGHT) equal the total weight of the catch (TR_CATCH.WEIGHT) for that OP_ID. When the COMPLETE field in the OP table (OP.COMPLETE) is null this means no data has been moved between tables for that OP_ID. Then, when the move statement is initiated, those rows with OP.COMPLETE set to null will be affected by the move statement. After the move statement is completed, the OP.COMPLETE field will be set to 1. 201903 Move Statement - Oracle "Alter Table" process from Oracle form: [Table: TR_L] There are two move statements that take data from the TR_L table and input the resulting information into the TR_LF and the TR_PREY tables. The move statement that occurs on TR_LF from TR_L is as follows: The data inserted into TR_LF populate the columns OP_ID, LIFE_STAGE, SPECIES, LENGTH, N. The column N in TR_LF was created by finding the total count in TR_L of fish that have the same OP_ID, LIFE_STAGE, SPECIES, and LENGTH. The move statement that occurs on TR_PREY from TR_L is as follows: The data added into TR_PREY populate the columns TR_FISH_ID, SPECIES, LENGTH, and N from TR_L. TR_FISH_ID must be not null for the move statement to occur. The column N in TR_PREY was created by finding the total count in TR_L of fish that have the same TR_FISH_ID, SPECIES, and LENGTH. When the COMPLETE field in the OP table (OP.COMPLETE) is null this means no data has been moved between tables for that OP_ID. Then, when the move statement is initiated, those rows with OP.COMPLETE set to null will be affected by the move statement. After the move statement is completed, the OP.COMPLETE field will be set to 1. 201903 Move Statement - Oracle "Alter Table" process from Oracle form: [Table: TR_LF / Column: N] This count of fish is calculated by a move statement that takes data from the TR_L table. The move statement that occurs on TR_LF from TR_L is as follows: The data inserted into TR_LF populate the columns OP_ID, LIFE_STAGE, SPECIES, LENGTH, N. The column N in TR_LF was created by finding the total count in TR_L of fish that have the same OP_ID, LIFE_STAGE, SPECIES, and LENGTH. When the COMPLETE field in the OP table (OP.COMPLETE) is null this means no data has been moved between tables for that OP_ID. Then, when the move statement is initiated, those rows with OP.COMPLETE set to null will be affected by the move statement. After the move statement is completed, the OP.COMPLETE field will be set to 1. 201903 Move Statement - Oracle "Alter Table" process from Oracle form: [Table: TR_Prey / Column: N] This counted prey fish for length is calculated by a move statement using the total count of TR_L. The move statement that occurs on TR_PREY from TR_L is as follows: The data added into TR_PREY populate the columns TR_FISH_ID, SPECIES, LENGTH, and N from TR_L. TR_FISH_ID must be not null for the move statement to occur. The column N in TR_PREY was created by finding the total count in TR_L of prey fish that have the same TR_FISH_ID, SPECIES, and LENGTH. When the COMPLETE field in the OP table (OP.COMPLETE) is null this means no data has been moved between tables for that OP_ID. Then, when the move statement is initiated, those rows with OP.COMPLETE set to null will be affected by the move statement. After the move statement is completed, the OP.COMPLETE field will be set to 1. 201903 Move Statement - Oracle "Alter Table" process from Oracle form: [Table: GN_L] The move statement that occurs on GN_PREY from GN_L is as follows: The data added into GN_PREY populate the columns GN_FISH_ID, SPECIES, LENGTH, and N from GN_L. The column N in GN_PREY was created by finding the total count in GN_L of fish that have the same GN_FISH_ID, SPECIES, and LENGTH. GN_FISH_ID must also be not null for the move statement to occur. The move statement that occurs on GN_LF from GN_L is as follows: The data inserted into GN_LF populate the columns GN_EFFORT_ID, LIFE_STAGE, SPECIES, LENGTH, N. The column N in GN_LF was created by finding the total count in GN_L of fish that have the same GN_EFFORT_ID, LIFE_STAGE, SPECIES, and LENGTH. When the COMPLETE field in the OP table (OP.COMPLETE) is null this means no data has been moved between tables for that OP_ID. Then, when the move statement is initiated, those rows with OP.COMPLETE set to null will be affected by the move statement. After the move statement is completed, the OP.COMPLETE field will be set to 1. 201903 Move Statement - Oracle "Alter Table" process from Oracle form: [Table: GN_LF / Column: N] This column N is calculated via a move statement counting rows of data in the GN_L table. The move statement that occurs on GN_LF from GN_L is as follows: The data inserted into GN_LF populate the columns GN_EFFORT_ID, LIFE_STAGE, SPECIES, LENGTH, N. The column N in GN_LF was created by finding the total count in the GN_L table of fish that have the same GN_EFFORT_ID, LIFE_STAGE, SPECIES, and LENGTH. When the COMPLETE field in the OP table (OP.COMPLETE) is null this means no data has been moved between tables for this OP_ID. Then, when the move statement is initiated, those rows with OP.COMPLETE set to null will be affected by the move statement. After the move statement is completed, the OP.COMPLETE field will be set to 1. 201903 Move Statement - Oracle "Alter Table" process from Oracle form: [Table: GN_Prey / Column: N] The move statement that occurs on GN_PREY from GN_L is as follows: The data added into GN_PREY populate the columns GN_FISH_ID, SPECIES, LENGTH, and N from GN_L. The column N in GN_PREY was created by finding the total count in GN_L of fish that have the same GN_FISH_ID, SPECIES, and LENGTH. GN_FISH_ID must be not null for the move statement to occur. When the COMPLETE field in the OP table (OP.COMPLETE) is null this means no data has been moved between tables for that OP_ID. Then, when the move statement is initiated, those rows with OP.COMPLETE set to null will be affected by the move statement. After the move statement is completed, the OP.COMPLETE field will be set to 1. 201903 Mensuration Mensuration. Tables that give broad characteristics to create a tow profile. Specifically the fishing depth and dimensions of the trawl. Note that not all mensuration sources / types/ brands collect the same data, this would account for null values in this table. Units depend on the mensuration source attributes (columns). In future publications of this database, the mensuration table should change to include more source for each of the data input attributes. Not null columns for this table: OP_ID; Primary key values for this table: OP_ID; Unique key values for this table: N/A. Producer defined REMARKS Remarks. Comments on deployment or collection of data of sensor. Oracle data type VARCHAR2(200) Producer defined Text OP_ID Artificial op table sequence number (linked to op table). Foreign key value. OP_ID is used as a linking variable between the tables in the RVCAT Database. OP_ID is assigned by Oracle based on the OP table Primary key fields: Year, Lake, Vessel, Serial, and Sample Type. Note that for most end users of the RVCAT database, the OP_ID is not a visible value. When querying the database, OP_ID is the most important attribute linking the RVCAT tables together. Oracle data type NUMBER(6) Producer defined Foreign key value AVG_WINGSPREAD_M Average width (meters) between trawl wings during operation. Oracle data type NUMBER(7,1) Producer defined Measured in meters AVG_DOORSPREAD_M Average width (meters) between trawl doors during operation. Oracle data type NUMBER(7,1) Producer defined Measured in meters MENSURATION_SOURCE_SPREAD What mensuration gear was used to measure net spread. This column is associated both with the Wingspread and the Doorspread. In the future this field will be split to allow for different gear types for Wingspread and Doorspread. As of right now, both spreads can only be recorded with their gear type if they come from the same gear type source. Foreign key value linked to the Mensuration Source Reference Table. See file Mensuration_Source.csv within the Reference item https://www.sciencebase.gov/catalog/item/57e18ddfe4b0908250033a84 Oracle data type NUMBER(2) Producer defined Foreign key value AVG_HEADROPE_DEPTH_M Average depth (meters) in the water column at headrope during operation. Oracle data type NUMBER(7,1) Producer defined Measured in meters AVG_FOOTROPE_DEPTH_M Average depth (meters) in the water column at footrope during operation. Oracle data type NUMBER(7,1) Producer defined Measured in meters AVG_VERTICAL_OPENING_M Average distance (meters) between footrope and headrope during operation. Oracle data type NUMBER(7,1) Producer defined Measured in meters MENSURATION_SOURCE_DEPTH Mensuration_Source_Depth code. What mensuration gear was used to measure net depth. This attribute (column) is associated with both with the Avg Footrope Depth and the Avg Headrope Depth. In the future this field will be split to allow for different gear types for Footrope and Headrope depths. As of right now, both depth measurements can only be recorded with their gear type if they come from the same gear type source. Foreign key value linked to the Mensuration Source Reference Table. See file Mensuration_Source.csv within the Reference item https://www.sciencebase.gov/catalog/item/57e18ddfe4b0908250033a84 Oracle data type NUMBER(2) Producer defined Foreign key value BTM_CONTACT Data collecting information about time on bottom. Duration of time the net is in contact with the lake bottom. Measured in decimal minutes, however, could be measured in seconds potentially. Currently bottom contact time does not have a field recording what gear collected this data. Oracle data type NUMBER(4,2) Producer defined Measured generally in decimal minutes AVG_HEADROPE_TEMP Avg_Headrope_Temp (C) refers to the mean temperature (from the start to end of a tow) recorded by a sensor on the headrope of a trawl. It is most commonly associated with midwater trawls. HOBO loggers and MK9s are commonly used sensors to gather the raw temperature data. Oracle data type NUMBER(3,1) Producer defined Temperature is recorded in degrees Celsius. AVG_FOOTROPE_TEMP Avg_Footrope_Temp (C) refers to the mean temperature (from the start to end of a tow) recorded by a sensor on the footrope of a trawl. It is most commonly associated with midwater trawls. HOBO loggers and MK9s are commonly used sensors to gather the raw temperature data. Oracle data type NUMBER(3,1) Producer defined Temperature is recorded in degrees Celsius. MS_head_rope_depth Mensuration Headrope Depth. Table describing the depth at which the trawl headrope was located throughout the operation. Units depend on the mensuration source, though should generally be measured in meters. Not null columns for this table: N/A; Primary key values for this table: N/A; Unique key values for this table: ELAPSE_TIME, METERS, H_DATE. Producer defined ELAPSE_TIME Time from the start of data recording. Oracle data type NUMBER(5,4) Producer defined Measured generally in hours. Units depend on source. Could be hours or minutes. Check mensuration_source to determine. For example, netmind collects the data in hours. METERS Depth at which the sensor, typically located in the center of the the headrope, is at a given elapse_time. Oracle data type NUMBER(7,1) Producer defined Measured in meters STATUS Status of collected data as a "Valid Reading" or an "Error" determined by software. Note that the software will not catch all errors. E = error, D = valid reading Oracle data type CHAR(1) Producer defined E = error, D = valid reading H_DATE Date the data were recorded, produced by the mensuration gear software. Oracle data type DATE. Producer defined Date. DD-MMM-YY H_TIME Time data were recorded. Oracle data type VARCHAR2(8) Producer defined Either in a XX:XX:XX or XX:XX format. OP_ID Artificial op table sequence number (linked to op table). Foreign key value. OP_ID is used as a linking variable between the tables in the RVCAT Database. OP_ID is assigned by Oracle based on the OP table Primary key fields: Year, Lake, Vessel, Serial, and Sample Type. Note that for most end users of the RVCAT database, the OP_ID is not a visible value. When querying the database, OP_ID is the most important attribute linking the RVCAT tables together. Oracle data type NUMBER(6) Producer defined Foreign key value H_TEMP Temperature reading produced by the mensuration gear software at the specified Meters, Date, and Time. Oracle data type NUMBER(3,1). Producer defined Celsius MS_foot_rope_depth Mensuration Footrope Depth. Table describing the depth at which the trawl footrope was located throughout the operation. Units depend on the mensuration source, though should generally be measured in meters. Not null columns for this table: N/A; Primary key values for this table: N/A; Unique key values for this table: ELAPSE_TIME, METERS, H_DATE. Producer defined ELAPSE_TIME Time from the start of data recording. Oracle data type NUMBER(5,4) Producer defined Measured generally in hours. Units depend on source. Could be hours or minutes. Check mensuration_source to determine. For example, netmind collects the data in hours. METERS Depth at which the sensor, typically located in the center of the the headrope, is at a given elapse_time. Oracle data type NUMBER(7,1) Producer defined Measured in meters STATUS Status of collected data as a "Valid Reading" or an "Error" determined by software. Note that the software will not catch all errors. E = error, D = valid reading Oracle data type CHAR(1) Producer defined E = error, D = valid reading F_DATE Date the data were recorded, produced by the mensuration gear software. Oracle data type DATE. Producer defined Date. DD-MMM-YY F_TIME Time data were recorded. Oracle data type VARCHAR2(8) Producer defined Either in a XX:XX:XX or XX:XX format. OP_ID Artificial op table sequence number (linked to op table). Foreign key value. OP_ID is used as a linking variable between the tables in the RVCAT Database. OP_ID is assigned by Oracle based on the OP table Primary key fields: Year, Lake, Vessel, Serial, and Sample Type. Note that for most end users of the RVCAT database, the OP_ID is not a visible value. When querying the database, OP_ID is the most important attribute linking the RVCAT tables together. Oracle data type NUMBER(6) Producer defined Foreign key value F_TEMP Temperature reading produced by the mensuration gear software at the specified Meters, Date, and Time. Oracle data type NUMBER(3,1). Producer defined Celsius MS_Primary Mensuration Primary. Table describing the distance from the headrope to the footrope or the distance from the headrope to the lake bottom. Currently there is no way to determine whether distance between headrope to footrope or headrope to lake bottom is being recorded. Units depend on the mensuration source. Not null columns for this table: OP_ID; Primary key values for this table: N/A; Unique key values for this table: ELAPSE_TIME, METERS, P_DATE, P_TIME, OP_ID. Producer defined ELAPSE_TIME Time from the start of data recording. Oracle data type NUMBER(5,4) Producer defined Measured in hours METERS Meters can either describe the distance from the headrope to the footrope or the distance from the headrope to the lake bottom. Due to issues with equipment, this data was not always recorded. Oracle data type NUMBER(7,1) Producer defined Measured in meters STATUS Status of collected data as a "Valid Reading" or an "Error" determined by software. Note that the software will not catch all errors. E = error, D = valid reading. Note taht is Elapse_Time was left null that the status column has also been left null. Oracle data type CHAR(1) Producer defined E = error, D = valid reading P_DATE Date the data were recorded, produced by the mensuration gear software. Oracle data type DATE. Producer defined Date. DD-MMM-YY P_TIME Time data were recorded. Oracle data type VARCHAR2(8) Producer defined Either in a XX:XX:XX or XX:XX format. OP_ID Artificial op table sequence number (linked to op table). Foreign key value. OP_ID is used as a linking variable between the tables in the RVCAT Database. OP_ID is assigned by Oracle based on the OP table Primary key fields: Year, Lake, Vessel, Serial, and Sample Type. Note that for most end users of the RVCAT database, the OP_ID is not a visible value. When querying the database, OP_ID is the most important attribute linking the RVCAT tables together. Oracle data type NUMBER(6) Producer defined Foreign key value CELSIUS Water temperature at the location of the sensor. Oracle data type NUMBER(3,1) Producer defined Measured in degrees celsius MS_Temperature Mensuration Temperature. Temperature data from mensuration gear. Units depend on the mensuration source. Not that netmind measures in degrees celsius. Not null columns for this table: OP_ID; Primary key values for this table: N/A; Unique key values for this table: ELAPSE_TIME, METERS, T_DATE, OP_ID. Producer defined ELAPSE_TIME Time from the start of data recording. Oracle data type NUMBER(5,4) Producer defined Measured in hours METERS Water temperature at the depth of the headrope sensor. Oracle data type NUMBER(7,1) Producer defined Measured in degrees celsius STATUS Status of collected data as a "Valid Reading" or an "Error" determined by software. Note that the software will not catch all errors. E = error, D = valid reading Oracle data type CHAR(1) Producer defined E = error, D = valid reading T_DATE Date the data were recorded, produced by the mensuration gear software. Oracle data type DATE. Producer defined Date. DD-MMM-YY T_TIME Time data were recorded. Oracle data type VARCHAR2(8) Producer defined Either in a XX:XX:XX or XX:XX format. OP_ID Artificial op table sequence number (linked to op table). Foreign key value. OP_ID is used as a linking variable between the tables in the RVCAT Database. OP_ID is assigned by Oracle based on the OP table Primary key fields: Year, Lake, Vessel, Serial, and Sample Type. Note that for most end users of the RVCAT database, the OP_ID is not a visible value. When querying the database, OP_ID is the most important attribute linking the RVCAT tables together. Oracle data type NUMBER(6) Producer defined Foreign key value MS_Wingspread Mensuration Wingspread. Table describing the width (meters) between trawl wings during operation. Units depend on the mensuration source. Not null columns for this table: OP_ID; Primary key values for this table: N/A; Unique key values for this table: ELAPSE_TIME, METERS, W_DATE, OP_ID. Producer defined ELAPSE_TIME Time from the start of data recording. Oracle data type NUMBER(5,4) Producer defined Measured in hours. Units depend on source. Could be hours or minutes. Check mensuration_source to determine. METERS Distance value between the two wingspread (trawl wing) sensors. This distance varies between trawls and can vary between tows at different depths. For example, the deeper the trawl, the farther the sensors get from one another. Oracle data type NUMBER(7,1) Producer defined Measured in meters STATUS Status of collected data as a "Valid Reading" or an "Error" determined by software. Note that the software will not catch all errors. E = error, D = valid reading. Note taht is Elapse_Time was left null that the status column has also been left null. Oracle data type CHAR(1) Producer defined E = error, D = valid reading W_DATE Date the data were recorded, produced by the mensuration gear software. Oracle data type DATE. Producer defined Date. DD-MMM-YY W_TIME Time data were recorded. Oracle data type VARCHAR2(8) Producer defined Either in a XX:XX:XX or XX:XX format. OP_ID Artificial op table sequence number (linked to op table). Foreign key value. OP_ID is used as a linking variable between the tables in the RVCAT Database. OP_ID is assigned by Oracle based on the OP table Primary key fields: Year, Lake, Vessel, Serial, and Sample Type. Note that for most end users of the RVCAT database, the OP_ID is not a visible value. When querying the database, OP_ID is the most important attribute linking the RVCAT tables together. Oracle data type NUMBER(6) Producer defined Foreign key value W_TEMP Temperature reading produced by the mensuration gear software at the specified Meters, Date, and Time. Oracle data type NUMBER(3,1). Producer defined Celsius The entity and attribute information provided here describes the tabular data associated with the data set. Please review the detailed descriptions that are provided (the individual attribute descriptions) for information on the values that appear as fields/table entries of the data set. The entity and attribute information was generated by the individual and/or agency identified as the originator of the data set. Please review the rest of the metadata record for additional details and information. GS ScienceBase U.S. Geological Survey mailing and physical

Denver Federal Center, Building 810, Mail Stop 302

Denver CO 80225 United States 1-888-275-8747 sciencebase@usgs.gov Unless otherwise stated, all data, metadata and related materials are considered to satisfy the quality standards relative to the purpose for which the data were collected. Although these data and associated metadata have been reviewed for accuracy and completeness and approved for release by the U.S. Geological Survey (USGS), no warranty expressed or implied is made regarding the display or utility of the data on any other system or for general or scientific purposes, nor shall the act of distribution constitute any such warranty. In order to make the data accessible, this data has been published as CSVs for public use. Note, however, that the original data were saved in an Oracle database and the use of a database to analyze this data set will aid in the comprehension of the data 20200820 Sofia Dabrowski Five River Services, U.S. Geological Survey, Midwest Region Information Services Contractor mailing and physical

1451 Green Rd

Ann Arbor MI 48105 US 734-214-7213 734-994-8780 sdabrowski@usgs.gov Content Standard for Digital Geospatial Metadata FGDC-STD-001-1998