I want to assign a geo bounding box for a map

[glenrobson]

Description

I want to assign a geo bounding box for a map to aid discovery

17-votes in Stanford maps meeting

Variation(s)

(do you know of, or can you imagine, similar use cases?)

Proposed Solutions

(any ideas about how your use case might be supported)

Additional Background

(more about your perspective, existing work, etc. goes here.)

[glenrobson]

Example service on the manifest:

  "service": {
    "@context" : "http://geojson.org/geojson-ld/geojson-context.jsonld",
    "@id" : "http://www.example.org/geojson/paris.json",
    "type": "Feature",
    "bbox":[ -10.0, -10.0, 10.0, 10.0]
 }

[glenrobson]

In production version from @jbhoward-dublin:

Manifest: https://data.ucd.ie/api/img/manifests/ucdlib:256179
Object description: https://digital.ucd.ie/view/ucdlib:256179

Note they have encoded a bounding box like:

"service": [{
    "@context": "http://geojson.org/geojson-context.jsonld",
    "@id": "https://data.ucd.ie/api/geo/v1/dl/geoFilter=bbox(-9.8582479,53.8633133,-9.4400571, 54.0405075)&format=geojson",
    "geometry": {
        "coordinates": [
            [
                -9.8582479,
                53.8633133
            ],
            [
                -9.4400571,
                54.0405075
            ]
        ],
        "type": "Polygon"
    },
    "label": "Bounding box coordinates",
    "profile": "http://geojson.org/geojson-spec.html",
    "properties": {
        "name": "Collins' scribbling diary for 1909",
        "type": "dcterms:Box"
    },
    "type": "Feature"
}]

[azaroth42]

The service needs to be rewritten at this point to use JSON-LD 1.1 best practices and features.

For recipes, they should be 3.0 (per versioning discussion) ... and this is still 2.0 era.
So I'm 👎 that this is ready to have a recipe yet.

[azaroth42]

In particular, the geoJSON service was first discussed and described at the Copenhagen meeting where we renamed metadata to presentation, pre 2.0. So it's not that the recipe or issue is bad, it's that I think there needs to be more work on the basics before jumping into the solution.

For v3, ...

• Shouldn't use embedded contexts, they should be at the top using the scoped context feature
• GeoJSON can be embedded as plain JSON, rather than treated as RDF (ala GeoJSON-LD), meaning that keys won't be misinterpreted, and various features (arrays of arrays) don't turn into crazy nested weirdness
• Distinction between embedded metadata and external service got greatly clarified in 3 (When to use service vs extension vs seeAlso vs annotation? api#1269 --> https://iiif.io/api/presentation/3.0/#service ) whereby services are actual endpoints for something, and extra embedded metadata is just an extension: https://iiif.io/api/presentation/3.0/#46-linked-data-context-and-extensions -- the current 2.0 is the old style melting pot of simply throwing everything under service and not worrying about whether the client should retrieve something separately or process embedded data.

[thehabes]

There is a related issue on this point being discussed in https://github.com/IIIF/api/ at the following link IIIF/api#1246. Perhaps using a service at all for this doesn't make sense. Alternatives are embedded Annotation or an extension like navPlace.

[eliotjordan]

Example JSON for assigning a bounding box to a IIIF resource from the Chronoscope web application:

{	id	: "MxHL28488267",
	title	: "Astygnomon sive Europaearum urbium maxime insignium index. earum distantias mutuas perquam accurate ostendens; G. Valck",
	year	: 1694,
	urlInfo	: 'https://id.lib.harvard.edu/digital_collections/990128376990203941',
        urlIIIF	: 'https://ids.lib.harvard.edu/ids/iiif/28488267/pct:7,10,86,80/',
	corners: [[-14.49770,60.36137],[32.19372,60.34046],[32.13611,37.70058],[-14.39956,37.65459]]
}

https://mprove.de/chronoscope/world-en.html