In which Wildbook did the issue occur? Whiskerbook
What operating system were you using? Win 11
What web browser were you using? latest chrome
What is your role on the site? admin & orgadmin
What happened?
An encounter with the location ID of Jura was sent to ID and returned 12 possible matches. However, the target encounter is the only encounter in Whiskerbook using the location ID of Jura. So there shouldn’t have been any match candidates.
What did you expect to happen? No match candidates to be found
I also saw this in a sample match results page run by @jason to see the new algorithm in action: Wildbook for Carnivores
In the case above, the target encounter is using location ID “Africa - South” and match candidates #2, 5, & 8 are using the location ID “Africa - East”.
Another unrelated bug is that those same match candidates from Africa - East (#2, 5 & 8) are all displaying a social unit name “Western Xigera Pride” but the individuals in these match candidate encounters are not part of that pride and do not have a social unit assigned at all. The Western Xigera pride social unit name belongs on the target encounter and probably some if not all of the “Xig-” identified encounters in the rest of the match candidates list. But it definitely shouldn’t be displaying on the Africa - East match candidates.
Since this covers two separate issues (the extra match candidates that aren’t in Jura and the incorrect social unit names) I’ll need a bit more time to untangle this. I’ll post here as I have updates or follow-up questions.
The only way I can get back to the original match result against 443 candidate annotations is to remove the Jura filter and match against everything. This doesn’t appear to be a bug.
For ACW, I’m still testing what’s going on with the Africa - East candidates appearing in the Africa - South search results as well as the mislabeled Western Xigera Pride issue.
The incorrect prides was the result of a bug where if the query individual is part of a pride, then all the matches appeared as part of the same pride. The fix will force it to check the social unit name on every annotation instead of just the source encounter.
I tried reproducing the mixed result for lions when specifying a location ID and could not. I also looked at the underlying database query, and the results were as I would expect.
I started with this Encounter:
I then started a match for only Africa-South:
And then one for Africa-East:
Both were proportionally about what I would expect.
I then went back to the original link:
And I found in the metadata that no location ID was specificied. I think in this case the original link was run without a locationID set for matching.
