Hi Anastasia,
@Sarah_Aus_SpotaShark has identified an issue with Carcharias taurus Location IDs in Sharkbook that I’ve been able to replicate. We are looking specifically at two sites, Flat Rock and Wolf Rock, for current analyses.
Both sites have the same issue, in that Location IDs are variably showing as ‘Flat Rock’ (or ‘Wolf Rock’), which is what we want, or ‘FT’ (‘WR’), which is not what we want.
There seems to be an issue with the Location ID hierarchical classification.
For sites showing a ‘FT’ Location ID, the encounter looks like this:
Example URL: Sharkbook: Wildbook for Sharks
For sites showing a ‘Flat Rock’ Location ID, the encounter looks like this:
Example URL: Sharkbook: Wildbook for Sharks
It’s the same for ‘WR’ encounters (example: Sharkbook: Wildbook for Sharks) versus ‘Wolf Rock’ (example: Sharkbook: Wildbook for Sharks).
How do we integrate the Location IDs?
Thanks!
Simon (& Sarah).
Hi @simonjpierce
This isn’t a bug, but is part of an ongoing code cleanup we have an internal ticket for: Cleanup for mismatched name and id fields in locationID.json · Issue #711 · WildMeOrg/Wildbook · GitHub
Looking at your two examples, this is what the code for each looks like:
{
"name": "Flat Rock",
"id": "FT",
"geospatialInfo": {
"lat": -27.1333333,
"long": 153.5583333
},
"locationID": []
},
{
"name": "Wolf Rock",
"id": "WR",
"geospatialInfo": {
"lat": -25.9111111,
"long": 153.2055556
},
"locationID": []
},
Name is what displays in the user-facing parts of the site (like in drop-down menus) and id is what Wildbook actually interprets the entry as. Ideally, the name and id fields should match. The mismatch is present mostly in older Wildbooks, though I’m not sure of the original reason for the abbreviations.
We’re gradually working through these. It’s pretty time-consuming and some location ID files contain up to 1000 lines of code that need to be manually fixed. I don’t have a timeline for when this will complete.
There’s also a separate possibility that if any of these were imported with a trailing space in the location ID name (such as a space before or after it). Sharkbook accepts the import without flagging that field with an error, but it treats it as a new location ID because it doesn’t match the exact way the location appears in the code. There’s a separate effort to add more validation during bulk imports for future Wildbook versions so that it will flag issues in the metadata in the import workflow instead of accepting and committing invalid entries.
