How to join

You do not need a GitHub or Google account. Either:

• send an email (any subject, any content) to tidycreel-announce+subscribe@googlegroups.com, or
• visit the group page and click Join group.

To leave, send an email to tidycreel-announce+unsubscribe@googlegroups.com. Every message includes that address.

What you will get

• [CRAN]: each new CRAN release, about every two months. Each one covers what changed, and whether any estimates are affected.
• [dev]: a monthly update on the development version, with a link to a post on this blog, like this month’s.

That’s all. Only I post to the list, so it carries no discussion threads and no questions from other members. The member list is private. If you reply to an announcement, the reply comes to me, not the whole list.

For questions and bug reports, the GitHub issues page is still the best place.

If you prefer RSS, this blog has a feed for tidycreel posts only, at https://chrischizinski.com/blog-tidycreel.xml.

The default total is now the season total

This is the change most users will notice first.

estimate_effort(), estimate_total_catch(), estimate_total_harvest() and estimate_total_release() used to default to target = "sampled_days": the total over the days that were actually counted. They now default to target = "period_total": the total for the season. Both printed as “Method: Total”, so a default call on a partly sampled season quietly reported a fraction of it. On the package’s example season, 36 of 120 days were sampled, and the default effort was 3,066 angler-hours against a season total of 9,994.

Every default total on a design that did not sample every day changes. To get the old numbers, ask for them by name with target = "sampled_days".

A related check: add_counts() now warns when every day of every stratum has a count. The calendar is the population of days, so a calendar built from only the sampled dates turns the design into a census, and the season total becomes the effort of those days alone. In one example that was 2,380 angler-hours against 8,651 for the full 61-day season, with nothing said. If you see this warning, pass the full season calendar to creel_design().

Estimates that change

These fixes move point estimates, not just standard errors.

• Aerial catch, harvest and release totals were too small. They were computed from the raw instantaneous count rather than from effort, so they missed the h_open, angler-ratio and visibility scaling that estimate_effort() applies: 14 times too small with h_open = 14. If you have reported aerial totals from 8.0.0, re-run them.
• Refused interviews were used as real trips. add_interviews(refused =) stored the flag, but no estimator read it, so a refused party usually entered the rate with a catch of 0. Flagging 10 interviews as refused on the example data took the catch rate from 2.29 to 1.03. Refused interviews are now set aside, with a message giving the count.
• Roving (mean-of-ratios) rates now weight each party by its size when n_anglers is available. The estimator is defined per angler, but an interview is a party. Weighting parties equally leaned toward small parties’ rates; in a simulation where larger parties caught fish faster, the old rate was 23% low. On the example roving data the rate moves from 0.197 to 0.191 fish per angler-hour. Designs without n_anglers, or with a constant party size, are unchanged.
• Catch rows with no species are refused. They were counted in the all-species total and dropped from every species row, so the species rows did not add up to the total. Label them (for example "unidentified", which is reported as its own species) or drop them on purpose.
• Counts dated outside the calendar, or in the wrong stratum, are refused. A count outside the calendar became a sampled day the population did not contain: four such counts moved a test effort estimate from 151 to 277.
• Sectioned catch totals use the stratified sum. Without by, each section’s effort was multiplied by one rate pooled across its strata, so a section’s total could differ from the sum of its by = day_type rows (by up to about 4% on the package fixture).
• summarize_cws_rates() handles creels that record only harvest and release. It read only "caught" rows, so such creels got a CWS of 0. On the example data, bass moves from 0.052 to 0.185 and walleye from 0.462 to 0.629.

Standard errors that change

Point estimates are unchanged in this group; the uncertainty around them moves.

• The finite-population correction no longer erases count-timing uncertainty. On season and stratum totals, a stratum where a sampled day had a single count could have its standard error shrunk to nothing, because sampling more days does not remove the uncertainty about when in the day the count fell. With every day sampled, the SE was exactly 0. On the example season the effort SE rises from 1,079 to 1,286 angler-hours, and every catch, harvest and release total built on that effort inherits the change.
• Within-day variance is no longer counted twice on target = "sampled_days" with two or more counts a day. On a four-day test fixture the SE falls from 276.9 to 100.
• Designs with more than one strata column (for example strata = c(day_type, month)) had their standard errors computed over the first column only. In one season the effort SE was 147.7 where it should have been 187.9.
• Sectioned lake totals now account for sections that rise and fall together. A busy day is busy in every section, and the lake total had treated sections as independent. In simulation, interval coverage went from 91.5% to 94.8%.
• The bootstrap no longer reports zero variance for a stratum with one sampled day. That design is now refused, as Taylor and the jackknife already refused it.
• An unknown within-day component is reported as NA, not 0. With one count a day, the within-day part cannot be separated out. The total SE is unchanged, but se_within now says “unknown” rather than “measured and found to be zero”.

The package stops instead of guessing

A theme runs through many of these changes: an unknown value is not a zero. Where tidycreel used to drop something and report the rest, it now stops and tells you what is missing:

• A stratum with effort but no catch rate (for example, no complete weekend trips) used to be left out of the catch total, with only a warning. On the package example that left out 54% of the season’s effort. It now stops and names the cells. missing_rate = "exclude" is the explicit way to leave them out, and the result records what was excluded.
• On bus-route and ice designs, parties that were counted but not interviewed entered totals as zero effort and zero catch. They are now refused by name.
• A season total that would silently leave out a never-sampled stratum (a Labor Day stratum, say) is now refused.

If your script stops where it used to run, the error message names the problem and the way forward.

Less noise

Warnings have been sorted into tiers. Warnings that the estimate may be wrong still print every time. Data-quality warnings now print once per design rather than on every call: one season script went from 216 copies of the same warning to one. Information that is not a warning, such as the count of zero-catch interviews, is now a message. get_warnings() lists everything that was raised on a design or an estimate.

New in the development version

A short list. The NEWS has the details.

• creel_calendar() builds the season calendar that creel_design() takes.
• Night creels: schedules and designs whose survey day crosses midnight.
• write_design() and read_design() save a design and rebuild it.
• summarize_rws_rates() for released-while-sought rates.
• prep_interview_totals() builds each interview’s catch, harvest and release totals from a long catch table, so interviews and catch can come from the same records.
• A new example dataset, example_roving_interviews.
• The vignettes were reorganized into a tutorial, how-to guides, explanations and reference, and checked against the code.

What to do

• If you use aerial designs, re-run your catch, harvest and release totals.
• If your totals changed and you want the old numbers, add target = "sampled_days". Then check whether the season total is what you meant all along.
• If you hit a new error, read it: it names the stratum, date or row involved.
• If something looks wrong, please open an issue.

All of this is planned for the next CRAN release in December.

Stay up to date

To get these updates by email, join the tidycreel-announce mailing list. You do not need a GitHub or Google account: send an email to tidycreel-announce+subscribe@googlegroups.com. The list carries each CRAN release and this monthly update, and nothing else. More about the list is in this post.

Describing the Data Source and Survey Design

The linked-tables post asked what one row represents. That distinction remains important when importing data. A single trip may include catches of multiple species but still represents one interview, while multiple counts conducted on the same date represent separate observations.

A connection profile describes the source: where its tables are, which columns contain the needed information, and what its codes mean. The survey design describes how observations were sampled: the calendar, strata, selection probabilities, and field protocol. We need both.

For example, a profile can tell us that HoursFished is the source’s effort column. We still need to know whether those hours describe one angler or a party. Renaming the column cannot answer that question.

Start with a small export we can inspect

The complete R script creates five fictional CSV files and a connection profile, loads the files, checks the results, and attaches the tables to a design. Download it and run it in an R session. It creates a new temporary directory each time and prints its location; the files remain available during that session. No database account is needed.

# Install pak once, if needed.
install.packages("pak")

# Install both GitHub packages and config for this example.
pak::pak(c(
  "chrischizinski/tidycreel",
  "chrischizinski/tidycreel.connect",
  "config"
))

# Run after saving the download in your working directory.
source("tidycreel_connect_walkthrough.R")

Map the names and explain the codes

The script writes a YAML file, creel-config.yml. YAML is a text format that allows us to define the data source separately from the analysis code. The files section specifies the paths to the five CSV files, while the schema section identifies the relevant columns and codes. Although the script generates this file, it can also be created or edited outside of R using any text editor. This makes it possible to share a common configuration among users working with the same data sources, without requiring each person to define the connections independently.

Here is the interview portion of that profile; the download contains the complete profile for all five files:

schema:
  survey_type: instantaneous
  columns:
    interview_uid: TripID
    date: SurveyDate
    effort: HoursFished
    n_anglers: PartySize
    catch: TotalFish
    trip_status: TripCode
  strata_cols:
    day_type: DayType
  value_maps:
    trip_status:
      "C": complete

Read each column entry as the name the package expects: the name in our export. The value_maps entry does a different job: it says that our source uses C for a completed trip. That meaning comes from the source documentation. The package cannot infer it from the letter.

The distinction between catch and catch_count is important. In this profile, catch maps to TotalFish, the total catch reported for an interview. The fetched interview table names this column catch_count. In contrast, the profile’s catch_count entry maps to FishCount, the number of fish recorded for each species in the separate catch-detail file. The complete example includes both mappings.

After loading, the same first three interviews look like this:

The observations have not changed. The names and trip-status code now have an explicit translation. Dates are read as dates and numeric fields are coerced and checked. Party size remains available for the later calculation of angler-hours.

Fetch each table without flattening the survey

With the profile written, loading the data takes a connection and the appropriate fetch functions:

library(tidycreel)
library(tidycreel.connect)

conn <- creel_connect_from_yaml(profile_path)

interviews <- fetch_interviews(conn)
counts <- fetch_counts(conn)
catch_data <- fetch_catch(conn)
harvest_lengths <- fetch_harvest_lengths(conn)
release_lengths <- fetch_release_lengths(conn)

Here, profile_path points to the YAML file created by our script. When working with your own data, replace it with the path to your own yaml file.

The tables remain separate. In this example, the row counts before and after fetching are:

The catch file has seven rows because one interview has two species and two interviews have zero catch. That arrangement is intentional. Joining the catch file onto the interviews and summing repeated trip hours would change what the total represents.

The CSV connection currently requires paths for all five tables. When no release lengths were collected, the example supplies an empty CSV with the appropriate headers. An empty measurements table does not establish how many fish were released; that information belongs in the catch records.

Validate the Imported Data

I want to check a few things while the export and the imported tables are still easy to compare. The script verifies that interview identifiers and count times survived, catch and length records link to known interviews, and the interview totals agree with the catch-detail totals in this example.

checks <- c(
  interview_ids_preserved = identical(
    interviews$interview_uid, raw_interviews$TripID
  ),
  count_times_preserved = identical(
    counts$count_time, raw_counts$CountClock
  ),
  catch_records_linked = all(
    catch_data$interview_uid %in% interviews$interview_uid
  ),
  zero_catch_interviews = sum(interviews$catch_count == 0) == 2L
)

print(checks)

The last check is specific to data we constructed. A real export needs checks based on what its records mean. In particular, an absent catch-detail row cannot establish whether the interview had zero catch or whether its catch information is missing.

The download also makes a separate demonstration copy with one unknown catch value and verifies that it remains NA after fetching. That copy is kept out of the design. We should resolve unknown values according to the survey records before estimation, without substituting zeros to make a check pass.

Also read messages about columns that were not carried through. An unused administrative field may be harmless; a missing stratum, party size, or count time can change the analysis. The diagnostics post picks up those checks after the tables are attached.

Bring the sampling plan back in

The source files contain observations from four dates. Our fictional survey season contains nine dates. The calendar needs all nine, including days on which no sampling occurred, as discussed in the sampling-calendar post.

The example assumes equal day-selection probabilities within weekday and weekend strata. Each sampled day covers the entire eight-hour fishing period; there is no random selection of one shift from several. We therefore supply eight actual hours and a period-selection probability of one.

counts$period_hours <- 8

design <- creel_design(calendar, date = date, strata = day_type) |>
  add_counts(
    counts,
    count_col = bank_anglers,
    count_time_col = count_time,
    period_length_col = period_hours,
    p_period = 1
  ) |>
  add_interviews(
    interviews,
    catch = catch_count,
    effort = effort,
    trip_status = trip_status,
    trip_duration = effort,
    n_anglers = n_anglers,
    interview_type = "access"
  ) |>
  add_catch(
    catch_data,
    catch_uid = interview_uid,
    interview_uid = interview_uid,
    species = species,
    count = catch_count,
    catch_type = catch_type
  )

Using bank_anglers as the count is appropriate here because the fictional fishery has only shore fishing. A survey that also counts fishing boats needs the boat component represented and converted appropriately. Likewise, the eight-hour period and probability of one describe this example’s protocol; they are not general defaults for a creel survey.

The count_time_col argument tells tidycreel that the two counts on each date are repeated observations within a sampled day. The resulting design reports four daily count observations, while retaining the information for within-day variation. The fetch step returned all eight source counts.

For add_catch(), both linking arguments select the interview identifier in their respective tables. Despite its name, the catch_uid argument here does not select the unique catch-row identifier. The script also attaches the measured fish through their interview links.

We now have a design containing the imported observations and the declared sampling information. The design-object post explains why keeping those together matters. This example stops at that handoff so we can inspect it before asking for estimates.

A separate repository for the connection work

tidycreel.connect now lives in its own repository, with separate documentation and issue tracker. The separation reflects the different responsibilities of the two packages. tidycreel.connect handles the differences among data sources, translating them into a consistent set of tables, while tidycreel uses those tables to define survey designs and calculate estimates. Keeping these functions separate allows data connections to change without affecting the analytical methods and lets users work directly with tidycreel when their data are already in the expected format.

Connecting Different Data Sources

The CSV example illustrates in this post is only one way to bring data into the tidycreel workflow. tidycreel.connect also supports databases through DBI, including SQL Server via ODBC, and REST APIs configured through a profile. For CSV files and databases, the schema defines how source columns map to the expected fields. API profiles instead specify mappings for endpoint fields. Each data source requires its own description, but the resulting tables follow a common structure that can be used throughout the analysis.

Once a connection profile has been established, it can be reused for subsequent exports that follow the same data structure and recording conventions. This reduces the need to repeatedly define column mappings and interpret source-specific codes. However, changes to the data structure or field protocols may require updates to the profile, the survey design, or both.

In the next post, we’ll bring these connection profiles, validation checks, and survey design decisions into a Quarto report alongside the resulting estimates. This will provide a documented path from the original data to the final results.

Install tidycreel

You can now install the CRAN release using the usual R command:

install.packages("tidycreel")
library(tidycreel)

As of October 15, the 8.0.0 source package and binaries for Windows and macOS are available on CRAN. The macOS binaries support both Apple Silicon and Intel Macs. Use the command above to install the release.

To install the source release explicitly:

install.packages("tidycreel", type = "source")

tidycreel itself has no compiled code. Dependencies installed from source may require build tools.

For the development version from GitHub, use pak:

install.packages("pak")  # Once, if pak is not already installed
pak::pak("chrischizinski/tidycreel")

Use the CRAN release for most analyses. Install from GitHub if you want to try the latest development changes.

Aerial surveys: Use the GitHub development version for catch, harvest, and release totals until 8.0.1 reaches CRAN. It fixes an underestimation issue in 8.0.0; non-aerial designs are unaffected (release notes).

Examples, methods, and vignettes

There are three places to go after installation, depending on what you want to work through:

• The blog series follows small examples from design objects and sampling calendars through roving interviews, linked tables, effort, catch, harvest, and release, and diagnostics.
• The companion book, Modern Creel Survey Analysis in R, develops the reasoning behind those workflows: sampling design, estimands, uncertainty, and interpretation. It remains a work in progress as the methods, examples, and package develop.
• The full vignette collection provides focused package walkthroughs. CRAN includes 24 vignettes, covering getting started, survey designs, interview estimation, incomplete trips, effort and catch calculations, variance methods, scheduling, visualization, and more. They are also available directly from the CRAN package page.

To browse the installed vignettes or open the getting-started guide in R:

browseVignettes("tidycreel")
vignette("tidycreel", package = "tidycreel")

The online collection is useful with a GitHub installation too, since that installation does not build local vignettes by default. Recent blog examples identify the 7.0.0 release they used; this announcement marks the 8.0.0 release.

If you try tidycreel with your own creel data, I would like to hear where the data structures, diagnostics, or examples need more explanation. Questions are welcome in GitHub Discussions, and reproducible bug reports help through the issue tracker.

Start with the tables before building the design

validation_report() checks supplied count and interview tables. It does not need a creel_design object. That makes it useful when an export first arrives, before the design object supplies the sampling context.

Suppose an imported count is negative, another count has a July date in a June survey, and one interview has a missing catch value:

counts_import <- counts
interviews_import <- interviews
counts_import$n_anglers[1] <- -1
counts_import$date[2] <- as.Date("2024-07-05")
interviews_import$catch_total[2] <- NA_real_

raw_report <- validation_report(
  counts = counts_import,
  interviews = interviews_import,
  na_threshold = 0,
  date_range = range(calendar$date)
)
raw_report

The report flags the negative n_anglers value as a failure, the count date as outside the supplied range, and catch_total as having missing data. The summary’s n_pass, n_warn, and n_fail count columns checked, not bad records. Its detail column identifies which columns need attention.

For the underlying column-level results, use validate_creel_data():

field_report <- validate_creel_data(
  counts = counts_import,
  interviews = interviews_import,
  na_threshold = 0,
  date_range = range(calendar$date)
)
subset(as.data.frame(field_report), status != "pass")

These are review prompts, not instructions to replace values. A negative count might be a database sentinel, a transcription mistake, or a problem in an import. The field sheet or database documentation determines the correction. Preserve the imported table and make corrections in a separate, documented step.

The 7.0.0 table checks also have limits. A type check reports a column’s class; it does not establish that the class matches your intended schema. A date-range check applies to a Date column, so parse imported date strings and check parsing failures first. Table-level checks also cannot establish that linked records describe the same trip. The keys introduced in the linked-tables post still need attention.

A passing threshold can still contain missing data

The default na_threshold is 0.10. A column warns when its missing fraction exceeds that threshold. One missing catch value among forty interviews is 2.5%, so this column passes the default missing-value check even though one trip still has an unknown catch value.

Here I set na_threshold = 0 to surface any missing values in the teaching example. That is a review setting, not a universal rule that every column must be complete. An optional comment field and the fishing-time denominator have different consequences for analysis.

Likewise, supplying the survey’s actual date range is more useful than accepting the broad default range of 1970–2100. Neither a threshold nor a green status establishes that an observation can safely enter an estimator. Check the fields that the intended calculation requires.

Compare calendar gaps with the actual sampling plan

The sampling-calendar post distinguished available days from selected days. Our calendar contains sixteen days; the survey sampled eight. Those eight intentionally unsampled days remain in the calendar because they belong to the population of days represented by the effort estimate.

coverage <- check_completeness(design)
coverage$missing_days

In this example, $missing_days contains eight dates. In the 7.0.0 implementation, this component identifies calendar dates with no count records. It does not compare them with the selected schedule. The label alone therefore cannot tell us which dates represent missed fieldwork.

To answer that question, compare the planned visits with the observed records:

planned_dates <- data.frame(date = sample_dates)
observed_dates <- unique(counts["date"])

missing_visits <- dplyr::anti_join(
  planned_dates, observed_dates, by = "date"
)
missing_visits

There are no missing planned visits in the original example. Now remove the June 13 count to simulate a lost record:

counts_missing <- subset(counts, date != as.Date("2024-06-13"))
missing_visits <- dplyr::anti_join(
  planned_dates, unique(counts_missing["date"]), by = "date"
)
missing_visits

This check identifies June 13, a selected day. It needs follow-up: did the clerk miss the visit, did the record fail to upload, or was the survey schedule changed? An observed count of zero would mean the count occurred and found no anglers. An absent record does not establish that outcome.

This example has one count per selected day. With multiple shifts, count rounds, or sites, compare the full visit key, such as date, shift, site, and round. One count on a date does not establish that every scheduled visit occurred. Keep the full population calendar; shrinking it to observed dates would change the population represented by the expansion.

Look for strata with few interviews and strata with none

check_completeness() also flags interview strata below n_min, which defaults to ten. Our original sample has ten weekday and thirty weekend interviews. For illustration, a review threshold of fifteen flags the weekday stratum:

review <- check_completeness(design, n_min = 15L)
review$low_n_strata

The result has key = "weekday" and n_observed = 10. Fifteen is an illustrative review threshold here, not a sample-size recommendation. This component counts interview rows; it does not assess their independence, weights, or eligibility for a particular estimator. Enough rows to pass a threshold do not guarantee useful precision.

In 7.0.0, this low-n check counts strata appearing in the interview table. A stratum with no rows can be absent from the result. To illustrate why that matters, we will keep only the weekday interviews, then join their row counts to the strata in the calendar. Starting with the calendar makes the missing weekend interviews visible:

expected_strata <- unique(calendar["day_type"])
weekday_only <- subset(interviews, day_type == "weekday")
observed_n <- dplyr::count(
  weekday_only, day_type, name = "n_interviews"
)

interview_coverage <- dplyr::left_join(
  expected_strata, observed_n, by = "day_type"
)
interview_coverage$n_interviews[
  is.na(interview_coverage$n_interviews)
] <- 0L
interview_coverage

Replacing the missing row count with zero here is appropriate: there are no weekend interviews in this deliberately reduced table. It does not assign a catch rate of zero. The weekend effort estimate still needs a supported rate before it can contribute to a fish total.

Repeat the coverage check for the observations eligible for your estimator. For the access-point example, inspect complete trips with recorded catch and positive fishing time. Roving interviews need the protocol and trip treatment described in the roving-interview post. Use all the relevant stratum columns when your design has more than day type.

Keep valid zero-catch trips in the denominator

Our forty interviews include eight trips with zero catch. They contribute sixteen angler-hours even though they contribute no fish. Removing those trips raises the sample’s apparent success rate:

That is a 25% increase caused entirely by dropping unsuccessful trips. These pooled sample ratios illustrate the effect of deletion; the previous post’s full-period total still requires rates matched to weekday and weekend effort.

A missing catch value needs a different decision. Setting it to zero asserts that the angler caught nothing. Deleting the interview removes fishing time and changes the represented sample. Recover the value where possible; otherwise, document how missing outcomes affect the analysis and its assumptions. Using na.rm = TRUE does not resolve that question, especially when fish and hours then come from different sets of trips.

We are expanding tidycreel’s error checking

These examples also help explain why we are expanding tidycreel’s error checking. The review documented in #388 used a real 2025 reservoir season to show that a report can identify problems without stopping them from reaching an estimator. In 7.0.0, validate_creel_data() returns the report; it does not stop, remove, or change the supplied data. Calling it is an analyst’s choice, and a fail in the report does not itself stop the pipeline.

The proposed approach has three parts: stop on impossible values or missing fields required by the design when data are attached; warn about suspicious values with counts and examples; and retain a report for broader review. I want a problem such as a negative angler count to be visible where the data enter the analysis, with enough information to find and correct the record.

Related work addresses the coverage questions we just walked through: distinguishing unsampled days from missed scheduled visits (#391), deciding how to handle interviews on unsampled days (#454), and checking counts and interviews against declared shifts (#426). Recent development changes already check count dates and strata against the calendar (#449); those changes are beyond the 7.0.0 release used in this example.

The broader work is still in development. For now, the checks above give us a way to inspect the records, identify the questions, and document the decisions before calculating a total.

Carry the decisions into the report

I would keep a short record of each issue, the evidence used to resolve it, and the resulting action. That might be a correction supported by the original field sheet, a confirmed unsampled date, or an unresolved missing interview outcome that limits a reported total.

Before reporting this example, I would check that:

• The calendar still covers June 1–16 and the total uses target = "period_total".
• Each selected visit has a count or a documented explanation for its absence.
• Every effort stratum has interviews eligible for its rate estimator.
• Valid zero-catch trips remain in the analysis and required missing values have a documented treatment.
• Linked records, party size, and units agree across the count and interview components.
• The report states the estimator, package version, standard error, and confidence interval.

The series introduction described reproducibility as being able to explain how survey decisions become reported results. For me, that includes being able to explain why we corrected one record, kept a zero-catch trip, or left an unsampled day in the calendar. The real creel data, sampling plan, and clerk’s notes supply the evidence for those decisions.

The next step is to carry those checks, decisions, and estimates into a reproducible Quarto report that a colleague or manager can follow.

Package references

• Table-level checks in tidycreel 7.0.0
• Validation summary implementation
• Design and completeness diagnostics

Catch, harvest, and release describe different outcomes

Here, catch includes every fish caught. Harvest counts the fish kept, and release counts the fish returned to the water. The example records both outcomes for one species, bluegill.

These are estimates of fishing outcomes. A release total does not estimate post-release mortality, and a catch total does not count unique individual fish if a fish can be caught more than once.

The roving-interview post explained why the interview protocol determines the rate estimator. This example uses completed access-point trips and ratio-of-means rates: fish reported by the interview sample divided by its angler-hours, with the survey design supplying the weights.

An access-point example does not change how roving observations should be analyzed. Preserve the interview type and trip information collected in the field when building your own design.

Start with the same effort design

We keep the June 1–16 calendar from the effort post. It contains ten weekdays and six weekend days, with counts on five weekdays and three weekend days. Each count represents an eight-hour fishing period.

library(tidycreel)

dates <- seq(as.Date("2024-06-01"), as.Date("2024-06-16"), by = "day")
calendar <- data.frame(
  date = dates,
  day_type = ifelse(
    as.integer(format(dates, "%u")) >= 6L,
    "weekend", "weekday"
  )
)

sample_dates <- as.Date(c(
  "2024-06-03", "2024-06-05", "2024-06-07",
  "2024-06-11", "2024-06-13",
  "2024-06-01", "2024-06-08", "2024-06-15"
))
counts <- data.frame(
  date = sample_dates,
  day_type = c(rep("weekday", 5), rep("weekend", 3)),
  n_anglers = c(10, 12, 11, 14, 13, 20, 24, 22),
  period_hours = 8
)

Keeping the full calendar preserves the reporting population established in the sampling-calendar post. The checked effort estimates remain 960 weekday angler-hours and 1,056 weekend angler-hours, totaling 2,016 angler-hours.

Attach interviews and the two catch outcomes

The interview sample contains ten weekday trips and thirty weekend trips. Every trip is complete and represents one angler fishing for two hours. The different numbers of interviews deliberately make the interview mix different from the effort mix.

interviews <- data.frame(
  interview_id = sprintf("trip-%02d", 1:40),
  date = rep(sample_dates, times = c(rep(2, 5), rep(10, 3))),
  day_type = c(rep("weekday", 10), rep("weekend", 30)),
  hours_fished = 2,
  n_anglers = 1L,
  trip_status = "complete",
  catch_total = c(rep(0:4, 2), rep(c(0, 2, 4, 6, 8), 6))
)
interviews$catch_kept <- floor(interviews$catch_total / 2)

catch <- rbind(
  data.frame(
    interview_id = interviews$interview_id,
    species = "bluegill",
    count = interviews$catch_kept,
    catch_type = "harvested"
  ),
  data.frame(
    interview_id = interviews$interview_id,
    species = "bluegill",
    count = interviews$catch_total - interviews$catch_kept,
    catch_type = "released"
  )
)

design <- creel_design(calendar, date = date, strata = day_type) |>
  add_counts(
    counts,
    count_col = n_anglers,
    period_length_col = period_hours
  ) |>
  add_interviews(
    interviews,
    catch = catch_total,
    effort = hours_fished,
    harvest = catch_kept,
    trip_status = trip_status,
    trip_duration = hours_fished,
    n_anglers = n_anglers,
    interview_type = "access"
  ) |>
  add_catch(
    catch,
    catch_uid = interview_id,
    interview_uid = interview_id,
    species = species,
    count = count,
    catch_type = catch_type
  )

The linked-tables post introduced this connection: catch records link to interviews through interview_id. Here, add_interviews() supplies catch and harvest totals for each trip; the linked catch table supplies the release records used by the release estimator. harvested and released are the catch-type labels accepted here.

Eight interviews report zero catch. We keep them because their fishing time belongs in the rate denominator. Removing unsuccessful trips would change the question to how well anglers did conditional on catching something.

This teaching example assumes equal interview selection probabilities within each stratum. The package reports that assumption because no interview weights were supplied. It also flags zero catch and the small weekday sample; these observations are intentional, and the example is not a sample-size recommendation.

Multiply within strata, then add the totals

For a stratified survey, the total is a sum of matched products:

where identifies a survey stratum, is its effort estimate, and is its catch rate. Replacing the catch rate with the harvest or release rate gives the corresponding total.

Inspect the rates before estimating those totals:

estimate_catch_rate(design, by = day_type)
estimate_harvest_rate(design, by = day_type)
estimate_release_rate(design, by = day_type)

The checked point estimates are:

All three rates are in fish per angler-hour. Weekday catch is therefore fish; weekend catch is fish. Adding them gives 3,072 fish caught across the full period.

A pooled interview rate gives a different answer. The forty trips report 140 fish over 80 angler-hours, or 1.75 fish per angler-hour. Multiplying that rate by 2,016 angler-hours would give 3,528 fish.

The pooled rate gives weekend trips three quarters of the interview effort. Weekends account for only about half of the estimated period effort. Multiplying within strata preserves that distinction. In this standard stratified workflow, tidycreel’s total functions perform the stratum products internally even when the requested output is a single period-total row.

Request the full-period totals explicitly

Use target = "period_total" to represent all sixteen calendar days:

total_catch <- estimate_total_catch(design, target = "period_total")
total_harvest <- estimate_total_harvest(design, target = "period_total")
total_release <- estimate_total_release(design, target = "period_total")

total_catch
total_harvest
total_release

These calls use the default complete-trip ratio-of-means path for this access-point design. The results below are rounded to whole fish.

The default target in these functions is "sampled_days". Omitting the target would give 1,536 fish caught for the eight sampled days in this example, rather than the total for all sixteen days.

For separate weekday and weekend catch totals, use estimate_total_catch(design, by = day_type, target = "stratum_total"). That returns 960 and 2,112 fish, respectively.

Both components contribute uncertainty

A precise effort estimate cannot compensate for an uncertain rate. Likewise, interviewing more anglers cannot repair sparse count coverage. The total’s standard error must reflect both sides of the calculation.

For this standard product-estimation path, tidycreel 7.0.0 defaults to product_variance = "goodman". Within each stratum, it combines effort and rate variances using:

Think of the Goodman correction as removing a small double charge in the uncertainty calculation. Both the effort estimate from counts and the catch rate from interviews have uncertainty. When we use each estimate to scale the other’s uncertainty, the basic calculation effectively counts a little uncertainty twice, making the result too large on average. Goodman’s correction subtracts that extra amount.

Here, the estimated catch stays 3,072 fish. The standard error drops slightly, from 368.6 fish without the correction to 368.3 fish with it, making the confidence interval slightly narrower. The correction adjusts the error bars; it does not improve the underlying data.

This calculation assumes independently estimated effort and rates. The option "first_order" omits the final term. These choices, including a first-order fallback if the Goodman estimate is nonpositive, are documented in the 7.0.0 total-catch source. The method cannot establish independence from the field data alone; that assumption needs to fit the sampling protocol.

The figure follows the same weekday and weekend catch estimates through the uncertainty calculation. Under the independence assumptions used here, the stratum variances add; taking the square root gives the total standard error.

In this example, the harvest and release point estimates add to the catch estimate because the records partition each trip’s catch into those two outcomes. Their confidence limits should not be added. Harvest and release share interviews and effort, so their uncertainties are related.

Check the match before reporting fish

Before using a total in a report, I would check:

• Does the calendar cover the intended reporting period, and is the target explicit?
• Do the interviews represent the anglers and areas included in the counts?
• Do the rate and effort use compatible units, including party size?
• Does every effort stratum have interviews that support its rate estimate?
• Are zero-catch trips retained and missing outcomes resolved?
• Does the report name the estimator, standard error, interval, and package version?

The one-angler trips here make the units easy to follow. For party interviews, fish reported for the party need the party’s angler-hours in the denominator. Similarly, a rate for boat anglers cannot simply be multiplied by effort that also includes bank anglers unless the sampling design supports that match.

An effort stratum with no usable interviews has an unknown rate. It is not a zero-catch stratum. Inspect coverage before accepting an aggregate; a numeric total alone does not establish that every part of the survey frame contributed.

The series introduction began with a design-first workflow. Here that design determines which observations can be multiplied together and what the resulting fish total represents. The next post reads the diagnostics before an estimate reaches a report, especially when records are missing or sampling coverage is uneven.

References

• Goodman, L. A. 1960. On the Exact Variance of Products. Journal of the American Statistical Association 55:708–713.
• Pollock, K. H., C. M. Jones, and T. L. Brown. 1994. Angler survey methods and their applications in fisheries management. American Fisheries Society Special Publication 25, Bethesda, Maryland.

A count and an effort estimate are different quantities

An instantaneous count answers a narrow question: how many anglers were present when the count was made? If 20 anglers are present at 10:15 a.m., the observation is 20 anglers. It is not 20 angler-hours and it is not the number of people who fished that day.

The count becomes an estimate of effort only after it is connected to time. If the count was randomized within an eight-hour fishing period, the simple period estimate is:

where is the instantaneous angler count and is the length of the period in hours. A count of 20 anglers across an eight-hour period represents 160 angler-hours for that sampled day.

That multiplication depends on the field design. The eight hours must describe the period over which the count was randomized and for which the snapshot is intended to be representative. It should not be added later merely because the survey crew worked an eight-hour shift.

Multiple counts within a period add another step. They estimate the same stock of anglers at different moments, so they are averaged before multiplying by the period length. They are not summed as if each count found a new set of anglers. The longer treatment in Modern Creel Survey Analysis in R works through that within-day case.

The same logic carries those snapshots through to a monthly estimate:

Keep the full calendar and the sampled counts

This example covers June 1 through June 16. The full calendar defines ten weekdays and six weekend days. Counts were collected on five weekdays and three weekend days.

library(tidycreel)

dates <- seq(
  as.Date("2024-06-01"),
  as.Date("2024-06-16"),
  by = "day"
)

calendar <- data.frame(
  date = dates,
  day_type = ifelse(
    as.integer(format(dates, "%u")) >= 6L,
    "weekend",
    "weekday"
  )
)

sample_dates <- as.Date(c(
  "2024-06-03", "2024-06-05", "2024-06-07",
  "2024-06-11", "2024-06-13",
  "2024-06-01", "2024-06-08", "2024-06-15"
))

counts <- data.frame(
  date = sample_dates,
  day_type = c(rep("weekday", 5), rep("weekend", 3)),
  n_anglers = c(10, 12, 11, 14, 13, 20, 24, 22),
  period_hours = rep(8, 8)
)

The unsampled dates remain in calendar, even though they have no row in counts. That is the distinction introduced in the sampling-calendar post: the observations come from sampled days, while the calendar defines the population of days they can represent.

Weekday and weekend also remain separate. Weekend counts are higher in this example, but both strata have a 50% sampling fraction: five of ten weekdays and three of six weekend days. Each stratum’s mean daily effort is expanded to its own number of calendar days. The same approach also handles surveys with different sampling fractions across strata.

Let add_counts() establish the effort unit

The design connects the calendar to the count observations. The important argument here is period_length_col.

design <- creel_design(
  calendar,
  date = date,
  strata = day_type
) |>
  add_counts(
    counts,
    count_col = n_anglers,
    period_length_col = period_hours
  )

For each sampled date, add_counts() multiplies n_anglers by period_hours. It also records the resulting effort unit as angler-hours. That unit information matters later when an effort estimate is combined with a rate reported as fish per angler-hour.

If period_length_col is omitted, tidycreel 7.0.0 warns that an instantaneous count has been expanded without a period length. The resulting sum is not an angler-hour estimate. The warning is worth stopping for because no downstream formatting can repair a missing time basis.

This example uses one count per sampled day, which keeps the arithmetic visible. A survey with repeated counts should also supply count_time_col so tidycreel can average the within-period counts and retain their contribution to uncertainty.

Choose the population the estimate should represent

estimate_effort() makes the reporting target explicit. Three calls show the progression from observed sample days to the full calendar period.

sampled_effort <- estimate_effort(
  design,
  target = "sampled_days"
)

effort_by_stratum <- estimate_effort(
  design,
  by = day_type,
  target = "stratum_total"
)

period_effort <- estimate_effort(
  design,
  target = "period_total"
)

The checked 7.0.0 example produces:

The sampled-day total is the sum of the eight daily effort estimates. The stratum totals first estimate mean daily effort within weekday and weekend, then multiply those means by the number of calendar days in each stratum. The period total adds the two stratum totals.

In this small example, exactly half of the days were sampled, so the period total happens to be twice the sampled-day total. That shortcut will not usually work. Sampling fractions can differ among strata, period lengths can vary, and the full estimate must preserve those differences.

Read the uncertainty with the point estimate

Printing period_effort returns more than 2,016 angler-hours:

Method: Total
Variance: Taylor linearization
Confidence level: 95%
Effort target: period_total
Unit: angler-hours

estimate    se se_between se_within ci_lower ci_upper     n
    2016    56         56         0     1879     2153     8

The estimate is 2,016 angler-hours for the 16-day period. Its standard error is 56 angler-hours, and the 95% confidence interval runs from 1,879 to 2,153 angler-hours.

Here, se_between equals the total standard error because there is only one count on each sampled day. There is no replication within a day from which to estimate moment-to-moment variation, so se_within is zero. Zero does not mean angler abundance was perfectly stable within each day. It means this design did not measure that component.

With repeated count rounds, se_within can quantify within-day variation. Comparing it with se_between helps identify whether additional field effort would be better spent sampling more days or making more counts on days already selected.

Check what the estimate does and does not cover

Before reporting the result, I would ask:

• Does the calendar contain every day in the intended reporting period?
• Were the counts randomized within the periods named by period_length_col?
• Do the strata match the field sampling design rather than a grouping created after data collection?
• Are dates without counts known unsampled days, or are some missed visits or missing records?
• Does the output name the expected target and unit?
• Are the confidence interval and variance components reported with the point estimate?

The estimate cannot extend beyond its frame. If the count route omitted part of the lake, the result represents the covered area unless an additional, defensible spatial expansion is part of the design. Likewise, a June calendar cannot support a summer-season total that includes July and August.

This is why check_completeness(design) is a diagnostic rather than an automatic decision maker. It can identify calendar dates without counts. The survey record must tell us whether those dates were intentionally unsampled, missed in the field, or lost during data handling.

An instantaneous count is only a snapshot. The period length gives it a time unit, the calendar gives it a population of days, and stratification controls how sampled days represent that population. estimate_effort() keeps those pieces together and returns the uncertainty needed to interpret the total.

The next post combines effort with interview-based rates to estimate total catch, harvest, and release. That multiplication is meaningful only when the rate and effort describe compatible anglers, places, periods, and units.

Reference

• Pollock, K. H., C. M. Jones, and T. L. Brown. 1994. Angler survey methods and their applications in fisheries management. American Fisheries Society Special Publication 25, Bethesda, Maryland.

Start with what one row means

Before joining anything, I want to be able to finish this sentence for every table: one row represents… That answer tells us which values can be repeated and which must remain unique.

For the instantaneous-count workflow used here, the main tables have these roles:

The sampling-calendar post explained why dates and strata matter. Here, the additional connection is the interview identifier. It allows several species records and several fish measurements to belong to the same interview without turning that interview into several independent trips.

Counts do not need to belong to individual interviews. A clerk might count anglers across a section and interview only some of them. Connecting every count to every interview on that date would create combinations that the field crew never observed.

One large spreadsheet can quietly repeat effort

Suppose an interview records four hours of fishing and catch of two species. A species-level table needs at least two rows to describe that catch. If we join those rows to the interview, the four hours appear twice. Summing the joined effort column now gives eight hours, although only four were reported.

Adding individual fish measurements can multiply rows again. Three length records for one species are three measurements, not three more interviews.

A join can be useful for a particular question. The problem is forgetting that it changes what a row represents. Keeping the original tables separate gives us a way to check a derived table against the observations that produced it.

This is the practical role of the design object. It holds the related tables and the information needed to interpret them, without requiring us to flatten everything into one spreadsheet.

Attach counts and interviews first

The first part of the example should look familiar. Define the calendar, attach counts, and then attach interviews with their catch and effort fields. The interview type remains explicit for the same reason discussed in the last post: it documents how the observations were collected.

library(tidycreel)

# This walkthrough was checked against version 7.0.0.
packageVersion("tidycreel")

data(example_calendar)
data(example_counts)
data(example_interviews)
data(example_catch)
data(example_lengths)
data(example_ages)

design <- creel_design(
  example_calendar,
  date = date,
  strata = day_type
) |>
  add_counts(example_counts) |>
  add_interviews(
    example_interviews,
    catch = catch_total,
    effort = hours_fished,
    harvest = catch_kept,
    trip_status = trip_status,
    trip_duration = trip_duration,
    n_anglers = n_anglers,
    interview_type = "access"
  )

This example declares access-point interviews. A roving survey should retain its own interview type and appropriate trip information; organizing the tables does not change the sampling protocol. The example also produces an equal-probability warning because it supplies no explicit sampling weights. It demonstrates table attachment; a survey with unequal selection probabilities needs those probabilities represented in its design before estimation.

The interview table still contains one row per interview, including interviews with no catch. Those zero-catch observations matter when estimating rates. A catch table alone cannot tell us how much fishing occurred without a fish being caught.

Link species-level catch to its interview

add_catch() attaches the species detail through the interview identifier. The two identifier arguments describe opposite sides of that link: catch_uid is the interview ID column in the catch table, and interview_uid is its counterpart in the interview table. Despite its name, catch_uid is not a unique identifier for each fish or catch row.

design <- design |>
  add_catch(
    example_catch,
    catch_uid = interview_id,
    interview_uid = interview_id,
    species = species,
    count = count,
    catch_type = catch_type
  )

The catch table uses "caught", "harvested", and "released" to describe catch type. Caught is the total; harvested and released are components. Adding all three together would count fish twice. If a caught row is absent, the package derives that total from harvested plus released. If it is present, it must be at least their sum. These rules are documented in add_catch().

An interview can legitimately have no catch rows when nothing was caught. That is different from losing its catch records during an export. The software cannot reconstruct that distinction from an absent row, so the data-preparation workflow must establish what absence means. Version 7.0.0 rejects NA catch counts rather than silently treating an unknown count as zero. Dropping a row with an unknown count is therefore a substantive decision, not a harmless fix.

Version 7.0.0 also makes the linked identifiers character values. A numeric ID from one source and a character ID from another can otherwise fail to join. Identifiers are labels: keep leading zeros when they are meaningful, and do not expect character conversion to recover zeros already lost during import.

Keep biological observations connected too

Length and age records attach to interviews in the same way. They do not need a matching row number in the catch table. Several measured or aged fish can belong to one interview, and many interviews may have no biological records.

design <- design |>
  add_lengths(
    example_lengths,
    length_uid = interview_id,
    interview_uid = interview_id,
    species = species,
    length = length,
    length_type = length_type,
    count = count,
    release_format = "binned"
  ) |>
  add_ages(
    example_ages,
    age_uid = interview_id,
    interview_uid = interview_id,
    species = species,
    age = age,
    age_type = age_type
  )

print(design)

The shipped length example mixes individual harvested-fish measurements with binned release records. That is why this call specifies release_format = "binned" and supplies a count column. The count is the number of released fish in a bin, not an interview count. Length and age fate labels are "harvest" and "release", whereas the catch table uses "harvested" and "released". The add_lengths() and add_ages() references describe those formats.

An interview ID identifies the interview, not an individual fish. If a project needs to match a fish’s length to its age, retain a separate fish or specimen identifier in the source records. Interview and species alone cannot establish which measurement belongs to which aged fish.

These links preserve biological observations; they do not automatically make the measured fish representative of the entire catch. That still depends on which fish were available, which were selected for measurement, and the estimation method used.

Check the links before estimating anything

The attachment functions check that catch and biological records refer to interviews in the design. A record with an unknown interview ID should send us back to the source tables: was the ID mistyped, was an interview omitted, or were records drawn from different survey exports?

I would also check that the interview identifier uniquely identifies an interview across the data being combined. If numbering restarts each year or at each water body, an ID such as "104" is not enough on its own. Construct a consistent identifier from the necessary source fields and use it in every related table before attachment.

A separate check asks whether the design has the expected field coverage:

check_completeness(design)

For this workflow, that report identifies calendar days without count data and strata with few interviews. Its default low-interview threshold is 10; that is a diagnostic threshold, not proof that a sample is adequate for every survey. On the shipped example, the report finds no missing sampling days but flags one stratum below that threshold. That is a result to inspect, not an error in attaching the tables. The report also does not establish that every fish was measured or every species record was entered. Those checks require the field protocol and source records.

Before moving on, I would ask:

• Can I explain what a row represents in every table?
• Does each catch, length, and age record point to the intended interview?
• Are zero-catch interviews retained, and are missing records investigated?
• Have any joins repeated effort or turned measurements into extra interviews?
• Can another analyst distinguish observed sample summaries from expanded estimates?

The calendar defines the survey’s time structure. Interviews retain the trip information and sampling protocol. Linked catch and biological tables add detail without changing how many interviews occurred. Keeping those distinctions visible is what lets the next step—estimating effort, catch, and harvest—start from the observations the field crew actually collected.

The same questionnaire can produce different observations

Imagine that a clerk interviews two anglers at a boat ramp. They have put their boat on the trailer and are heading home. Their reported hours fished and catch describe completed trips. An access-point interview is therefore a natural setting for estimating a rate from total catch divided by total effort across those trips.

Now imagine a clerk moving through the fishery by boat. The clerk speaks with an angler who launched at dawn and plans to fish until noon. At 9:30, the angler’s reported catch and effort describe only the trip up to the time of the interview. The angler may accumulate more effort, catch more fish, or harvest additional fish before going home.

There is another important difference. An angler fishing for six hours is available to a roving clerk for longer than an angler fishing for one hour. Longer trips therefore have more opportunity to be intercepted.

That is not a flaw in roving surveys. It is part of their sampling process. The estimator needs to reflect how anglers entered the interview sample rather than treating a roving interview as though it were simply an unfinished access-point interview.

What the survey literature adds

This distinction comes from the creel-survey literature, not from a software convention. Pollock, Jones, and Brown (1994) set out access-point and roving interviews as different ways of contacting anglers within a broader survey design. The practical point is the one that matters here: an access interview normally observes a completed trip, whereas a roving interview observes the part of a trip visible at the time of contact.

Pollock et al. (1997) make the sampling consequence explicit. In their formulation, anglers are intercepted with equal probability at access points, but an angler’s chance of being encountered in a roving survey is proportional to the completed-trip length. They therefore recommend ratio-of-means for access interviews and a mean of individual catch-to-effort ratios for roving interviews.

Hoenig et al. (1997) develop the roving catch-rate and total-catch estimators in more detail. Under their modelling assumptions, very short observed trips can make an untruncated mean-of-ratios estimate unstable. Their simulation results support dropping interviews observed within the first 30 minutes of a trip before calculating that estimator.

These sources do not prescribe one estimator for every creel survey. They show why the estimator must follow the interview and sampling design. That is the connection tidycreel is trying to preserve when the analysis records interview_type, trip status, and observed duration.

Start by recording how the interview was collected

In tidycreel, add_interviews() records the interview type along with catch, effort, trip status, and, when available, trip-duration information. This is one place where a small declaration prevents a much larger ambiguity later in the workflow.

library(tidycreel)

data(example_calendar)
data(example_interviews)

roving_design <- creel_design(
  example_calendar,
  date = date,
  strata = day_type
) |>
  add_interviews(
    example_interviews,
    catch = catch_total,
    effort = hours_fished,
    trip_status = trip_status,
    trip_duration = trip_duration,
    interview_type = "roving"
  )

The calendar establishes the days and strata that organize the analysis. The interview type answers a different question: how did an angler become available for an interview?

Both pieces of information belong in the design object before we estimate a catch or harvest rate.

An access-point design is declared in the same place with interview_type = "access". That is currently the default, but I prefer to state it explicitly in a project script. Doing so leaves the field protocol visible to the next person who reads the analysis.

What the roving declaration changes

For an access-point design, estimate_catch_rate() defaults to completed-trip interviews and a ratio-of-means estimator. The ratio-of-means pools the interviews first: total catch across the sampled trips is divided by total effort across those trips.

That aligns the rate estimator with the completed-trip observations collected at the access point.

For a roving design, tidycreel recognizes a different sampling process. When neither use_trips nor estimator is specified, it uses all eligible complete and incomplete interviews with a mean-of-ratios estimator. Rather than pooling catch and effort first, the mean-of-ratios calculates a catch-per-unit-effort rate for each eligible interview and then averages those individual rates.

The same design-aware choice carries through the catch, harvest, and release-rate workflows and the totals constructed from those rates.

# Roving design: all eligible interviews + mean-of-ratios
roving_cpue <- estimate_catch_rate(roving_design)

# Override the defaults when completed trips are specifically wanted
complete_trip_cpue <- estimate_catch_rate(
  roving_design,
  use_trips = "complete",
  estimator = "ratio-of-means"
)

These calls do not simply calculate the same quantity in two different ways. They use different subsets of the interview sample and different estimators.

The second can be useful as a diagnostic comparison, or when the scientific question specifically calls for completed trips. It should not quietly replace the roving estimator simply because completed trips are more familiar.

Why this matters for creel-survey estimates

Interview type affects more than the label on a CPUE result. In a conventional creel survey, estimated total catch or harvest is often calculated as estimated total effort multiplied by an estimated rate. The rate must therefore be on the right footing before it is expanded to a day, season, fishery, or management unit (Pollock et al. 1997).

That has several practical implications:

• A mismatch between the interview protocol and estimator can carry into total catch, harvest, and release estimates, rather than remaining a technical difference in a table of CPUE results.
• Rates from years, locations, or survey programs are only directly comparable when the way anglers entered the sample and the estimator used to analyze them are comparable too.
• The field record needs to retain interview type, trip status, and observed duration. Without them, an analyst cannot show which interviews contributed to an estimate or reproduce the decision later.

Choosing the roving estimator addresses the unequal opportunity for longer trips to be encountered. It does not remove every challenge of a roving design. For example, when an effective bag limit changes angler behavior or catch rates over the course of a trip, an interview during the trip may no longer represent the completed trip in the same way. Pollock et al. (1997) show that this can produce biased roving estimates, so those fisheries warrant a design review rather than an automatic estimator choice.

Very short trips need special attention

The default roving path also applies a 30-minute minimum trip duration for mean-of-ratios estimation, following the short-trip treatment discussed by Hoenig et al. (1997).

The reason follows from how the estimator works. Each interview contributes its own catch-per-unit-effort rate. When very little effort has been observed, even a single early catch can produce an extremely large individual rate. An angler who catches a fish shortly after beginning a trip, for example, can have a very high observed catch-per-hour rate even though little of the trip has actually been observed.

Those extreme individual rates can make the estimate unstable.

By default, tidycreel therefore excludes interviews with observed trip durations shorter than 0.5 hours before calculating the mean-of-ratios estimate. The threshold is part of the estimator and should be reported as such. It is not a general data-cleaning rule saying that short fishing trips are invalid observations.

Complete and incomplete are not a data-quality ranking

It is tempting to read an unfinished trip as incomplete data. In the ordinary-language sense, the trip is incomplete. In a roving survey, however, that does not mean the interview is a mistake, a deficient record, or an access-point interview that happened too early.

The angler was encountered during the trip by design.

The useful question is therefore not whether the trip was complete. It is whether the observation contains the information required by the estimator appropriate to the survey design.

This distinction is also why trip_status and trip-duration information should be retained during data preparation. They document what the clerk actually observed, support the appropriate estimation path, and make it possible to review later exactly how the rate was calculated.

A short checklist before estimating rates

Before estimating CPUE, HPUE, or release rate, I would stop and ask:

• Did interviews occur after anglers completed their trips, or while anglers were still fishing?
• Does the interview table retain valid complete/incomplete trip status?
• For roving interviews, is the information needed to determine observed trip duration available?
• Does the estimator reported in the output match the interview design?
• If a minimum observed duration was applied, is that threshold documented?
• Can someone reading the script tell why this estimator was used?

These are field-method questions as much as R questions. A well-organized table cannot reconstruct a sampling process that was never recorded. It can, however, keep that process visible throughout the analysis.

The tidycreel reference site documents the function-level arguments for add_interviews() and the rate estimators. The earlier posts on the design object and sampling calendar provide the larger context.

The calendar tells us when the fishery could be sampled. The interview protocol tells us how anglers entered the sample. The estimator determines how those observations become an estimate.

Those are parts of the same survey design, not separate decisions to reconcile at the end.

References

• Hoenig, J. M., C. M. Jones, K. H. Pollock, D. S. Robson, and D. L. Wade.
  1997. Calculation of catch rate and total catch in roving surveys of anglers. Biometrics 53:306-317.
• Pollock, K. H., J. M. Hoenig, C. M. Jones, D. S. Robson, and C. J. Greene.
  1997. Catch rate estimation for roving and access point surveys. North American Journal of Fisheries Management 17:11-19.
• Pollock, K. H., C. M. Jones, and T. L. Brown. 1994. Angler survey methods and their applications in fisheries management. American Fisheries Society Special Publication 25, Bethesda, Maryland.

The next post turns to the linked tables that carry counts, interviews, catch, and biological data through the rest of a creel analysis.

What is a sampling calendar in a creel survey?

A sampling calendar records the dates in the survey period, the strata used to organize them, and the dates selected for fieldwork. That is more useful than thinking of the calendar as a list of work assignments. It distinguishes the period we want to estimate from the smaller set of days on which observations were collected.

Suppose a survey covers June through August. Every day in that season belongs to the period we want to estimate, but field staff cannot sample all of them. The calendar may separate weekdays from weekends because anglers use the fishery differently on those days. It may also identify holidays, special events, or periods of unusual access.

The sampled days provide the observations. The full calendar defines the population of days those observations are used to estimate. If that information is lost, a mean count or interview rate can still be calculated, but there is no longer enough information to expand the sampled days to the full season.

Why available days and sampled days are different

An available day belongs to the population of days the survey could have sampled. A sampled day is one the survey actually selected and worked. Those are related pieces of information, but they have different roles in the analysis.

For example, a survey might make every summer day available, classify each as a weekday or weekend, and then sample a larger proportion of weekends. That is not a problem. It may be a deliberate design choice when weekend fishing pressure is expected to be higher or more variable. The estimator needs to know both how many days were sampled and how many days are in each stratum so the sampled observations can be expanded correctly.

This is the practical reason to retain unsampled dates in the survey record, even when they have no count or interview row. They provide information about the population of days and the sampling design. A missing count record might mean “not selected,” “selected but no data were collected,” or “data have not been entered.” Those situations cannot be treated as equivalent.

Accounting for strata in the expansion

Strata are groups of days that the sampling design treats separately. Weekday and weekend are common examples, but a survey might also use month, season phase, holiday period, section, or combinations of these when the field protocol supports them.

The important question is not whether a column can be used as a grouping variable. It is whether those groups were part of the sampling design and have a clear role in defining the population. If a field season deliberately samples weekend days more often, that decision needs to be included in the calendar and in the later expansion, not only in a scheduler’s spreadsheet.

If fishing pressure differs among strata, the season-wide estimate needs to account for how many days each stratum contributes to the season. A weekend stratum with 26 available days and a weekday stratum with 66 available days represent different portions of the season, regardless of how many days were sampled from each. The calendar provides those population counts for the expansion.

Building a calendar with tidycreel

tidycreel can generate a reproducible stratified schedule with generate_schedule(). The example below defines the full season, samples weekday and weekend strata at different rates, and retains all dates with a sampled column identifying those selected for fieldwork.

library(tidycreel)

schedule <- generate_schedule(
  start_date = "2024-06-01",
  end_date = "2024-08-31",
  n_periods = 2,
  sampling_rate = c(weekday = 0.30, weekend = 0.60),
  include_all = TRUE,
  expand_periods = FALSE,
  seed = 42
)

# The full schedule has date, day_type, and sampled columns.
schedule

The example is deliberately simple. It does not specify what proportion of weekdays or weekends another survey should sample. That decision depends on the fishery, staffing, budget, survey objectives, and expected variability. The important part here is that the sampling rates and selection are explicit and reproducible rather than stored only in a spreadsheet or calendar export.

When it is time to analyze the observations, pass the full calendar to the design. Keep the selected dates separately as the planned visits:

planned_visits <- schedule[schedule$sampled, ]

design <- creel_design(
  schedule,
  date = date,
  strata = day_type
)

The design retains every date in the season, including dates without counts. Use planned_visits to check whether the selected fieldwork occurred; do not use it to replace the population calendar. The diagnostics post shows how to compare planned visits with observed records. This calendar example was checked against tidycreel 8.0.0.

The tidycreel reference site documents the scheduling and design arguments in detail. For a fuller explanation of the logic, the companion book’s chapter on sampling calendars and strata is the better place to start.

What to check before the field season starts

Before a schedule becomes a field assignment, I would ask a few questions:

• What dates belong to the period I want to estimate?
• Which differences among days are important enough to define strata?
• How many days are available in each stratum, and how many will be sampled?
• What will a missing record mean after the season: not selected, missed, incomplete, or absent from the data system?
• Can another analyst reconstruct the selection rule without asking the person who made the schedule?

These questions determine the population that can be estimated from the survey. If the intended result is a summer-season estimate, for example, the design needs to identify the days in that season and how the sampled days were selected from them.

Retaining the calendar for analysis

By the end of a field season, schedules often live in several places: a shared spreadsheet, email assignments, a database export, and a field notebook. The analysis should preserve a clean version of the original calendar rather than rebuilding it from the dates that happen to have observations.

That is the same principle behind the design object: the field design and its data belong together. It is also related to the recent tidycreel development update, where the focus was keeping downstream estimators and reporting consistent with the survey design.

The next step is to attach counts and interviews to the design and use that information to estimate angler effort across the defined survey period. Before that, the roving-interviews post shows why the way an interview enters the design determines which estimator is appropriate.

Matching the estimator to the survey design

One of the bigger pieces of work has involved roving interviews. An access interview happens when an angler has completed a trip. A roving interview happens while the person is still fishing. The catch and effort in a roving interview can therefore be partial, and that changes the estimator that makes sense.

It is worth being precise about what that means. A roving clerk does not only meet anglers in the middle of a trip. Moving through the fishery, the clerk intercepts whoever is present, and some of those people happen to be finishing their trips. What follows from a roving design is that those interviews are used together, complete and incomplete alike, rather than discarding the incomplete ones. The estimator follows from how the clerk sampled, not from the status of any one interview. That is also why the same change was needed for harvest and release. Harvested and released fish are recorded in the same interception as the catch, so they are subject to the same sampling issue.

For a while, different parts of an analysis could make different choices from the same survey. A catch-rate estimate could use the roving-survey estimator, while a harvest rate, release rate, or total could use a different estimator. The resulting set of estimates therefore did not always use the same underlying method.

That work is now in place. When a survey calls for the roving approach, the catch rate, harvest rate, release rate, and the totals calculated from them all use it. When an analyst wants the older ratio-of-means approach, specifying it is enough to get it. Bus-route and ice designs, which cannot support a mean-of-ratios total, now reject that argument instead of accepting it and using another estimator.

That work is not completely finished. A sectioned design given the regression estimator is still accepted and returns ratio-of-means estimates instead. That issue is documented, and it is the next problem of this kind to fix.

This is not a new feature in the usual sense. It makes the estimator used in the analysis consistent with the field design.

Estimating by section and species

Lake-wide estimates matter, but managers often need to know what is happening in a particular section of a lake or river, or with a particular species.

We have been improving how tidycreel handles those estimates. Species totals can now be estimated within sections, and catch, harvest, and release rates use the same estimator logic when results are grouped by species. These functions are closely related, so a change to one needs to be applied consistently to the others.

There was also a problem with requesting section groupings. A sectioned result is already one row per section. Asking to group it by section a second time does not add another level of information; it repeats the existing grouping. Previously, that request ended in an error about a duplicated column name. The message was technically correct, but it did not identify what was wrong with the requested analysis.

The revised behavior is to stop and explain that the result is already split by section. Other groupings are unaffected. This makes it easier to identify the problem in the analysis rather than diagnose an unrelated-looking R error.

Recording which estimator was used

A creel estimate depends on the estimator used to calculate it. The same survey can produce different estimates depending on that choice, so the returned result needs to record which estimator was used.

On several paths, it did not. A total is effort multiplied by a rate, so the label on the returned total described the form of that calculation rather than the estimator used for the rate. Ratio-of-means, mean-of-ratios, and the truncated version therefore all returned the same estimator label. The estimator was used in the calculation, but that information was not retained in the returned result.

There was also an incorrect label on sectioned rates. A rate estimated section by section could use mean-of-ratios and then be labeled as ratio-of-means. On one test design, mean-of-ratios produces 0.87 fish per hour and ratio-of-means produces 0.59. Both are defensible estimates, but they are different methods and produce different results. Because a roving survey automatically uses mean-of-ratios, this could occur without the analyst explicitly requesting the estimator.

Results now record the estimator requested by the analyst for rates, sectioned rates, and totals. None of the estimates changed as part of that fix. The tests check both the reported estimator and the calculation. Two settings that resolve to the same calculation must return identical estimates while retaining their requested estimator names, while sectioned estimates calculated with different methods must still differ. Checking only the labels would not detect a case where the estimator argument was reported correctly but ignored in the calculation.

The original issue describing this problem also turned out to be incorrect. It said that a total reported the mean-of-ratios name. The total actually reports the product-form name. The label quoted in the issue occurs on an intermediate object that is discarded before the result is returned, so the proposed repair would not have fixed the reported output. Going back through the code before making the change identified that problem and two additional issues.

Recording which trips were used

A mean-of-ratios estimate now reports which trips were included: all trips, complete trips, or incomplete trips. The distinction matters because the roving-survey default uses all interviews, while an explicit diagnostic analysis may use only incomplete ones. Previously, the printed output described every mean-of-ratios result as though it used incomplete trips, including results calculated from all trips.

The same diagnostic information is now available for catch, harvest, and release rates. Truncation details are still reported because they are part of the estimator. The length-of-stay caution and the recommendation to validate incomplete trips appear only when incomplete trips are included in the calculation. The printed output now corresponds to the interviews actually used in the estimate.

Handling missing and unusable data

Some important problems occur when the data do not meet the requirements of an estimator. A trip duration may be missing. A truncation threshold may remove every usable interview. A warning may report a percentage that is not the one an analyst needs to evaluate the problem.

We have been adding checks so these cases return an explanation related to the survey and the data rather than an error from somewhere deeper in R. A trip with no recorded duration should be identified as a data problem. A truncation threshold that leaves no usable trips should say that directly. The analyst may still need to decide how to handle the problem, but the package should identify what caused it.

Current focus

tidycreel is being developed around a straightforward idea: a fisheries estimate should remain connected to the survey design and data used to produce it.

That means keeping the calendar, counts, interviews, catch, and biological data together in an inspectable workflow. The estimator needs to match the interview design, and the same estimator decisions need to carry through rates, totals, species, sections, uncertainty, and reporting. The package should also stop when a requested analysis does not have a clear statistical meaning.

There is still more to add. Camera surveys, aerial counts, bus routes, ice fisheries, connected agency data, and reporting all have additional problems to work through. For now, the focus is getting the underlying estimation and validation pieces right. The introduction to tidycreel explains the wider purpose of the series. The sampling-calendar tutorial returns to how the calendar defines the population an estimate represents. The later roving-interviews post and linked-tables post continue the same design-first thread.

That work is less visible than adding new features, but it is necessary before building more on top of it.

You can follow the package work on GitHub, browse the reference site, or read more of the reasoning in Modern Creel Survey Analysis in R.

The design object is where analysis begins

It is tempting to think that the analysis begins when the first estimator is called. I think it begins earlier, when we state what was sampled, how it was stratified, and what each observation represents.

For a straightforward instantaneous-count survey, the smallest useful example looks like this:

library(tidycreel)

# The calendar says which days belong to each stratum.
design <- creel_design(
  example_calendar,
  date = date,
  strata = day_type
)

# The count table supplies the observations made on sampled days.
design <- add_counts(design, example_counts)

# `design` now carries both the sampling structure and the count data.
design

creel_design() does not estimate anything. It creates an object that records the survey’s calendar, date field, strata, and survey type. add_counts() then attaches the count observations and uses the design information to establish the sampling structure needed downstream. The result is still an ordinary R object, but it has an important job: it keeps the design logic from being recreated, and possibly recreated differently, every time we estimate effort, catch, or a rate.

This is particularly helpful for graduate students learning design-based inference. You do not need to start by writing the machinery that connects strata, sampling units, and weights. You do need to be able to explain those parts of your own survey. The package asks for that information in terms that look like a creel survey: calendar, date, strata, counts, interviews, catch, and lengths.

Why the schedule belongs in the analysis

In many projects the schedule is treated as paperwork that can be set aside once the field season is over. I prefer to treat it as data. It tells us the available days, the strata, and which opportunities to sample were actually selected.

That is why the calendar is the starting point for a design object. The count table tells us what was observed. The calendar tells us what those observations need to represent. If a weekday and a weekend are separate strata in the field, they should remain separate in the object used for estimation unless there is a defensible reason to combine them.

The same idea carries into interviews and catch. As the analysis grows, the design object can be extended with add_interviews(), add_catch(), and add_lengths(). Those additions do not turn a pile of tables into a black box. They make the links between the tables explicit and allow the later functions to check that the pieces make sense together.

The design object also makes error checking more useful

The design object supports two different kinds of error checking. They use the same survey context, but they have different jobs.

Automatic guardrails run under the hood when you create or extend a design object, and again when an estimator needs a particular piece of information. They are there to stop an analysis before an assumption is silently violated. For example, creel_design() requires the selected date to be a real Date with no missing values and strata to be usable categories. add_counts() can catch ambiguous repeated sampling units or information that would make a count or its variance hard to interpret. Other survey types bring their own checks: a bus-route design, for example, verifies its inclusion probabilities. These are not optional data-cleaning suggestions; they protect the weights, expansions, units, and variance calculations the estimator will use.

Diagnostic tools for the analyst are the checks you run deliberately to understand the data and decide what to do next. validation_report() is a table-level diagnostic that reports column types and flags missingness, implausible dates, negative numeric values, empty text values, and—when a species field is supplied—unmatched species names. It does not decide whether a flagged value should be deleted or changed; it gives the analyst a concise record to investigate.

check_completeness() is the design-aware companion diagnostic. After data are attached, it identifies calendar dates without count records and flags interview strata below a specified row-count threshold. A date without counts may have been intentionally unsampled. To identify missed fieldwork, compare the selected visits with the observed records separately.

Likewise, passing an interview-count threshold does not establish that the interviews are independent, eligible for the estimator, or sufficient for the precision a manager needs. Check every expected stratum, including those with no interviews. The diagnostics post works through these checks and explains why missing records, unsampled days, and observed zeros need different treatment.

Here is a useful diagnostic sequence before estimation:

# Inspect the incoming tables; investigate any flags.
validation_report(
  counts = counts,
  interviews = interviews,
  species_col = "species"
)

# Use the calendar in the completed design to assess coverage.
design <- creel_design(calendar = schedule, date = date, strata = day_type) |>
  add_counts(counts = counts) |>
  add_interviews(interviews = interviews)

check_completeness(design)

The distinction matters because neither kind of checking substitutes for a field biologist’s judgment. A flagged long trip may be a data-entry error, or it may be the most informative trip in the dataset. The guardrails prevent invalid analysis states; the diagnostic tools surface questions that require an informed decision before a result is reported.

Where tidycreel.connect fits

Most agencies do not export a dataset with the exact variable names used in an R package. The interview identifier might be InterviewID; the date might be SurveyDate; effort might be HoursFished. That is normal. The problem comes when those translations happen informally in several scripts or, worse, by hand.

tidycreel.connect is the layer I use before building the design object. It connects to CSV files, a SQL Server database, or a REST API; applies an explicit column map; and returns tables with the canonical names expected by tidycreel.

Here is the basic CSV pattern. In a real project, the schema would document the names used by that agency’s export.

library(tidycreel)
library(tidycreel.connect)

schema <- creel_schema(
  survey_type = "instantaneous",
  interview_uid_col = "InterviewID",
  date_col = "SurveyDate",
  effort_col = "HoursFished",
  trip_status_col = "TripStatus",
  bank_anglers_col = "BankAnglers",
  angler_boats_col = "AnglerBoats"
)

conn <- creel_connect(
  con = list(
    interviews = "data/interviews.csv",
    counts = "data/counts.csv"
  ),
  schema = schema
)

interviews <- fetch_interviews(conn)
counts <- fetch_counts(conn)

The connection does not decide how the survey was designed. It performs the translation so that the analysis does not depend on whatever a particular database or spreadsheet happened to call a field. The sampling schedule remains an explicit input, and the fetched tables become the observation inputs. From there, the workflow becomes much easier to read:

design <- creel_design(
  calendar = schedule,
  date = date,
  strata = day_type
)

design <- add_counts(
  design,
  counts = counts,
  count_col = bank_anglers,
  count_time_col = count_time
)

The important point is not that every project must use a database connection. Many projects will begin with a folder of CSV files. The point is that the translation from agency data to analysis data should be declared once, inspected, and reused. That makes a handoff to a colleague, a new field season, or a future version of yourself much less fragile.

A runnable walkthrough

If you would rather learn by running a complete example, I have also prepared a one-hour tidycreel walkthrough that you can download and open in RStudio. It moves from planning a survey and building a schedule through validation, effort, catch, biological data, plots, and export. The script is deliberately more expansive than this post: use it as a guided tour, and return here when you want the reasoning behind the design object.

A useful habit before estimating anything

Before running an estimator, I would ask four questions:

• What are my sampling units?
• What are my strata, and why do they belong in the design?
• Which table contains the observation, and which table describes what it represents?
• Can another analyst see how my agency fields became the variables in the analysis?

If those answers are clear, the design object becomes more than a programming convenience. It is a compact, inspectable record of the survey logic. If they are not clear, changing estimators rarely fixes the underlying problem.

The tidycreel reference site has the function-level details. The chapter Building a Creel Design Object in Modern Creel Survey Analysis in R walks through a fuller example, including interviews and species-level catch. The companion chapter on tidycreel.connect shows the connection workflow in more detail.

The next post looks more closely at the sampling calendar and why it needs to survive all the way to the final estimate. The later linked-tables tutorial returns to the same design object once counts, interviews, catch, and biological observations are attached.

Why creel analysis gets complicated

The arithmetic behind an estimate can be simple. The surrounding survey is not. A count at an access point is not automatically a measure of effort across a lake. An interview from an angler who is still fishing does not mean the same thing as an interview at the end of a trip. A catch table may have a different unit of observation than an interview table. Weekday and weekend samples may need different treatment because the fishery behaves differently and because the sampling design says they do.

Those are not annoying details to clean up after the fact. They determine what an estimate means and how much confidence we should place in it. A good workflow keeps the sampling design attached to the data instead of reducing everything to a spreadsheet of numbers before analysis starts.

That is also why I think reproducibility matters here. It is not only about being able to rerun a script. A reproducible creel analysis should let a colleague see how the schedule, raw data, cleaning decisions, and estimation choices became a reported result. That is useful in a graduate methods course, but it is equally useful when a manager asks what a change in estimated harvest means for a fishery.

Why build on the tidyverse and survey packages

I did not want to rebuild the parts of R that already work well. tidycreel uses tidyverse conventions because they make data work readable. Tables stay as data frames or tibbles. Common tasks use verbs that many R users already know, such as filter(), mutate(), group_by(), summarise(), and left_join(). The package also uses tidy-select style column arguments, so the code can stay close to the names used in a survey.

For example, the start of a simple workflow reads like this:

library(tidycreel)

design <- creel_design(
  calendar = survey_calendar,
  date = date,
  strata = day_type
) |>
  add_counts(
    counts = angler_counts,
    count_col = angler_count,
    count_time_col = count_time
  )

The tidyverse style helps us build and inspect the data. It is not the statistical engine. For that, tidycreel builds on the survey package. The survey package has a long record of implementing design-based analysis: stratification, sampling units, probabilities, totals, ratios, and variance estimation. Those are the pieces we need when a count or interview has to represent more than itself.

That combination is deliberate. The tidyverse makes the workflow legible. The survey package supplies the design-based machinery. tidycreel adds creel survey vocabulary and guardrails around both, so an analysis can say creel_design(), add_interviews(), or estimate_effort() instead of forcing every user to reconstruct the same survey objects and variance calculations.

The book and the package have different jobs

The companion book, Modern Creel Survey Analysis in R, takes the slower route through these topics. It is for readers who want to understand the design-based logic, data structures, diagnostics, and interpretation behind a workflow. The book is broader than package documentation because an analysis is broader than a list of functions.

The package provides the working tools. The book explains the reasoning and gives the larger arc. This series sits between them. Posts will be shorter and more conversational than book chapters, while still providing code that readers can run, adapt, and question.

Who I am writing for

I have graduate students in mind, especially those who have field data and a question but have not yet had to translate a sampling design into an analysis. I am also writing for fisheries scientists and managers who need estimates that are transparent enough to explain, review, and use. Some posts will assume more R experience than others; I will try to be clear about that and to keep examples small enough that readers can see what changes from one step to the next.

If you work with creel data in a different setting, I hope the series is still useful. The particular species, water body, agency database, and reporting requirements will vary. The need to connect field observations to a defined population and sampling design does not.

What is coming in this series

Here are the first topics I plan to cover:

• Building a creel design object and keeping survey structure attached to the data
• Sampling calendars, strata, and the difference between an available day and a sampled day
• Access-point and roving surveys, including what changes when interviews occur during trips
• Data as linked tables: schedules, counts, interviews, catch, and biological data
• Using tidycreel.connect to turn agency CSV files, databases, or APIs into consistent analysis inputs
• Validating data before an estimator turns a small problem into a large one
• Estimating angler effort from count data and describing the uncertainty around it
• Catch, harvest, release, and rate estimates, including the distinction between complete and incomplete trips
• Building reproducible Quarto reports that are useful to managers as well as analysts
• Reading results carefully: domains, precision, bias, and what a creel estimate does not say
• And more, as the package, book, and questions from readers develop

The next post starts with the design object. It is the point where a survey plan and its observation tables become an analysis that can support the later estimates.

You can find the source code for tidycreel on GitHub, the package reference site, and the full book.