dnoneill

Our world iiif3 manifests look good but there is a validating problem https://presentation-validator.iiif.io/ in our stanford only manifests which should be fixed before we try this: https://purl.stanford.edu/bd117rc5047/iiif3/manifest

List of Metadata differences: @andrewjbtw could use your guidance on these differences. - [ ] PublishDate is a different date. In v2 we got the date from the xml (https://purl.stanford.edu/bc592pz8308.xml)....

Do we want to keep the original source file in here?

https://github.com/sul-dlss/sul-embed/pull/2911 should finish this. The following PRs were all part of fixing up the manifests so the metadata was correct. [fix v3 manifest validator errors](https://github.com/sul-dlss/purl/pull/1279) [fix image manifests for mixed...

@andrewjbtw That is currently what is being used. We get the updated_date from the version. We can structure it so it more looks like the date in versions but the...

Okay the relation field is waiting for a cocina_display. The good changes were on purpose. The download source file size discrepancy is an actual size discrepancy between files: Prod: Stage:

This is an issue for [gk831nh0251](https://purl.stanford.edu/gk831nh0251) coming from the data. If you look at what is coming from geoserver it is also encoded wrong. https://geowebservices.stanford.edu/geoserver/wms/?LAYERS=druid%3Agk831nh0251&BBOX=-343.125%2C-69.90011762668541%2C345.93750000000006%2C64.77412531292873&WIDTH=980&HEIGHT=263&QUERY_LAYERS=druid%3Agk831nh0251&X=262&Y=119&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetFeatureInfo&STYLES=&SRS=EPSG%3A4326&EXCEPTIONS=application%2Fjson&INFO_FORMAT=application%2Fjson

Yeah it is doing a re-render because the form wasn't entered correctly. I guess we could redo spotlight to redirect instead of render but I am not quite sure how...

closing because it seems only to be my system. Tested with two other devs and it worked.

@jcoyne Yeah but the way I understood it, it was already a dependency of spotlight?