What we’re working on in tidycreel right now
The last post on the design object argued that a creel survey’s calendar, strata, and observation tables should stay together through analysis. This is a short update on why that matters in practice. Before returning to the planned post on sampling calendars, I want to show some of the downstream work needed to keep an estimate aligned with that design.
tidycreel can now take a survey from a calendar and raw field tables through counts, interviews, catch, and lengths to rates, totals, section and species results, and uncertainty estimates. The work right now is less about adding new capabilities and more about making sure those results are calculated consistently and can be inspected.
In brief
- Roving-survey rates and totals now follow the same estimator logic.
- Results record the estimator and trip set that produced them.
- Clearer checks stop invalid requests and problematic input earlier.
Over the past few days, I have been working through how existing estimates are calculated: which interviews they use, which estimator produced them, and when the package should stop rather than return a plausible but mismatched number. Often the visible change is a number that does not move, a label that finally matches the calculation, or an error that occurs before the result is reported.
That sounds obvious. It is also where creel analysis gets difficult.
A survey can have a reasonable sampling schedule, careful field staff, and a well-organized set of tables, then still have problems when the analysis quietly treats two kinds of interviews as though they were the same. The same can happen when a total and the rate used to calculate it are based on different trips, or when a result is split by species or section in a way that no longer matches what was actually sampled.
Those are the kinds of problems we have been working through.
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 next tutorial returns to the sampling calendar and how it defines the population an estimate represents.
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.