Lion config - 1) able to "start match" on a lion body annotation & 2) no match results from manually added head annotations

In which Wildbook did the issue occur? ACW

What operating system were you using? Win 10

What web browser were you using? latest chrome

What is your role on the site? admin

What happened?
I’m adding manual annotations to a bulk import of lions where they are missing. In the first one I found where both the head and body annotations were missing, two issues occurred:

  1. After adding the body annotation, I went to the dropdown to add the head annotation and noticed that the ability to “start match” was enabled:
    Here’s an example encounter where I found this: Wildbook for Carnivores | Login
    image

This is only happening when the body annotation is added manually. When the annotation is created via IA, it is not matchable.

  1. After manually adding the head annotation, I kicked off matching for that head annotation on several encounters. After awhile, I went back to the encounter and noticed that the zebra dropdown menu for the head annotation (for ones where I had previously kicked off matching) now shows “no matchable detection” and offers the ability to “start another match”:
    Encounter for screenshot below: Wildbook for Carnivores | Login
    image

What did you expect to happen?

  1. I don’t expect to be able to kick off matching for bodies; only for head parts.
  2. I expect to find a link to “match results” in the zebra dropdown menu for the head annotation where I manually kicked off matching; I don’t expect to see “no matchable detection” in the same dropdown menu after having selected “start match” earlier.

What are some steps we could take to reproduce the issue?
View examples above; also go to source lion bulk imports to find other examples of missing annotations where they can be added manually to verify these issues.

thanks!
Maureen

Hi @ACWadmin1

Fortunately, this is just a configuration change. I adjusted the configuration to make sure those non-head classes no longer get set and made sure their match against status is false in the database.

Your example looks as intended now.

This should not happen again in the future, but please let me know if it does.

Thanks,
Jason

1 Like

Looks good @jason! Thanks very much!!

1 Like