As a user of a map-based discovery service, I wish to easily view potentially many images exposed via drag-and-drop

[jbhoward-dublin]

Description

In making use of a map visualisation plugin linked to IIIF GeoJSON service statements, I wish to easily select and view the potentially many (potentially hundreds) geocoded images exposed via the map as a discovery tool. For example, a historical map's boundaries may be specified by the GeoJSON data, and the map interface can populate this polygon with geocoded images (or other media) that lie within its bounds.

Resources within the bounding box of an historical map

Drag and drop image from map interface

Proposed Solutions

Deploying a visual map within a client application introduces a form of discovery based on geographic proximity, or inclusion within a geographic boundary. It is a case where exploring an image identified by a user on one basis, leads to potential for further discovery based on (probably) other criteria.

It however also poses issues that relate to user experience and user interface: having potentially very many drag and drop images means that other expectations are raised, such as ease in identifying space to drop the image for inspection, and perhaps also 'lightbox' functionality for arranging images selected. Client functionality that detects draggable IIIF objects and intelligently provides space for them to be dropped is one probable solution; client functionality that allows image containers to be dragged to new locations in a window or tab is another.

[glenrobson]

I wonder when things are Geo data and when things are annotations on an image of a map. Could you have plotted the geo coded images as annotations on the IIIF map?

With our Cynefin data we have land ownership details linked to a geo coord which correspondences to a tithe map. In our current implementation we've converted the geo-coords to image coords and display them as annotations but we've lost the 'geo-ness' of them in the conversion. I don't know if this is similar to your use case but it would be good to express both the annotation targeted on the IIIF map image and also with hard geo coordinates.

[jbhoward-dublin]

Hi Glen, interesting observation, but I think it might be a somewhat different use case. The references in the IIIF GeoJSON service are to a bespoke API providing a query interface to a GIS. The GeoJSON responses are then plotted on a slippy map, and references within the GeoJSON response create linkages to images and other media that reside in the repository. In the example shown, the highlighted area of the map is based on the bounding box of the georectified map.

So we don't lose the 'geo-ness' in plotting objects on a map (a design decision is whether to allow download of the GeoJSON data). Also, we use the IIIF GeoJSON service to express Point and (sometimes) BoundingBox coordinates literally, even though the reference to the remote API is what we make use of in the interface pictured here. So in fact the hard geo coordinates are available in the manifest. (In the example I used, the GeoJSON service is declared at canvas level, since this is a collection of maps.) I copy an example of a GeoJSON service from a map manifest below. I'd be afraid that also expressing this information separately in an annotation would introduce redundancy and, as you say, take us a step away from precisely expressing the spatial data. In the absence of a map interface, annotations seem like an alternative way of expressing associations between places and related information, with the caveat that it requires the transition from geo to image coordinates.

I wonder if this answers your question?

"service": { "@context": "http://geojson.org/geojson-context.jsonld", "@id": "https://data.ucd.ie/api/geo/v1/dl/geoFilter=bbox(-6.255094881758,53.328827608461,-6.240413324562,53.334593236968)&format=geojson", "label": "Bounding box coordinates", "profile": "http://geojson.org/geojson-spec.html", "type": "Feature", "properties": { "name": "City of Dublin", "type": "dcterms:Box" }, "geometry": { "type": "Polygon", "coordinates": [ [ -6.255094881758, 53.328827608461 ], [ -6.240413324562, 53.334593236968 ] ] } }

[jbhoward-dublin]

Just one more thought ... Another obvious use case is displaying a georectified map image as a layer on the slippy map, and then plotting the object references onto that. In this case, the third-party licence for the maps does not allow us to expose the georectified map, otherwise it's something we'd prefer to do.

[mattmcgrattan]

Vatican 2017: in scope for further discussion.