Catch-In-Areas Main

The Catch-In-Areas database integrates catch data from the Catch Accounting System (which has the spatial resolution of a NMFS Reporting Area) into a database that resolves the GIS data into polygons of approximately 7.5 km. In unrestricted outside waters, sixty four grid IDs fit inside one state statistical area. A state statistical area is = degree in latitude and one degree in longitude block. The 7.5 km grid size was picked for two reasons 1) we were likely to pick up at least one 30 minute VMS ping for a vessel running at fishing speed; and 2) the size (.125 degree latitude) is perfectly divisible in geographic coordinates so they fit perfectly inside a state statistical area. The grid polygons are often further divided into smaller polygons by the boundary of state statistical areas, the boundary of state and federal waters, or by the boundary of Steller sea lion critical habitat (broken out at 3, 6, 10, and 20 nautical miles from each of the 154 Steller sea lion rookeries and haulouts). Where confidentiality and mapping is an issue, seven-kilometer polygon are pre-coded for grouping into (3x3) 23km polygons. Each grid-id can queried individually or by sets of pre-coded attributes, such as reporting area and distance from Steller sea lion sites.

The Catch-In-Areas database integrates catch data from the Catch Accounting System (which has the spatial resolution of a NMFS Reporting Area) into a database that resolves the GIS data into polygons of approximately 7.8 km. The spatial resolution is added to Catch Accounting using a combination of Observer and VMS data, where for observed vessels observer data is joined with VMS data; for unobserved vessels, VMS data is used to find fishing locations based on time periods and reported state statistical areas.

Loaded by FGDC Metadata Uploader, batch 7101, 09-22-2015 18:52

The following FGDC sections are not currently supported in InPort, but were preserved and will be included in the FGDC export:

- Spatial Reference Information (FGDC:spref),

- Spatial Data Organization Information (FGDC:spdoinfo)

Steve Lewis

Observed Fleet

We begin by separating VMS records as observed catch or unobserved. A record is considered observed when the federal observer logs the deploy time and retrieve time of a haul. The VMS records are processed when the vessel-id and date-time are within the observed times. A series of Speed algorithms clean the data of Observer or VMS outlier records. Speed is computed after each cleaning subset using several algorithms, simplified below.

When the speed is greater than 8.5knots, the VMS or Observer records are removed as long as there are greater than 2 records

When there is more than one VMS transponder associated with an observed haul, we only keep the VMS transponder that is closest to the observed retrieve location.

Most VMS data is removed from Hook-and-Line and Pot Observed records since the gear is dropped and retrieved while the vessels loiters or deploys other sets of gear.

When only a single observed record is available by haul, we add .002 to the Latitude and Longitude of the observed retrieve location in order to have enough points to build a line.

When a VMS or Observed point is greater than 120km from the observed deploy or retrieve point, the record is deleted.

The observed-VMS lines are built in ArcMap, grouped by the Catch Accounting Reference Key and sorted by the date-time from the Observed and VMS records. These lines can be simple, straight or very complex that run back and forth several times between the relevant VMS and observer points. All segments of the lines are used in the proportional calculations that follow.

After the lines are created, they are moved back to SQL Server and intersected onto the Grid Area GIS feature class. This spatial intersect operations splits each line into parts that are referenced by the grid IDs. The Catch-In-Area database attributes catch based on the effort a vessel spends fishing. In order to apply the effort, we divide the line length [by grid id] by the total line length. This gives us the proportion of the line falling into each grid id. In affect the Catch-In-Areas is an effort based product.

For catcher processors the catch is assigned by individual haul from the Catch Accounting System to each based on the length of the line.

For catcher vessels, the catch is split by individual haul into grid-IDs but then aggregated to the catcher vessels reported trip. A related algorithm applies the catch of the Observed haul to the trip. This is due to Catch Accounting assigning catch by a catcher vessel's trip rather than by individual haul.

Unobserved Fleet

A portion of the fishing fleet is unobserved because they are too small, are within a gray area of being a partially observed, or simply do not require a federal observer. Many of these vessels only report the state statistical area where they fished and time period (in days) when they were fishing. Almost all of these vessels are required to carry VMS though. Instead of attempting to build a line based on unobserved VMS data where data may be sparse and spread-out, we instead depend on the VMS-points intersected onto the grid-id feature class.

The criteria the Catch-In-Areas database uses to find a vessel that is fishing instead of cruising or being idle include 1) A vessel must be operating between .9 knots and 4.1 knots; 2) a vessel must not be in an area known not to be a fishing area, e.g., very near ports; 3) a vessel must be operating inside at least one of the state statistical areas reported on its fish ticket; and 4) the date-time of the VMS point must be within the date range on the fish ticket.

We use the vessels reported latitude and longitude to determine vessel speed. This calculation is based off the standard formula:

Radius_of_the_Earth*((2*ASIN(SQRT((SIN((RADIANS(LAT1)-RADIANS(LAT2))/2)2)+COS(RADIANS(LAT1))*COS(RADIANS(LAT2))*(SIN((RADIANS(LONG1)-RADIANS(LONG2))/2)2))))) Geoid 6371.1

A catch record in this process is weight

SQL Server Database

Attribution included

Confidential Fisheries Data

Confidential

Data is confidential and requires a confidentiality form.

Steve.Lewis@noaa.gov

None

None

.

.

Microsoft Windows 7 Version 6.1 (Build 7601) Service Pack 1; Esri ArcGIS 10.3.1.4959

Catch-In-Areas database matching algorithms match 99.976% of the Catch Accounting to spatial data.

Data has embedded 'metadata' called the Match-Source column, that identifies each row in the database to a specific matching method.

Checksum and Go-NoGo tables are created in order for analytical products to be built.

Data has embedded 'metadata' called the Match-Source column, that identifies each row in the database to a specific matching method.

Checksum and Go-NoGo tables are created in order for analytical products to be built.

Approximately 96% of the catch is matched directly and 4% of the catch is matched using very specific extrapolations.

VMS units depend on satellites and while the vessel's transponders should buffer the signal until it has captured a satellite, it does not always work that way. Therefore we only match only 96% of the catch.

There other other issues with data including date mis-compares.

VMS-Obs-UnObs database; another part of the Catch-In-Areas.

Tuning of database and adjusting for new types of data.

7.8 kilometers.

7.8 kilometers.

variable

VMS

See Checksums

See Checksums

Checksums, match-source, enterprise DBMS standards

Data has to be recompiled into a non-confidential dataset and moved to the public access location

Data is backed up in both DBMS and FileGeoDatabase format.

Observed Fleet

We begin by separating VMS records as observed catch or unobserved. A record is considered observed when the federal observer logs the deploy time and retrieve time of a haul. The VMS records are processed when the vessel-id and date-time are within the observed times.

Unobserved Fleet

A portion of the fishing fleet is unobserved because they are too small, are within a gray area of being a partially observed, or simply do not require a federal observer. Many of these vessels only report the state statistical area where they fished and time period (in days) when they were fishing. Almost all of these vessels are required to carry VMS though. Instead of attempting to build a line based on unobserved VMS data where data may be sparse and spread-out, we instead depend on the VMS-points intersected onto the grid-id feature class.

After the lines are created, they are moved back to SQL Server and intersected onto the Grid Area GIS feature class. This spatial intersect operations splits each line into parts that are referenced by the grid IDs. The Catch-In-Area database attributes catch based on the effort a vessel spends fishing. In order to apply the effort, we divide the line length [by grid id] by the total line length. This gives us the proportion of the line falling into each grid id. In affect the Catch-In-Areas is an effort based product.

Data is spatially intersected onto Grid and then joined to V_CAS_Primary_All using a precise matching algorithm.

The final table includes data from five tables

[V_CAS_TXN_PRIMARY_ALL]

.V_ELPR_VWPR_PRODUCT

.V_ELLR_SLOG_PRODUCT

.V_OBS_HAUL

.V_VMS_VESSEL_LOCATION

.V_OBS_HAUL_SPECIES_ALL]