Missing images = error

Feature Requests
,
1

What Wildbook should this feature be in? GiraffeSpotter

What would you like to see? Previously, one could upload an xlsx form with image names that are not present in the image upload folder. It was alerted (highlighted yellow) but not an error and bulk upload could continue. A recent update has made that any missing image names are an error (highlighted red) and one cannot continue to bulk upload without removing them from the xlsx form. I would like to request this return to not classify as an error if possible.

How would this functionality help you? I would like to keep record that the image(s) was taken but I just have not been able to locate it. At the moment I must delete all record of the image if it is missing, and I donā€™t like to remove information :wink:

If requesting a new location ID, include

  • Is this is nested beneath another location in the hierarchy?
  • Is there a prefix for region-based naming? (optional)
  • GPS coordinates (optional)

Note: Not all feature requests can be accepted, but all of them are reviewed by our product team. Weā€™re unable to provide implementation timelines for accepted requests. We are a small team with many competing priorities. Thanks for your understanding!

1 Like
2

I strongly support this although Iā€™d label it a bug, as the functionality that existed previously is now not working.

It is possible, in earlier versions of WB, for a user to upload metadata without any image as often images have been lost or misplaced. Itā€™s critical that users be able to record event metadata including the photo file name, even if the photo isnā€™t available.

This needs to be the case for both Report an Encounter and bulk imports. This is required functionality for the Eurasian lynx (and Iā€™m sure other species in addition to giraffe), particularly for historical data.

thanks
Maureen

cc: @PaulK @Lucas @jason

3

This change has significantly reduced the number of support requests related to image files names not matching media asset data in the spreadsheet; weā€™re not likely to undo it. :sweat_smile:

However, media asset data isnā€™t required to upload a bulk import or report a single encounter.

For a bulk import: If you know the image name, but donā€™t have the image itself, you can document it under Encounter.researcherComments (adds the comment in the Audit Trail of the encounter) or Encounter.occurrenceRemarks (add the comment under the Attributes section of the encounter). This lets you create an encounter with the data you have without the image, but the image name is still recorded with it.

For an individual encounter report: Fill out the form as usual and skip past the image upload part. Add the file name to the Additional comments section.

1 Like
4

Hi @CourtneyMarne

I would like to keep record that the image(s) was taken but I just have not been able to locate it.

On our side, even under the old system we would not preserve the record of a missing image. No Wildbook data construct on our side would be created to hold an empty reference.

For supportability, we really need to insist on high data consistency, or as @Anastasia mentioned, we get support requests about missing data and spend time tracking down missing imagery that we ultimately never received.

I follow this same protocol when doing my own bulk imports (I help users create several per month and am doing two currently) and work to get 100% image reference accuracy to ensure we capure all of the data users intend. If we canā€™t find a small subset of images together, they get left out of the spreadsheet as they would be ignored by Wildbook anyway.

Thank you,
Jason

5

Hi @CourtneyMarne @jason and @Anastasia ,

Iā€™m wondering if there isnā€™t a missed opportunity here. I can appreciate the need to reduce support tickets and by association, confusion and errors on the part of users, but I feel like we could have delivered value to both stakeholders with a slight adjustment to the solution to the support burden, that takes into account the use case of being able to include the image file name with the metadata, even when the file itself is missing.

And since it looks like the current solution for reducing suppport tickets has resulted in support tickets elicited by the consequences of that solution, Iā€™m not sure this is actually solved from the support perspective nevermind the end user perspective.

Also, the suggested workaround of using comments/remarks fields for image file names isnā€™t ideal since other, free text information is often included in the suggested alternate fields (Encounter.researcherComments & Encounter.occurrenceRemarks). This means that putting the image file name in these fields buries it in a field that isnā€™t the image file name field - Encounter.mediaAssetX.

It seems to me that ideally, all image file names should be consistently captured in the same database field; not some in the media asset field and some in the comments and/or remarks field, especially since the latters could be mixed with a bunch of other free text.

Lastly, the fact that these ā€˜orphanedā€™ image file names havenā€™t been saved in the past doesnā€™t necessarily mean that they shouldnā€™t be.

Continuity and traceability of the data from source to Wildbook and then offline again, is critical. Also, tracking every single encounter with a supported species, whether the image is available or no,t is also critical.

To address both the support reduction need, which has been addressed with the solution now in place, and the end user need to track all encounters whether they include an image or not, would it be not be possible to make the upload of image file name without an associated image, trigger a warning popup that says something along the lines of ā€œare you sure you want to upload with missing imagesā€ where users can agree or not. Additionally allowing the storage of the file name in the standard image file name field (Encounter.mediaAssetX) regardless of whether the image is in the database or not, would address the end user need and not negatively affect support.

Appreciate all thoughts on this alternative solution that would address the legitimate end user need raised by @CourtneyMarne in this post.

thanks
Maureen

cc: @PaulK @Lucas @mbrown

7

This is precisely what the comment fields are meant for: information that doesnā€™t quite fit standard metadata fields.

This request was already marked as unplanned and Iā€™ve locked this topic so we donā€™t continue belaboring the point.

1 Like