How does a Library relate to the Real World?

If we want to find a book (in the spatial sense we're talking about in this project), let's assume we start from somewhere in the known physical universe (a fairly safe assumption).

Let's look at some other assumptions we can make, and assess how safe each is, or what caveats (i.e. restrictions to functionality generated) we need to add to them.

A first pass of requirements at how a location should be indicated elicited the requirement (from one of our Library IT Team colleagues) that "the top priority requirement [for the LibraryLocator] is that the orientation of arrows on the map can be controlled - so they don't obscure text or other details". I'd question whether this is really the "top" priority - either for end users or for the librarians who will need to edit this data (for each of the assumed <=5,000 distinct shelf-bay locations that are likely to be our maximum resolution).

We have problem of deciding how a location can be recorded just once, and then displayed on a variety of background plans which may be at different scales (to suit display on different end-user devices etc), different orientations (of text on a plan) and different levels of detail.

A long lunch in the Senior Dining Room (lamb tangine with cous-cous and preserved fruits) yielded the diagram above and the realisation that the best sort of coordinates to use will be those of the real world.

Whenever a plan is imported to the LL (this shouldn't happen very often, and there are only likely to be <=20 of them), it needs to have metadata added (either in standard internal JPEG/PNG fields, or in an external registry file/table of known plans). This metadata for all plans can be read in just when the LLmapdisplayer initialises (not for every search) and should include:

• the real-world Lat-Long of the bottom-left corner of the plan graphic;
• the real-world Lat-Long of the top-right corner of the plan graphic (both so that orientation of the plan is sensible when displayed w.r.t. text/symbols shown);
• the X,Y dimensions in pixels of the plan graphic (we assume all graphic files are rectangular).

When a plan is imported, the LLeditor must allow this to be done reasonably easily (there are only about 20 of them and they don't change often). In v1 it would be acceptable to expect a user to click two points on the plan, and locate the corresponding points on the building as depicted by GoogleEarth, copy-pasting in the Lat-Long values. (A smarter v2 may be able to use a GoogleMaps API to capture the values, or even allow positioning/rotation/scaling of the plan image overlaid on GoogleMaps to align with the real-world features - OutOfScope for now!)

When an arrow (or whatever appropriate location indicator graphic - also a rectangular image) is placed, the LLeditor must allow this to be done very easily (there may be 5,000 of them!). It must allow a hot-spot (e.g. arrow-point) to be positioned, and then allow for the arrow graphic to be rotated around the hot-spot point. The location and orientation of the arrow should each be recorded by translating into real-world coordinates (Lat-Long and compass bearing) so they're effectively absolute. They can then be rendered by the LLmapdisplayer using any background plan. If an editor-user chooses an orientation for the arrow which clashes with some other background plans, that's OutOfScope for now too.

A little experimentation with Google maps and at http://pagesperso-orange.fr/universimmedia/geo/loc.htm (to pick one site from a quick search) was in order. Searching for Portugal Street London makes it easy  to view the LSE library (if you know which building it is!) and find the latitude and longitude of the corners of the building, to five decimal places (lat 51.51473, long -0.11641; lat 51.51494, long -0.11563 for the western and northern corners respectively). This would give a resolution of about 60x130 for a map which has a pixel for each square corresponding to the least significant digit produced, clearly not enough for our purposes. But Google maps will at least accept more places of decimals, so as long as the initial processing of the map graphics is done more carefully, it should be possible to get higher resolution numbers for the corners, and so to place a pointer more accurately in a range of maps with different edges.