IIIF Component - Adds IIIF manifest viewer support via Clover integration#74
IIIF Component - Adds IIIF manifest viewer support via Clover integration#74ewlarson wants to merge 4 commits intoOpenGeoMetadata:mainfrom
Conversation
Adds Clover as a IIIF Component, loaded via UMD. Tries to be as lightweight of an implementation as possible.
Replace ref callback with querySelector to fix "[object Object]" error. Add missing spinner import and defer state updates to prevent lifecycle warnings.
Mock Shoelace import and suppress expected console.error in error handling tests.
|
Thanks for working on this! The work in #75 represents what I was hoping to go for – something that doesn't bring in Clover or another viewer and just does a very basic zoomable image with OpenSeaDragon. I had this locally, but hadn't made time to push it up...sorry about that. The approach of inserting the IIIF viewer into an iframe is interesting – it does keep ogm-viewer lightweight, but nesting an iframe into the shadow DOM feels like a lot of indirection. Right now I think I'd rather just go ahead and bundle OpenSeaDragon into the ogm-viewer so that there are no runtime dependencies. |
|
I should say though – there's probably items out there with manifests that the approach in #75 won't handle (i.e. they would need a real viewer). In that case, I think we have a tough choice...either we pick a viewer and integrate it (as in this PR), or we just let the consuming application decide to render a IIIF viewer if it wants instead (and don't try to render the item in ogm-viewer, maybe just showing a bounding box). When you use a IIIF viewer to render a manifest from an OpenGeoMetadata record, you get into this weird space where the manifest potentially provides a bunch of metadata (title, rights, etc.) that duplicates or even may differ from the OGM JSON record. Right now I'm kind of thinking that ogm-viewer is first and foremost a viewer for the OGM record, and so we should prefer the metadata that actually comes from that record, instead of doing what a IIIF viewer would do and attempting to render everything from the manifest. Maybe this is the wrong way of going about things...not sure yet! |
|
Yeah, I thought that was your take from earlier discussion and tickets. I'll take a look at your OSD path here — but I do worry IIIF is just complex enough (and increasing!) that we'll ultimately need a full-fledged IIIF viewer option. The OGM Viewer should definitely be focused on the OGM Aardvark metadata. But! There are times where the IIIF Manifest has some really good map data tho, like Princeton's scanned maps many times have a Cartographic Scale value that Aardvark doesn't support. Gah, decisions... |
2 participants
This DRAFT PR integrates the Clover IIIF viewer as a new viewer component. I'm not sure this matches your IIIF expectations for this project, but I tried to find a way to add IIIF support with as lightweight a footprint as possible.
The viewer is isolated in an iframe to avoid DOM conflicts with OpenSeadragon. The viewer automatically detects IIIF manifests in record references and switches from map view to IIIF image viewer as necessary.
Changes:
Addresses #19