Automatic Trap Data and Corrected Catch Rate

Predator Control strategy
#1

BHMET runs a fleet of around 1,500 manual traps, 400 A24 automatic traps, 100 AT220 automatic traps and 100 AT520 automatic traps. Corrected Catch Rates (i.e. catches per 100 trap nights) are an important metric for us… but we’re struggling to integrate automatic trap statistics.

Historically, I haven’t been too troubled because just using manual trap results, I have a proxy for automatic trap results - in other words, the rapid decline in predator kills we see in our manual traps is largely because of the way higher kill rates in our automatic traps.

But we’re now at a stage where I need an integrated statistic… that includes all trap types.

Two major problems: how to integrate automatic trap results into Trap.NZ and then how Trap.NZ handles automatic traps in calculating ‘trap nights’.

Integrating automatic trap data into trap.nz is an absolute nightmare in any circumstances. But with a fleet of 400 A24s (only 100 of which have Smart Caps), 100 AT220s, and 100 AT520s, it’s an insurmountable barrier. If any other projects have experience of this, I’d love to hear from them! I’m contemplating manually adding results by ‘smearing’ six-monthly reports across evenly spaced dates - in other words, if our six month AT220 report says 12 ‘small’ kills and 3 ‘large’ kills, I assign 1 mouse per month, 1 rat per month and 1 possum every other month (since that’s the ratio found from carcass checks). But that’s a LOT of work. Perhaps I’m better off not trying to do the statistics in Trap.NZ: perhaps Excel is a better bet - so export the manual stats from Trap.NZ and then integrate the automatic trap stats in Excel? Any ideas (that don’t involve code!)?

For manual traps, the trap night figure is calculated based on assuming that a kill occured halfway between two visits… so if 30 days elapsed between two service visits and a kill was recorded on the second visit then the assumption is that the trap killed on day 15 and was unavailable for the remaining 15 days of the cycle. But that’s clearly not the case with automatic traps… but does Trap.NZ account for that in the ‘trap night’ calculation for automatic traps?

I’d really appreciate some ideas here…

Cheers

David

3 Likes
#2

You are doing a great job highlighting a basic issue with data collection.
Maybe Trapnz needs to discuss the issue with statisticians and programmers.
Rather than relying on trap data, I use camera trapping data to track predator numbers. Cameras are an additional expense but it isn’t necessary to monitor every trap.
To date our camera data is proving very effective and appears to reflect the inverse of trap activity - more predators caught equals less camera triggers.

1 Like
#3

Great point raised and would love to something back from Trap.NZ on this.

Also, I am a manage across two projects and an administrator for another
when looking at the AT220 Telemetry Reports. it read the data from across all three. And as there is no way to separate the data out. thus, make’s things hard when looking at triggers. (I have to select the individual traps)

There also needs to be some way to edit the telemetry data at the back end to simplify the reporting process. currently we have 1,470 All triggers and 195 Possums. this is around three times the total for last year and were only in May.

#4

Short answer is trap nights work best for single fire, non remote monitored traps, as that is what it was designed for.

We would have to make a bunch of changes to make that report useful for self resetting traps. It would have some similarities to trap nights (to capture time in the field as an effective trap), but it would likely mean a new report with a different set of data captured.

We are working on methods / reports to improve the value derived from self resetting traps.

1 Like
#5

Thanks Lenore,

I suggest that this conversation needs expanding to become a long answer because this cuts to the heart of being able to compare the effectiveness of different trap types… which needs a consistent metric.

I need to measure several things:

  1. Our overall trapping progress - are we seeing kill rates (measured by kills per 100 trap nights) decline consistently across our area of interest?
  2. Our species-specific trapping progress - are we seeing each target species decline consistently across our area of interest?
  3. Our individual trap performance - how are individual traps performing? Do we need to move under-performing traps?
  4. Trap type effectiveness - how do different trap types compare in their effectiveness?

At present, I can only measure 1,2 and 3 for manual traps. Which as I mentioned before is okay as long as I have an equal distribution of manual and automatic traps because my manual trap stats are an acceptable proxy for my automatic traps.

But 4 is a critically important measure for investment. If I’m putting a funding application together, it’s critically important that I can justify why I’m selecting a particular trap type. Given the high capital cost of automatic traps, I need evidence.

I can gather that by having an entirely seperate set of spreadsheets for A24s, AT220s and AT520s… and then compare overall metrics (AT220s have an catch/100Trap Night averages of 6.0 overall and 0.43 for possums versus the same area manual trap averages of 0.7 and 0.09 respectively… a massive difference). But it would be so much easier if Trap.NZ could handle that.

Cheers

David

1 Like
#6

Another thing that we are grappling with is that the AT220 traps will fire several times each night to clear any beam obstructions until the pest drops out of the trap. This is inflating our rats count. The possums are recorded differently by an accelerometer so should be accurate. Apparently the detail of the telemetry can be examined to determine false triggers but I haven’t worked out out how to do that. I’ve asked NZ auto traps to put up some explanation.

1 Like
#7

Hi there. The AT220 will preform a “clearing fire” if at the beginning of the night the sender eyes are blocked. This clearing fire is usually enough to clear any remains blocking the sender eyes.
It will only preform one of these clearing fires - this is usually enough to remove the remains, and if not additional fires will not help. It will however repeat this if the eyes are still blocked the following night, in hope to remove the blockage. It will do this until the eyes are cleared, or battery runs out.
These clearing fires are tallied in the “All Cycles” count when using the app, not the “Triggers”, so shouldn’t be inflating your rat counts.
Hope that helps.

3 Likes
#8

Hi David,
Important issue you raise, I be misunderstanding your issue but it seems to me that the data you require is stored in the AT220 log. Maybe easy (automatic?) downloading of this log into TrapNZ would solve the problem. It would identify accurately the date and time of any catches.
Maybe your query should be directed to NZ Autotraps?
For what it’s worth I don’t have the number of AT traps that you do but I use excel to record catches, entering data when I clear the traps and get an average over time.

Cheers,
Pat

1 Like
#9

We are working on a spreadsheet that takes the Goodnature dashboard data and aligns with Trapnz codes , set up to match the trapnz record import table and excludes catches recorded in close succession and day time catches.

1 Like
#10

Hi eict2024, I work for Goodnature and have been working on building a similar tool, could you please get in touch with me so we can look at how we can work together to ensure we’re not building the same thing twice?

Email is hello@goodnature.co.nz

Thanks!
Andy Jenkins

#11

Do GoodNature have a dashboard for public use at this time?

#12

Hello David. I have been following the Bluff Hill postings closely and trying to have your innovations applied to Pest Free Kaipatiki. Perhaps I can help with the data analysis. Please don’t use a spreadsheet. Have you considered using the WFS feed provided by TrapNZ? This is a much better way of doing further automated analysis of the records collected in TrapNZ.
If you need a no-code solution, then just ask AI to do the coding! :grinning: Or me.

#13

Hi Kim! It’s great to hear from you after all these years!

My challenge is that our automatic trap data never goes near Trap.NZ. That’s because the current ingestion mechanisms just can’t keep pace with the avalanche of data. And also because the relationship between ‘trigger’ and ‘kill’ still hasn’t been sorted out in Trap.NZ.

I only put manual trap data into Trap.NZ. The platform does a great job getting me the baseline stats out - I really only need the Corrected Catch Rate out… and then I use the WFS feed for visualisation in ArcGIS.

I then use the Goodnature dashboard for the A24 data coming from my SmartCapped devices. We have a total fleet of about 1,000 A24s of which around 200 are instrumented… which is statistically enough to correlate from. I use a spreadsheet to calculate Corrected Catch Rates from the A24s (to compare against manual traps).

For AT220s (we have 130), I use a spreadsheet to get the counts for large and small triggers and can then calculate Corrected Catch Rates.

Finally (and most complex), for AT520s (we have 100+ another 50 that we monitor for other organisations), I use the Integrated Management System to go through all the in-trap image captures and load the data into a MOASS (Mother of All SpreadSheets)… so that I can calculate daily presence for each species (sort-of like a daily RTI or RTC) and then the Corrected Catch Rates per trap, per species and overall.

I can’t code my way out of this because of the big data bottleneck at Trap.NZ. In some nirvana (2050?), Trap.NZ will directly connect to all the different trap and monitor systems, directly ingest the flood of data, miraculously make sense of triggers versus kills, and then spit out meaningful dashboards. We’re a long way from that.

I perhaps need to be clear that I’m not criticizing Trap.NZ. If a finger is going to be pointed, it is at the plethora of closed, proprietary platforms that pop up for each trap or monitor solution. It’s like GIS in the 1990s! Perhaps we need an Open Trapping Consortium! (Just kidding :slight_smile: )

Meanwhile, Spreadsheets are us!

All the best

David

1 Like
#14

Kia ora David,

Love the thread and the work you’ve been doing.

There are sub threads here delving into hardware limitations and data normalisation challenges. As you know it is not an easy challenge to make sense of the data even if you can get it.

The Trap.nz position has been that of prioritising ease of data collection for everyone, while maintaining quality data, and protecting data sovereignty. We’re very proud of what has been achieved on that side - on a shoe string budget. We’ll never be completely satisfied, but we’re satisfied enough to begin the pivot to next generation performance and analysis - customisable dashboards, and planning tools.

We obviously agree that a future of MOASSs is not one anybody wants. We have actively encouraged open sharing from the ‘closed, proprietary platforms’. The good news is there aren’t that many, and most have been open and willing to assist. There are active conversations in this space which we will progress. Various political hurdles have slowed things, notably the closure of PF2050 Ltd. Despite that some of those conversations have already progressed it to the work bench and are well along the path.

andrew.jenkinses, it would be great to have a chat, we are keen to support.

We have already prototyped the next generation dashboards and are pleased with the insights and direction they provide. The job of turning that into a production ready tool set - one that is consumable and meaningful to a broad audience - is our next challenge.

We would love to have your input …

Andy
Trap.nz

#15

Thanks for the reply Andy,

I re-read my post and it was a little too negative - I am a huge cheerleader for Trap.NZ in being an island of interoperability sanity in an ocean of closed solutions. I also respect that as you’ve grown your user base, your funding base isn’t growing… the curse of conservation technology. You’re right to be proud of what you’ve achieved.

Having spent the bulk of my working life in the GIS space, I’m a firm believer in open standards as a lowest common denominator of information TRANSFER. In conservation, we urgently need to see the development of open standards so that proprietary systems can transfer data about predator control and monitoring activities seamlessly.

But those standards require money to develop and consensus to implement. Sadly, in conservation, whilst consensus is the norm, money isn’t. Conservation IT isn’t the greatest. We tend to have world-class hardware, cobbled together with software that leaves a LOT to be desired. And that’s because the money just isn’t there. That means that we’re starting from a difficult baseline to achieve any form of standards implementation.

I’m looking forward to seeing your new dashboards… because they might incentivise me to start moving more automatic trap data into Trap.NZ.

Cheers

David

1 Like