Closed karenmajewicz closed 1 month ago
GeoBlacklight Sidecar Images is closely tied to the viewer_protocol
value for each SolrDocument, which here is iiif_manifest
, but we don't have support for thumbnails from IIIF Manifests.
This item, and others like it, are being "placeheld", as the thumbnail process returns this transaction:
{"solr_doc_id"=>"pst_0083368041", "solr_version"=>1796518337326350336, "placeheld"=>true, "viewer_protocol"=>"iiif_manifest", "error"=>"service_url NameError", "image_url"=>nil, "gblsi_thumbnail_uri"=>false}
A couple options for these type of items...
All the items in this set do have an Image API in addition to the Presentation API. Could the image harvest code be configured to look for the Image API first? Is that what your option 1 is?
It would be very handy to generate a thumbnail from the first image of a manifest though.
Yeah, we need to enhance GBL Sidecar Images to better handle IIIF Manifests and to also check for other potential thumbnail options if the default viewer protocol doesn't pan out.
It appears that most of these have harvested, but they are not showing up in the search results.
Yeah, we are still presenting the old ActiveStorage thumbnails in production (wanted to make sure the initial bulk harvest was successful). We need to switch over to Kithe/Shrine.rb/Amazon thumbnails.
I originally uploaded the items in this collection with thumbnail links that don't work.
I then removed the bad links and added IIIF image APIs instead. Can we clear the originally links and set these to reharvest thumbnails using the IIIF API instead?