Encounters w/o location IDs are being presented as match candidates

Support
,
1

We’ve come across an issue where some encounters are being presented as match candidates even though they don’t have a location ID assigned.

Here’s the match results page where we’re seeing this - the source encounters for match candidates #1, 2, 3 & 5 don’t have location IDs:

I’m wondering if there’s a possible contributing factor - each of the match candidate encounters that lack a location ID are duplicate annotations in the system. The source encounters of the duplicate annotations (that are not being presented as match candidates here) do have location IDs.

I know that duplicates in the system can cause issues with match results, among other things so I’m wondering if the fact that the version of the annotation being presented as a match candidate, which doesn’t have a location ID, is somehow being confused during the interaction with WBIA, with the version of the annotation that does have the location ID?

The reason for the duplicates is that I needed a very specific type of data for testing purposes. I specifically excluded the location ID so that this data wouldn’t get mixed in to the match candidate dataset in the database but that didn’t work as expected, obviously.

I’ll be deleting the test data however we (@Lucas) and I wanted to be sure that this isn’t a bug where data without location ID is being included in the matching dataset before I do that as that’s a scenario that that org & others in the same region, will use in future for various reasons, specifically to exclude certain data from matching.

Thanks for helping us understand the source of this problem - whether it’s a bug where encounters without location IDs are being included in matching when they shouldn’t be or if it’s a problem with the annotation duplication and WBIA not liking duplicates like this.

Maureen

2

This doesn’t sound like a bug. Animals without location IDs are included into every match pool of its species and viewpoint to increase the likelihood of a positive identification.

3

Interesting. That’s the opposite of how it works when a single encounter is sent to identification - the location ID of the source encounter is pre-checked in the match against criteria and the option to include data without location ID “match data without location ID” is unchecked by default.

It would be great if these 2 methods were consistent in their inclusion or not of data without location IDs to avoid confusion about matching functionality overall but it’s good to have it clarified. thanks @Anastasia

2 Likes
4

Feel free to add this as a feature request so we can explore that.