"Next suggested new ID" increment can re-offer an old IDnumber already assigned

Hello :slight_smile:

What is the use of the increment numbers for naming?
In all individual wildlife tracking databases, each individual is assigned a unique number to ensure it cannot be confused. The individual will often then be renamed or given a nickname, but it always retains its unique identifier somewhere on his name, so it can’t be confused.

What’s the problem?
When naming a new individual in Whiskerbook, the “Next suggested new ID” increment can be reversed, which can lead to two individuals having the same assigned number.

Proposed solution: the increment sould never decrease, but only increase.

I documented a case to illustrate the problem.

The next proposed name is 5006 :

I assign the number 5006 to the new individual :

The next proposed number is 5007 :

I wait a few days.

The proposed name has dropped back to 5005 :

I really hope it will be possible to fix this or offer a built-in alternative to have a unique number integrated into each individual name. This is a major element to ensure there is no confusion between individuals.

Thanks for your help :pray:

Hi @Lucas

How often do you see this and how many days days did you have to wait to see the repeated ID? Do you have links to the encounters from your screenshots? This will take longer to research without it.

If you hear of any other users experiencing the same issue, be sure to refer them to Community to post about it, preferably with links to the encounter pages so we can research it.

Hi @Anastasia

Yes, all Whiskerbook users have this problem since it involves naming individuals. We discussed it at a meeting this week and of course all 10 people present were concerned and worried. I don’t know about other Wildbooks, but I assume it must have the same problem.

Here’s the encounter where I ran this test: https://www.whiskerbook.org/encounters/encounter.jsp?number=f22ef670-44b3-4db3-a526-7cb02b19f83b

I waited 48 hours before going back to see if the increment had decreased.

I think the problem lies in how the “next available number” is determined. It should be an ever-increasing counter (= if a number has already been assigned, it can never be assigned again), which is simple and has no drawbacks.

When you choose the proposed name 5006 (for example), it creates an individual 5006. It should never suggest a 5006 again, but I think it will check each time if a 5006 already exists. However, in an individual’s main name (which is the one displayed in match results), there is other information to include, for example, the way users refer to them. So, for example, we’ll enter “5006_KITTY.”. I think in this case, the software considers the name 5006 to be “available again,” which is catastrophic because it creates confusion among individuals who ultimately all have the same “unique number.”

It’s a bit complex, I hope I explained it correctly :slight_smile:

Thanks for the link and additional context. Your test individual was named “5006_CHATST_G” which is not the same as “5006”. There is no lynx named “5006” in Whiskerbook, which is why it keeps suggesting it as an ID even if you add variations to 5006 for your org’s naming conventions.

This isn’t a bug and is working as intended.

Hello Anastasia,

Indeed I agree, so I posted in the “Support” section and not in the “Bug Report” section, because I need help and support to find a solution to the problem I tried to describe as best I could.

I tried to suggest a solution that seemed logical to me and that I thought was not too hard to implement (but I may be wrong) : the software would record the “last given value” and then add 1 to the proposed value without ever going back to a number it has already given, but it was just an idea.

I really need help to find a workaround, even if it’s a “workflow” solution. Do you have any ideas please ?

Jason, perhaps you may please have a workaround in mind for us ?

The need could be summed up as “having a unique number that increments by 1 for each new individual”. By integrating this number into the name of the lynx we can say "I have a data of 5005_KITTY to pass to you and not to confuse it with 5008_KITTY.

Thanks for you help :pray:

*PS : just to be clear on a point where I’m not sure I was → the lynx was first named “5006” and later it was added “_CHATST_G” at the end, to make 5006_CHATST_G, but somewhere in the timeline it was named just “5006”

Because every organization has different conventions for how they catalog individuals, this doesn’t seem like something that would be broadly applicable across all Wildbooks. Our philosophy has always been to leave it up to individual researchers/orgs to determine how they manage their IDs.

One suggestion would be to post to the Community Research category to ask other Wildbook users how they track their next available IDs. Wildbooks suggest a next available ID for users who may not already have an ID protocol in place.

Thanks Anastasia.

Eureka!!!
I found the solution!

If anyone ever has this problem : just enter the number/name in any of the additional names boxes, and the software won’t propose it again for future individuals.

Phew, that’ll solve a big problem for us! :partying_face: :partying_face: