creel survey, fisheries, design-based inference, R, tidycreel, Quarto
13.1 Purpose
Section 12.5 introduced spatial strata: divide a large waterbody into reaches or basins, sample each one, and let each contribute a separately weighted component to the total. That description is correct for the estimator, but it does not fully describe why managers often divide a waterbody.
Spatial sections often have a second job that temporal strata do not. Strata are usually a means to a more precise total, and they may never appear in a report. Sections exist because someone needs to know what is happening in the north basin as distinct from the south. The estimate for each part is a result in its own right, alongside the lake-wide total. An agency that closes one arm of a reservoir to boat traffic, for example, needs an estimate and confidence interval for that arm as well as for the whole reservoir.
tidycreel treats that second job as a first-class part of the design rather than as post-hoc reporting. add_sections() registers the spatial partition, and the estimators then return one row per section plus an aggregated .lake_total row. This chapter covers:
what distinguishes a section from a stratum, and why the two can cross-cut each other;
registering sections with add_sections() and reading the resulting estimate table;
how the lake-wide row is combined from the sections, and when that combination assumes something it should not;
how a party-size expansion interacts with the section partition, an especially important setting in which a plausible-looking standard error can be wrong;
handling sections that were registered but never sampled.
13.2 A section is not a stratum
Both are partitions of something. A stratum partitions the sampling frame — the set of days, shifts, or count times from which the sample is drawn. A section partitions the water. Nothing forces those two partitions to line up, and in practice they usually do not.
Consider a reservoir sampled on both weekdays and weekend days, divided into a north and a south basin. The day-type stratification and the basin division are independent of one another: every basin is sampled on weekdays and on weekend days. Neither partition is nested inside the other. A quantity defined on one — a weekday mean, say — spans both parts of the other.
This distinction deserves more than a paragraph in Section 12.1. Reasoning that is valid for strata is not automatically valid for sections: in the same design, a statement such as “each part carries its own independent estimate” can be true for one partition and false for the other.
Important
Sections and strata are different partitions and may cross-cut. A quantity that is confined within each stratum can still span every section, and the reverse. When you reason about whether two parts of an estimate are independent, be explicit about which partition you are asking about.
There is also a practical difference in how the two are supplied. A stratum is a column in the calendar, and the design knows the full population of days in each stratum. A section is registered explicitly from a table of the sections that exist, which is what allows tidycreel to distinguish a section that was sampled and found empty from a section that was never visited at all — a distinction the estimator cannot make from the count data alone.
13.3 Registering sections
Sections are added to a design with add_sections(), before the counts and interviews. The sections table lists every section that exists in the fishery, whether or not it was sampled.
The counts and interviews both carry a section column, and every registered section is sampled on every one of the twelve survey days. Registering the sections changes what the estimators return: instead of one row for the whole water, the result carries one row per section and an aggregate.
Code
estimate_effort(design)$estimates
Warning: Instantaneous counts were expanded without a period length.
ℹ No `period_length_col` was supplied to `add_counts()`, so the estimate is the
count column summed over days.
! If that column holds an instantaneous angler count, the result is in
angler-days, not angler-hours.
ℹ Supply the period each count was randomised within: `add_counts(design,
counts, period_length_col = <col>)`.
This warning is displayed once per session.
# A tibble: 4 × 11
section estimate se se_between se_within ci_lower ci_upper n
<chr> <dbl> <dbl> <dbl> <dbl> <dbl> <dbl> <int>
1 North 269 12.3 12.3 0 242. 296. 12
2 Central 472 19.0 19.0 0 430. 514. 12
3 South 105 9.18 9.18 0 84.6 125. 12
4 .lake_total 846 39.4 39.4 0 758. 934. 36
# ℹ 3 more variables: prop_of_lake_total <dbl>, se_prop_of_lake_total <dbl>,
# data_available <lgl>
Four columns are worth reading carefully.
section names the part, with the aggregate row labelled .lake_total. The leading dot marks it as a value the package inserted rather than one that came from the data, so a section genuinely named “lake total” could never be confused with it.
prop_of_lake_total gives each section’s share of the total. It is often the most useful column for a management report, even when the headline number is lake-wide.
data_available distinguishes a section with no fish from a section with no data. A registered section that was never sampled appears as a row of NA values with data_available = FALSE, rather than being silently dropped from the table or, worse, contributing a zero to the total.
Interpret n in the context of the estimator. For a catch-total aggregate it is the number of contributing sections; for the effort aggregate it is the number of contributing section-day observations. The per-section catch rows carry the interview counts.
The catch-total table uses the same section and availability columns:
# A tibble: 4 × 9
section estimate se ci_lower ci_upper n prop_of_lake_total
<chr> <dbl> <dbl> <dbl> <dbl> <int> <dbl>
1 North 285. 23.1 232. 339. 9 0.228
2 Central 711. 29.9 642. 780. 9 0.567
3 South 257. 22.7 205. 310. 9 0.205
4 .lake_total 1254. 44.1 1163. 1345. 3 1
# ℹ 2 more variables: se_prop_of_lake_total <dbl>, data_available <lgl>
13.4 How the lake row is combined
The point estimate on the .lake_total row is a sum: because the sections partition the water, their totals add.
The standard error requires more care because it depends on how the component estimates co-vary. When sections are counted and interviewed separately, their sampling errors usually arise from disjoint observations and combine in quadrature:
For effort, tidycreel builds the lake-wide contrast inside the survey-design object rather than combining per-section standard errors afterward. This preserves covariance between sections induced by their shared sampling structure (Lumley 2010). As a result, the effort table’s .lake_total standard error need not equal the quadrature of its section rows, whereas the catch table’s does in this example.
Note
Quadrature is not wrong here — it is a statement that the sections are independent, and for the sampling error of separately observed sections that statement is usually true. The care is needed for quantities that are not observed separately, which is the subject of the next section.
13.5 Sections and the party-size expansion
Many creel designs do not count anglers directly. They count boats and multiply by an estimated mean party size, an approach Pollock et al. (1994) and Malvestuto (1996) both treat as standard practice. That multiplier is an estimate, with a standard error of its own, and tidycreel propagates it into the effort standard error rather than treating the party size as though it were known.
The multiplier introduces a dependency that the section-specific sampling error does not have. If one party-size estimate is applied to every section, its uncertainty is a single random quantity shared across them. If that estimate rises, every section total rises with it. Perfectly correlated contributions add before squaring, not after:
where R_i is section i’s rate and s_i its share of the party-size term. The first quantity is larger whenever more than one section contributes. Treating a shared multiplier as independent therefore understates the uncertainty of the lake total.
Which expression applies depends on the geometry of the estimate: does a party-size estimate stay within one section, or does it span several? The following rotating-section example makes the three possibilities concrete. Each day is sampled in exactly one section, alternating between them; the section partition deliberately cross-cuts the day-type strata, so each section includes two weekdays and two weekend days.
One estimate spans both sections, so the two contributions are perfectly correlated. The component the package reports for each row makes the arithmetic visible: the lake entry is the sum of the section entries, not their quadrature.
Code
catch_shared$se_expansion
[1] 3.9375 3.7125 7.6500
One estimate per section
Now suppose party size was estimated separately in each section, from that section’s own interviews. The two estimates are independent, and their contributions combine in quadrature.
The two designs use the same boat counts, interviews, party-size value (2.5), and party-size standard error (0.1). They differ only in whether those values came from one estimate or two. That distinction changes the lake-wide standard error:
The point estimates are identical; only the uncertainty changes with the correlation structure.
Warning
A design cannot have a section-specific party-size estimate unless each sampled day belongs to a single section. The primary sampling unit is the day, and one day carries one party-size estimate; a day sampled in two sections at once cannot carry a different multiplier in each. add_counts() rejects that configuration rather than picking one. This is why the example above uses a rotating-section design — with all sections sampled every day, only the shared case is reachable.
An estimate that straddles the sections
The third case is more difficult. Suppose party size is estimated by day type — one value for weekdays and another for weekends. With respect to the strata, this is neatly nested: each estimate remains within one stratum.
With respect to the sections it is neither nested nor shared. Each estimate covers part of both sections, and neither section is covered by a single estimate.
The lake-wide standard error is NA, with a warning explaining why. Combining the sections would require the allocation of each party-size estimate across sections, information that a per-section standard error no longer retains. Quadrature would understate the result and a linear sum would overstate it. Either would be a plausible number built on an unsupported assumption.
Returning NA is a deliberate choice, and it is worth being clear about what it means. It does not mean the uncertainty is zero, and it does not mean the estimate failed. It means the standard error of the lake-wide total is unknown given how the party size was estimated. The per-section rows are unaffected and still carry their own standard errors, and the point estimate is unchanged.
# A tibble: 3 × 3
section estimate se
<chr> <dbl> <dbl>
1 North 98.4 32.4
2 South 92.8 17.9
3 .lake_total 191. 37.2
If a lake-wide standard error is required from a design in this position, the fix is at the estimation step rather than the reporting step: estimate party size either within sections or once for the whole design, so that the contributions are either cleanly independent or cleanly shared.
Note
This is an instance where the honest answer is less convenient than the wrong one. Earlier versions of tidycreel combined these sections in quadrature and returned a number, thereby assuming a geometry the design did not have. A missing value that prompts a design question is preferable to a plausible value that hides one.
13.6 Registered sections that were never sampled
A section can be registered and then not appear in the count or interview data — a reach closed for the season, an arm the crew could not reach. tidycreel treats this as a reportable fact rather than an error, because a section missing from the data is exactly the sort of thing that should be visible in the output table.
By default the estimator warns and inserts an NA row with data_available = FALSE. Passing missing_sections = "error" turns it into a hard failure instead, which is the right setting for a production pipeline where an unsampled section means something upstream went wrong.
The aggregate row can also be suppressed with aggregate_sections = FALSE, which returns the per-section rows alone. This is useful when the sections are the deliverable or when reporting a lake-wide figure would invite an interpretation the survey cannot support.
Important
An absent section contributes nothing to the lake-wide total, which means the total is over the sections that were sampled, not over the fishery. If a registered section is missing, the aggregate row is a partial total and should be reported as one. Check data_available before quoting .lake_total as a lake-wide figure.
13.7 Takeaway
Sections answer a different question from strata. Strata are used to improve precision for a total; sections make the parts reportable. The two partitions can cross-cut, and that fact drives most of the care required in this chapter.
In practical terms:
Register every section that exists with add_sections(), not only the ones you expect to sample — that is what makes an unsampled section visible instead of absent.
Read data_available before quoting .lake_total; with a section missing it is a total over the sampled sections, not over the fishery.
Use the per-section rows when the management question concerns a place. prop_of_lake_total is often particularly useful for reporting relative use or catch.
When a party-size expansion is in play, ask which partition the multiplier respects. One estimate for the design and one estimate per section are both well behaved; an estimate keyed to something that cross-cuts the sections is not, and will return NA rather than guess.
If you need a section-specific party size, the design has to sample each day in a single section. That is a field-scheduling decision, and it has to be made before the season, not at analysis time.
Treat an NA standard error as a question about the design rather than a defect in the software. It is telling you that the quantity you asked for is not identified by the way the inputs were estimated.
Lumley, T. 2010. Complex surveys: A guide to analysis using R. John Wiley & Sons, Hoboken, New Jersey.
Malvestuto, S. P. 1996. Sampling the recreational creel. Pages 591–623 in B. R. Murphy and D. W. Willis, editors. Fisheries techniques, 2nd edition. American Fisheries Society, Bethesda, Maryland.
Pollock, K. H., C. M. Jones, and T. L. Brown. 1994. Angler survey methods and their applications in fisheries management. American Fisheries Society, Bethesda, Maryland.