Proposal: front/back COG images for scanned maps

[kgjenkins]

We are in the process of adding a large collection of scanned maps to our GBL instance. We would like to distribute the images as COGs, and allow users to preview/zoom/pan the images using the COG viewer in GBL. However, many of these maps have a front and a back (two separate COG images).

Currently, the COG key https://github.com/cogeotiff/cog-spec in dct_references_s only supports a single string value. We propose allowing it to optionally hold an array, similar to multiple downloads:

\"https://github.com/cogeotiff/cog-spec\":
[
  {\"label\":\"Front\", \"url\":\"https://example.com/front.tif\"},
  {\"label\":\"Back\", \"url\":\"https://example.com/back.tif\"}
]

We currently have some code working locally that will handle such a structure, presenting the COG map preview with tabs at the top for selecting the "Front" or "Back" image:

In cases where the COG key points to a single URL string, the COG viewer would retain the current behavior. It would only show the tabs when the value is an array of objects with a "label" key (and a "url" key pointing to the COG). So no changes would be necessary to existing Aardvark records.

[kgjenkins]

Here is a live example on our test server: https://cugir-dev.library.cornell.edu/catalog/cugir-smwg-01403

[thatbudakguy]

This seems like a really good use case for IIIF georef annotations – if the content were delivered as a IIIF manifest, you could get paged behavior, and note in the manifest that one side was "front" and one was "back", as well as delivering the annotations that would support displaying it as a map (instead of just an image).

Not that you can't do what's suggested here, it just seems like a good use case for that functionality!

I would love to explore additional ways to reference georef annotations in GBL's viewer (or the new viewer in development).

[kgjenkins]

In this case, we don't have an IIIF server for these maps, just the COGs.

[karenmajewicz]

Could we enable arrays for all/most of the reference types?

[thatbudakguy]

Another thought, maybe not fully baked: make references an array of objects. E.g.

{
  "dct_references_s": [
    {
      "label": "COG (front)",
      "uri": "https://github.com/cogeotiff/cog-spec",
      "source": "http://link.to/my-files/layername-1.geotiff"
    },
    {
      "label": "COG (back)",
      "uri": "https://github.com/cogeotiff/cog-spec",
      "source": "http://link.to/my-files/layername-2.geotiff"
    },
    {
      "label": "ISO 19139 metadata",
      "uri": "http://www.isotc211.org/schemas/2005/gmd/",
      "source": "http://link.to/my-files/layername.xml"
    },
    {
      "label": "Download (COG)",
      "uri": "http://schema.org/downloadUrl",
      "source": "http://link.to/my-files/layername.geotiff"
    },
    {
      "label": "Download (JPEG)",
      "uri": "http://schema.org/downloadUrl",
      "source": "http://link.to/my-files/layername.jpeg"
    }
  ]
}

[karenmajewicz]

Several years back we explored using DCAT Distributions. I think it was hard to implement in Solr, but might be more realistic nowadays? Here's what the Distributions section of a record in the Minneapolis Open Data Portal's DCAT API 1.1 looks like:

"distribution": [
				{
					"@type": "dcat:Distribution",
					"title": "ArcGIS Hub Dataset",
					"format": "Web Page",
					"mediaType": "text/html",
					"accessURL": "https://opendata.minneapolismn.gov/datasets/cityoflakes::planning-secondary-zoning"
				},
				{
					"@type": "dcat:Distribution",
					"title": "ArcGIS GeoService",
					"format": "ArcGIS GeoServices REST API",
					"mediaType": "application/json",
					"accessURL": "https://services.arcgis.com/afSMGVsC7QlRK1kZ/arcgis/rest/services/Planning_Secondary_Zoning/FeatureServer/0"
				},
				{
					"@type": "dcat:Distribution",
					"title": "CSV",
					"format": "CSV",
					"mediaType": "text/csv",
					"accessURL": "https://opendata.minneapolismn.gov/api/download/v1/items/a31f298136c04b06886e7c9167b80147/csv?layers=0"
				},
				{
					"@type": "dcat:Distribution",
					"title": "Shapefile",
					"format": "ZIP",
					"mediaType": "application/zip",
					"accessURL": "https://opendata.minneapolismn.gov/api/download/v1/items/a31f298136c04b06886e7c9167b80147/shapefile?layers=0"
				},
				{
					"@type": "dcat:Distribution",
					"title": "GeoJSON",
					"format": "GeoJSON",
					"mediaType": "application/vnd.geo+json",
					"accessURL": "https://opendata.minneapolismn.gov/api/download/v1/items/a31f298136c04b06886e7c9167b80147/geojson?layers=0"
				},
				{
					"@type": "dcat:Distribution",
					"title": "KML",
					"format": "KML",
					"mediaType": "application/vnd.google-earth.kml+xml",
					"accessURL": "https://opendata.minneapolismn.gov/api/download/v1/items/a31f298136c04b06886e7c9167b80147/kml?layers=0"
				}
			],

[thatbudakguy]

re: solr, it shouldn't matter because we just index the whole thing as a JSON blob...right? we're not trying to search or facet on the actual contents of the references field, as far as I know