Thanks for the feedback. Projects are by design Encounter-based, meaning if two encounters are of the same individual, they will be listed twice in the project. We do not merge encounters when assigning them to the same individual because we do not know ourselves (as the programmers) whether these are two distinct encounters but separated by a small gap in time or whether they are duplicative. That in and of itself can be difficult to determine (i.e. whether something is a dupliate) because two observers can report the same whale, for example, with separate photos.
We leave the concept of duplication and merging to users. It is not something we can safely execute on our own (in the database or the user interface) without making asumptions on behalf of users that then cause confusion for others.
thanks for clarifying. Would it be possible to delete one of the entries (or encounters) from the project list without losing the encounter? So if two encounters are already matched to the same individual but both encounters are still listed as separate entries, does this mean, both encounters would be retained if one of the entires in the list was deleted?
I’m mostly concerned that when I export the project data, for example in the .inp format for population size estimations using the Jolly-Seber method in MARK/RMARK that this could cause problems/faulty results.
You account for multiple observation in setting your primary (and secondary if applicable) sessions in your model (e.g., Cormack Jolly Seber). If one, two, ten, or more encounters for the individual exist for the same primary session, the individual will only ever get a “1” in the session column in the INP file.
If you end up using number of encounters as a proxy for effort, you may need to do some de-duplication (e.g., remove duplicate encounters of same individual on same day), but this is pretty easily done with quick data manipulation. I did this in the following papers, which we exported from the original Wildbook for Whale Sharks (now sharkbook.ai).