Subsequent trap records showing up as None

Issues and bugs
#1

Hey team!

Just noticed an issue with our catch data based on how we occasionally enter multiple catch records through the trap.nz app.

As a backyard community group we get people reporting multiple catches for a trap. When entering these records through the trap.nz app I’ve noticed that the second record is not recorded as expected when doing the following:

  1. Selecting a trap, selecting the species (rat), and pressing/holding save.
  2. While the trap is still selected and the species still shows rat, pressing/holding save to log a subsequent record.

After saving the first catch, the Trap Status field appears and is set to “Still set, bait bad”, and the species is still set to Rat, but looking at the records through the website we see Species:None, Strikes:0.

Capture
Capture1186×111 4.61 KB

I’m guessing we’re not using the app as intended for logging multiple strikes, but thought I would raise it incase others are doing the same. Closing out of the trap, and going back into it to log the second record works fine.

App version: 4.1.3

Cheers, Timon

#2

Hi Timon,

What sort of traps are these? You shouldn’t be adding subsequent catches in this way, but equally the app shouldn’t show ‘rat’ then record ‘none’ (we’ll fix this.)

For multi-kill traps use the strikes field which indicates how many times the trap has fired. If there is no species entered, the system logs the catch as ‘unspecified’ rather than ‘none’.

For double sets (box with two traps) add a collocated trap for the second one, as described here:
https://help.trap.nz/books/trapnz-comprehensive-user-guide/page/trap-records

Andy

#3

Thanks Andy,

The trap types are not multi-kill, but most have rat + mouse trap collocated. They were never setup as collocation traps in trap.nz so this is something we can think about. We have volunteers who don’t use trap.nz currently and report in aggregated catch data which is why we are sometimes logging multiple catches for a single kill trap.

Cheers, Timon

#4

For reference, this was fixed in v5.