Why is the recording of bait measured in Kgs?
The logical measurement would numbers of blocks ( 28 grams)
Whenever I input records I ignore Kgs as do other users.
We hope to make this possible soon. There is a variety of bait types with different sized blocks, pellets, etc, so we need to have a mechanism where the unit weight can be set before the data is entered.
We use 28gm block as well and ignore the kgs to record the bait blocks used. This works fine until you changed the app. I have queried this some time ago soon after you launched the new app and you said you were working on it and would be fixed shortly. Where are you at with this? My volunteers are complaining about having to use a note book and then inputting the data later using the website. Please don’t upgrade the website to be the same as the app. without catering for the 28gm blocks.
Hi gullyresotoration,
“Please don’t upgrade the website to be the same as the app. without catering for the 28gm blocks.”
Can we assume then you want the website to work the same way the app does?
“My volunteers are complaining about having to use a note book and then inputting the data later using the website.”
The app currently caters for your 28gm blocks so what is the reason for the volunteers ‘having’ to use a notebook?
For completeness here is how the current app handles the 28gm scenario:
With the new app you define your own unit size for bait, so in your case it would look as follows (assuming you use no more than 5 blocks per station.)
With that set up the slider is stepped at 28gram intervals.
At this stage the bait configs are per device so not sharable, but the plan is to make it project based with perhaps some common brand options available to all projects.
I am new to TRAP.NZ, so this is all new to me. But I am tasked with loading up our group’s 20 baitlines with ~200 stations and transitioning all users to TRAP.NZ.
One obstacle has already been that our previous records all use block counts, not grams of bait. Under the current system, baiters can enter fractions of a block, but out in the bush they are going to have to convert that to g, though they think in blocks, and our reporting until now has all been in blocks…
The image below showing the sliders (Mar2019) looks to be an improvement, is it now operational? Can users have the option to “slide” in blocks or in g, then if necessary, conversion behind the scenes to g?
It seems to me that if the app and the website work differently it will complicate the transition.
Don’t hold your breath, I asked about this 4 years ago 
and indeed that turns out to be so. We have some baiters using the mobile apps in the bush, and others using the website at home because eg they don’t want their phones contaminated, or they can’t get a clear signal, or they have enough to carry already. So the former have that have active ingredient (in gms) and the others have number of blocks (in “kg”).
So when I run a report of bait placed or eaten, the totals represent a mix of the two measures. This is not helpful!
Must I export the data, do a conversion of one of the measures, then make a report myself?
So Andy, in your example (thanks for the images, that helps) we get in the record the number of grams. But the same entry done on the website, when we enter n blocks (as Kgs, as advised elsewhere on this site), would show there remain ~6 kgs and one added. No summary reporting will be helpful here without transforming one or other of the measures.
So what’s the hold-up in making the two systems work similarly? It’s been a while, people (not just Paul above) are telling me it won’t happen. I don’t understand why the different systems happened and why the options cannot be set that make it “just work” !
Thanks,
Jo
Please, what happened to this promise?
- Not being able to record and report in bait blocks (not limited to grams of kilograms) is truly frustrating and time consuming, makes errors easy, hard to detect and difficult to correct.
- Not having a set of NZ-available baits & their descriptors (brand name, active ingredient, formulation, unit weight & concentration), perhaps in a relational database, with common access - or even just as project categories - opens up the system to errors in data entry, perpetually, with questionable benefit.
- Allowing a record to be entered, without any warnings, that make a bait station have more bait than it can physically hold, and allowing more bait to be removed than is currently in the station, without offering any warnings, means any data quality assurance system has to be manually driven, but probably means it just does not happen.
To me, these are all basic systems features. Baiting is the predator control method of choice in urban areas and other places where rat trapping is not feasible or permitted. I understand that TRAP.NZ was born for trapping, & evolved from there, but if it is be the centre of NZ pest control records, please can we baiters have some relief? Or even an update to the promise and so many requests from years ago?
Do we need a squeaky wheel campaign, or have baiters given up?
Sorry to be so negative, I know you all work so hard and do your best to provide good service, but imho sometimes the nice-to-have trapping features should wait until some basic baiting features are fixed?
1 Like