-
Notifications
You must be signed in to change notification settings - Fork 6
IIIF IDs
A IIIF ID can include almost any character, per the IIIF
spec, but an id by itself has no
meaning to an image server. In order to work for the widest variety of use
cases, RAIS needs ids which are encoded, fully-qualified URLs, or else values
that can be prefixed with the TilePath
setting to point to a local filesystem
resource. Note that even local resources get translated to URLs under the hood
so that RAIS can always operate on a URL for simplicity.
For example, if your TilePath
is /var/local/images
, and an identifier of
foo.jp2
comes to RAIS, the two are joined and RAIS looks for a local file at
/var/local/images/foo.jp2
. Strictly speaking, RAIS receives
file:///var/local/images/foo.jp2
as the URL for the image.
If RAIS receives an ID which includes a scheme other than "file" (e.g.
s3://bucket/path/to/object.jp2
), it doesn't use the TilePath
, and takes the
id to mean an absolute URL to the asset. RAIS only understands file
and s3
schemes right now, but a plugin could be built to accept more.
If an identifier needs to have special characters (particularly slashes, /
,
and pound/hash signs, #
), they must be URL-encoded.
The IIIF spec has specific URL encoding rules which should be adhered to strictly. These rules are necessary so that the part of the URL which define the image ID isn't confused with the parts of the URL which describe what to do to the image (e.g., resize, crop, etc.)
This means if you have an image in /var/local/images/collection1/foo.jp2
, and
your TilePath
is the default (/var/local/images
):
The canonical IIIF ID would be collection1/foo.jp2
, but the encoded ID sent
to RAIS would be collection1%2Ffoo.jp2
.
If using S3, the same situation applies: an IIIF ID of
s3://bucket/path/to/object.jp2
must be sent to RAIS as
s3:%2F%2Fbucket%2Fpath%2Fto%2Fobject.jp2
.