Merging different encounters of the same individual as it refers to the same sighting

[Anastasia]

Hi @lsimon

Good questions!

@lsimon

So we were wondering whether it might be possible, retrospectively, to merge all Encounters where the same individual was identified within the same Encounter.occurrenceID, so that on the individual’s page, it would appear as a single, unified encounter. For example, on the page for individual CCS_Pm_0102, who was only seen once on January 29th, 2024, there are currently three separate Encounters, even though they all correspond to the same sighting.

There isn’t a way to combine the encounters from the same sighting, but having seen what too many images on a single encounter can do in other Wildbooks, I think how you’re currently handling it is fine (especially since they share the same sighting/occurrence ID). There’s no exact limit, but encounter pages with too many photos can fail to load at all or load so slowly, it takes several minutes to complete. I don’t know how many images you typically capture per encounter, but if it’s only a handful, one workaround could be to remove the images from the second encounter before deleting it and uploading them manually to the first encounter using the Add image to encounter option at the bottom of the Gallery:

@lsimon

I also have another question. We’ve just started a collaboration with BMMRO, and we’ve granted each other edit access. CCS will need to perform bulk imports using their data (photos and the associated Excel files), and we would like to directly input their name into the Encounter.submitterID column.

However, we’re unsure if using our own CCS account to submit data with their Encounter.submitterID might cause any issues (since the account submitting wouldn’t match the one referenced in the submitterID). Alternatively, would it be easier — assuming both parties agree — for us to log in directly to their account in order to upload the data on their behalf?

I think this arrangement is fine, functionally. The only potential drawbacks I can see are:

• Only the user who uploaded the import can view it in their bulk import logs and take bulk actions on all of those encounters (sending all to ID, deleting the entire import, etc.). The assigned researcher would still be able to manage the encounter on an individual level, just not from the bulk import table.
• If you and CCS accidentally uploaded the same encounters from your respective accounts, you won’t be able to track the duplicates using our Data Integrity page. There was a recent issue reported in Community that appeared to be a bug but was actually the result of 3 different collaborators having accidentally uploaded the same encounters across different imports. Since the Data Integrity tools only show you data issues for encounters assigned to you, it wouldn’t flag a situation like the one in the post because duplicate uploads happened across different accounts instead of just one account.

So if you’re REALLY confident about who has uploaded what and everyone is collectively tracking that, then it should be ok.