F.get.catch.data: F.get.catch.data

In tmcd82070/CAMP_RST: CAMP RST R Routines

F.get.catch.data

Description

Fetch catch data from an Access database and perform some initial computations, like dates.

Usage

F.get.catch.data(
  site,
  taxon,
  min.date,
  max.date,
  output.file,
  autols = FALSE,
  nls = NULL,
  weightuse = NULL,
  reclassifyFL = FALSE
)

Arguments

site	The identification number of the site for which estimates are required.
taxon	The species identifier indicating the type of fish of interest. This is always 161980; i.e., Chinook Salmon.
min.date	The start date for data to include. This is a text string in the format %Y-%m-%d, or YYYY-MM-DD.
max.date	The end date for data to include. Same format as min.date.
output.file	A text string indicating a prefix to append to all output.
autols	A logical indicating whether or not lifestage assignment should be decided by the computer via a mixture distribution/clustering analysis.
nls	A numeric communicating the number of new lifestages to assign. Values can be 2 or 3.
weightuse	A logical indicating if weight data are to be incorporated in the assigning of lifestage. useWeight=NULL, ignored if autols is FALSE, NULL leads to the program deciding if weight should be used, FALSE lead to the program not using weight to assign lifestage.
reclassifyFL	A logical indicating if passage should be estimated via forklength-based class groups.

Details

Function F.get.catch.data fetches all appropriate catch data from an Access database, and then processes it for further use. The processing includes several steps. Currently, although variable includeCatchID is separately queried, it is not used in processing after the initial catch query.

Each record contained in the resulting data frame itemizes fork length, lifestage, and final run, via variables forkLength, lifeStage, and FinalRun, respectively, for each unique combination of trapVisitID and trapPositionID.

Counts of captured fish are recorded via variable Unmarked, with zero catch containing a 0. Zero records additionally have variables lifeStage and FinalRun equal to Unassigned.

Value

A data frame summarizing catch for the site of interest for all traps between the dates indicated. Data include biologist- or computer-assigned lifeStage, FinalRun, and forkLength.

Additional variables result from the computaton of catch following expansion for half-cone operations.

Variables modAssignedCatch and modUnassignedCatch house the results following half-cone operation manipuation, with each equal to the sum of the originally recorded number of catch of that type, together with the extra fish added due to half-cone operations. Variables halfConeAssignedCatch and halfConeUnassignedCatch contain the extra additive fish due to half-cone operations. Finally, variables assignedCatch and unassignedCatch tabulate the number of these type of fish prior to the application of the plus-count routine, where variable Unassd contains the FinalRun value prior to its implementation. Note that non-zero values of unassignedCatch correspond to values of "Unassigned" in variable Unassd. Finally, variable preUnmarked contains the value of variable Unmarked, i.e., the number of relevant fish, prior to implementation of the plus-count routine. The values contained in Unmarked, or counts of fish, change during the half-cone and plus-count processes, and so is retained via preUnmarked for purposes of fish accounting later.

Lifestage

Users have the options of reassigning lifestage away from the assignments provided by field biologists at the time of capture. Options for reassignment number several, and are itemized in the See Also section in function passageWithLifeStageAssign.

Gaps in Fishing

Sometimes, during the normal course of fishing, a trap, or trapPositionID, stops fishing for an extended period of time in the middle of the time frame specified by min.date and max.date. During this so-called "gap in fishing," subsequent catch fitting methodologies have no data via which to estimate catch fit. Thus, unexpected behavior may occur, especially if catch was trending upwards/downwards immediately before/after a gap in fishing. To prevent statistical methodologies from estimating catch during these periods, catch imputation procedures are "turned off" by reassigning the trapPositionID of the offending trap after the gap to a different trapPositionID. In this way, catch is independently estimated for each disconnected trapping period, with no estimation occurring during the gap. Gaps must be greater than or equal to the value set by global variable fishingGapMinutes for reassignment to occur, which is currently set at 7 days (or 10,080 minutes).

Any one trap, given a min.date and max.date, may have more than one gap in fishing. Generally, the number of resulting reassigned trapPositionIDs equals one more than the number of gaps. Reassigned traps can be identified by a decimal appendage after the original trapPositionID, although the first trapping instance, i.e., before the first (and possibly only) gap in fishing, retains its original non-decimal trapPositionID.

Half-cone Adjustment

On some rivers, the use of half-cone adjustments is commonplace. Practically, the use of a half-cone involves covering half of a trap opening, so as to reduce the amount of water that flows into it. This also necessarily reduces the amount of captured fish as well. In order to accurately estimate temporal catch trends, statistical methodologies need to account for this expected reduction. However, a season could include trapping instances involving both full-cone and half-cone operations. To account for this possibility, trapping instances utilizing half-cones via variable halfConeID have their catch multiplied by the value of the global variable halfConeMulti, which is currently set at 2.

Within the process of estimating passage, original catch is paritioned into many different groupings. This eases calculations and provides a check; see "Fish Accounting" in functon F.est.passage. Generally, variables check for appropriate tallying of added half-cone fish for each of assigned and unassigned catch. A break-out for tallying counts of fish between assigned and unassigned catch is necessary due to plus-counting.

The check for assigned fish sums the counts of assigned fish and the added count of half-cone fish, following plus-counting. Practically, variable halfConeAssignedCatch is summed with variable assignedCatch to form variable modAssignedCatch, with all three variables containing integer counts of fish. The plus-count algorithm applies proportions of observed fish to unassigned fish, often resulting in fractional fish. Due to rounding, this means that sometimes, the numbers of half-cone fish does not exactly equal the number of assigned fish. See F.assign.1dim.

A similar calculation sums variables halfConeUnassignedCatch and unassignedCatch of integer fish to create variable modUnassignedCatch.

Half-cone Operations & Plus Counts

Generally, during a trapping instance, a small sample is selected from what may be many thousands of fish. The resulting sampling distribution, in terms of lifestage and run, is then applied to the remaining fish not randomly sampled. The resulting assigned proportions of unsampled fish form "plus counts." Functions expand.plus.counts, assign.1dim, and assign.2dim detail the plus-count algorithm. Plus-counting requires special consideration in light of half-cone adjustments.

Generally, the estimation of plus counts requires a sample. Thus, prior to its implementation, any half-cone adjustments must already be applied. However, the plus-count algorithm often considers the sampling distribution of fish from trapping instances temporally neighboring that of the trapping instance of interest. Inevitably, a before and/or after trapping instance may have been a full-cone operation, in contrast to the half-cone operation of the trapping instance of focus, or vice versa. Thus, resulting sampling distributions can become skewed, i.e., the amount by which a half-cone trapping instance must have its fish counts expanded is not necessarily an exact multiple of 2.

To combat this phenonmenon, trapping instances with half-cone operations are not simply multiplied by the value of the global variable halfConeMulti. Instead, the plus-count routine is applied twice, both with and without the halfConeMulti adjustment applied. Then, for each trapping instance, the difference in the count of fish is then recorded as the "half-cone adjustment" for that particular lifestage, final run, and forklength combination. In this way, half-cone adjustments are obtained, while taking into consideration the possibility that in some instances, simple application of the halfConeMulti variables is not advised.

Not Fishing

Similar to "gaps in fishing" are periods of "Not fishing." An instance of "Not fishing" is a period during which a trap does not operate for more than 30 minutes, but less than 7 days. Instances of "Not fishing" are included as records within the data frame returned by function F.get.catch.data, and can be identified by variable TrapStatus, which is set equal to "Not fishing". Equivalently, variable trapVisitID is missing.

See Also

expand.plus.counts, assign.1dim, and assign.2dim for plus-counts. Also getCatchDataWeight.R, assignLifeStage.R, assignLSCompare.R for life stage reassignment.

Examples

 
## Not run: 
#  ---- Fetch catch data on the American. 
site <- 57000
taxon <- 161980
min.date <- "2013-01-01"
max.date <- "2013-06-01"
autols <- FALSE
nls <- NULL
weightuse <- NULL
reclassifyFL <- FALSE

catch <- F.get.catch.data(site,taxon,min.date,max.date,
  autols,nls,weightuse,reclassifyFL)

## End(Not run)

tmcd82070/CAMP_RST documentation built on April 6, 2022, 12:07 a.m.