Use Movebank `animal_id` for `individual_id`

[peterdesmet]

Hi! Reading the paper, I wanted to look up some of the calculated traits from birds we tagged. For example:

• movebank_study: 985143423
• animal_id: L907322
• scientific_name: Larus fuscus

However, in the MoveTrait.v0.1_individual.sum_20250311.csv file deposited on FigShare I couldn't find L907322 in the individual_id values for that study. The listed values are:

1218541454
1218541455
1218541456
1218541457
1218541458
1218541459
1606042784
1606042785
...

I assume these are internal Movebank identifiers for the individuals? How do I connect these to animal_id values such as L907322?

Suggestion

Would it be possible to use animal_id values in the next update of MoveTraits (i.e. L907322)? That is a public value that would make it a lot easier to lookup across systems:

• GBIF: https://www.gbif.org/occurrence/search?organism_id=L907322&advanced=1
• Movebank search: works for L907322, not for any of the values above

[annescharf]

Hi @peterdesmet , in Movebank each individual has 2 ids, the individual_local_identifier (ie L907322) and a internal id, which via the API is called animal_id (unfortunately, as on the website GUI individual_local_identifier and animal_id refer to the same name). The internal id cannot be viewed on the website
We chose to use the internal id (an integer) for the calculations because sometimes the name given by the user contains symbols that end up breaking R code.
It seems that we missed to include the individual_local_identifier in the final tables to enable the data owners to find their animals. Thank you for raising this issue. The use of the internal animal id should only be for the calculations, but the name given by the data user should be displayed. I will make sure to fix this in the code.

[peterdesmet]

Great, that makes sense!

unfortunately, as on the website GUI individual_local_identifier and animal_id refer to the same name

That is unfortunate indeed 😄

[sarahcd]

Yes, we need to fix this with the upcoming database updates. In my view, the internal db IDs should not be exposed to users, because it is too easy to misunderstand them and lose track of the local IDs, they mean nothing to the data owners, and they are not stable (a user can unknowingly create new internal IDs for the same local_identifiers when updating reference data). But it's a good point that custom names can break code. Maybe best practice is to create numeric IDs or reformat the names on the fly for a given use case—in this case, it would be intuitive for the analyst that these IDs are not stable and they need to keep track of the owners' IDs

…

On Thu, Feb 19, 2026 at 10:12 AM Peter Desmet ***@***.***> wrote: *peterdesmet* left a comment (annescharf/MoveTraitsDatabase#6) <#6 (comment)> Great, that makes sense! unfortunately, as on the website GUI individual_local_identifier and animal_id refer to the same name That is unfortunate indeed 😄 — Reply to this email directly, view it on GitHub <#6 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADYNNPSC2O6QEACCWB62KWL4MXHFDAVCNFSM6AAAAACVRG6C3OVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTSMRXHA4TKMJXGU> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[annescharf]

If I remember correctly the main issues were white spaces before or after the character string of the individual name, that get trimmed by default by some R functions. The use of the internal id is just for downloading the data at that particular moment and the remaining part of the code, and future linkages should not refer to these internal ids. I think that restricting the naming is suboptimal, as the name has to be something meaningful and recognisable. I find the internal ids pretty useful, but maybe they should not be accessible by default like now, but through an active choice

[sarahcd]

Ok, that's a database control problem, right? Shouldn't Movebank prohibit leading/trailing spaces in IDs (and maybe any other data values)? Are there other controls that we should have on animal/tag/deployment ID values? I made a ticket Movebank ticket "Prevent leading & trailing space in data values". In the meantime maybe write code to just remove spaces from the ID fields during data prep? Then at least a user could still recognize their names.

[annescharf]

When constructing the API call to download data the individual name has to be an exact match, and this is where the problem is. The code goes through several steps, and ends up with a vector of individual names that then get downloaded one by one. We actually fixed the automatic deleting of empty spaces in move2, so that was not anymore an issue. But there where still individuals (when I was downloading all storks for another project) that returned "no data for this individual". I randomly caught this by comparing two tables and seeing that the number of individuals did not match, and that I was missing data for a bunch of individuals. When comparing the names I had in R, and the names on the movebank website I could not see the difference, but could see that the individuals had data. Probably some symbols get corrupted when putting together the API call. I could have spent time debugging and finding out exactly what was going on, but given that I had an alternative solution by using the internal individual id, I went for the the faster solution. Foreseeing that in the data download for Movetraits this would happen too I kept the same strategy.

Current fix to be implemented: the internal individual id should only be used to construct the API call and thereafter be removed from the data set. The only individual id that should be present in the data set should be individual_local_identifier

Future (movebank 2.0): I think that there should not be high restrictions on the individual_local_idendifier, this is the name that people recognise and should contain what they need. Of course empty spaces before and after are just typos. I am not familiar on how the UIID is created, if this is user defined it should definitely be more restrictive, as I can foresee the UIID having a similar function as the internal animal id in a case like this one.

[annescharf]

Note to self: mistake occurs here https://github.com/annescharf/MoveTraitsDatabase/blob/main/04_merge_database.R#L51