Our first testable software

We now have our first working software. This is the map display component; it runs both as a servlet and as a command line application (which produced the image on the left).

This interface will retrieve one from a specific group of maps and mark a location on it. The generic URL for a map with a pointer displayed will be http://findmylibrarybook.in/library/mapgroup?location=longitude,latitude&bearing=angle-in-degrees&resolution=string-which-matches-a-filename.

Here, "mapgroup" indicates a collection of maps (e.g. "first-floor", "SouthLondonCampus"), location indicates the position to place the pointer in latitude and longitude, bearing the number of degrees from true north to rotate the pointer graphic, and resolution the particular map to choose from the collection, in this case "mapgroup-high.extension" - the application will cope with a number of extensions and corresponding file formats, but will choose the first matching one if there are identically named files but for the extension.

We have some test URLs to see a variety of behaviour of the servlet, including the expected errors from incorrect URLs (e.g. specifying a non-numeric latitude or orientation). Note that these are not guaranteed to continue to work, as we refine the software. Further work clearly needs to be done to refine the display of the arrow (persuading the Java JAI that the rotated image should be surrounded by a transparent rather than a black background). The map graphics used come from OpenStreetMap and from the LSE hosted archive of the Booth maps of poverty in London at the end of the nineteenth century.

Note: The links below have been updated to reflect the new working location of the test locator (there were java versioning problems in the old location which prevented the servlet working properly). The new location does not have a commercial web server certificate but will only accept external connections via https, so access will require the user to accept a self signed certificate (i.e. one which a web browser will flag as invalid).

Firstly, https://far-project.lse.ac.uk/LibraryLocator/DisplayMap/lse-campus?resolution=openstreetmaplibrary&;location=51.514532,-0.117057 should place arrow pointing due north.

Rotate arrow to each quadrant

https://far-project.lse.ac.uk/LibraryLocator/DisplayMap/lse-campus?resolution=openstreetmaplibrary&location=51.514532,-0.117057&bearing=35

https://far-project.lse.ac.uk/LibraryLocator/DisplayMap/lse-campus?resolution=openstreetmaplibrary&location=51.514532,-0.117057&bearing=162

https://far-project.lse.ac.uk/LibraryLocator/lse-campus?resolution=openstreetmaplibrary&location=51.514532,-0.117057&bearing=223

https://far-project.lse.ac.uk/LibraryLocator/DisplayMap/lse-campus?resolution=openstreetmaplibrary&location=51.514532,-0.117057&bearing=309

Different maps

https://far-project.lse.ac.uk/LibraryLocator/DisplayMap/lse-campus?resolution=openstreetmapclose&location=51.514532,-0.117057&bearing=162

https://far-project.lse.ac.uk/LibraryLocator/lse-campus?resolution=openstreetmapmedium&location=51.514532,-0.117057&bearing=162

https://far-project.lse.ac.uk/LibraryLocator/DisplayMap/lse-campus?resolution=openstreetmaplarge&location=51.514532,-0.117057&bearing=162

Errors

This should display map with no arrow (because the requested position is off the map): https://far-project.lse.ac.uk/LibraryLocator/DisplayMap/lse-campus?resolution=booth&location=51.514532,-0.117057&bearing=162

This should return 404 not found (no map file of that name): https://far-project.lse.ac.uk/LibraryLocator/lse-campus?resolution=openstreetmaplibrary&location=71.514532,5.117057&bearing=309

This should return 503 (because location doesn't make sense): https://far-project.lse.ac.uk/LibraryLocator/lse-campus?resolution=openstreetmaplibrary&location=71.gdsryer514532,5.117057&bearing=309

CampusM at LSE

A secondary objective of the Library Locator project is integration on mobile devices with the CampusM service, for which LSE has contracted with oMbiel.

This launched on Apple iPhones only, but is now available in a generic 'mobile web' version at http://lse.ombiel.co.uk. (It will reject access by browsers identified as 'not mobile devices'. Either try this on a mobile browser, or use User Agent Switcher or similar to fool it into talking to your big browser.) Proper apps for Android and Blackberry are forthcoming.

Further information about CampusM is at http://www.ombiel.com/campusm.html

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.

How Can We Find a Library Book?

This is the fundamental question which we need to answer to carry out this project. We have assumed that the best way to do this is to take a unique ID for the book (or other item held by the library) and obtain the information need to find it from the LMS system database. But...

1. Different libraries use different LMS products. So the information is found in the same place: different queries will be needed depending on the product used.
2. Even if two libraries use the same LMS, their holdings may be organised differently. For example, one library might have two items with the same classmark which are in different locations because of their acquisition date, while the acquisition date might be totally irrelevant in another library. So the information needed to find an item is not necessarily the same, even when the library system is the same.
3. Even if two libraries organised their holdings in identical fashion, their different holdings might still require different information. For example, in the LSE library, paper archives of academic journals are organised by the classmark which represents the scope of their contents, so that journals which cover all of economics need to be given the Library of Congress classmark H (this covers the whole of the social sciences, but a journal can't be given the classmarks HB-HJ, all of which cover subjects which could be seen as sub-divisions of Economics as a whole. This means that the journal title is needed to narrow down the location to a single bookcase. But with a library which doesn't have such extensive journal holdings within a particular subject area, this might well not be necessary.
4. Even if two libraries organised their holdings in identical fashion, their cataloguers might enter data into the system in different ways. LMS databases are complex, and decisions have to be made as to where particular information should be stored.

This is a potential minefield, if we want the locator software to be reusable. The difficult thing is to design a database structure which is sufficiently general and at the same time comprehensible to be managed (so that just having tables for "field1", "field2", etc. is not sensible).

There are, in the end, five database fields whose values are sufficient to determine location (to the level at which the locator will operate) in every case (though they are not all needed for some items). Using English language labels rather than the actual column names, we have, in approximate order of specificity:

• Location In the LSE's LMS database, the "location" field is rather overloaded, as it contains information which is not location related (e.g. "Main collection - normal loan": though the collections contain items with different loan lengths depending on anticipated use, these are all shelved together).
• Item type Journals, books, theses, DVDs, and other media types may well share classmarks and yet be shelved separately. Of course, they may also be shelved together - CDROMs are shelved among the books at the LSE library.
• Item status This is needed to determine whether the item is on the shelve, or on loan, lost, or requiring a fetch service. In most of these cases, displaying the location is beyond the scope of the locator - but the locator will need to know what to do about it (e.g. offer a link to a reservation form) if asked.
• Classmark Probably the most important single piece of information for determining the location. Usually LOC, but there are also some local schemes (theses, official publications, etc.).
• Title As mentioned above, this is needed for some journals. 

I now define a collection to be "a set of items such that two items which share the same classmark will be shelved together". This is just so I can use a convenient word for this, and despite the fact that I have been told that this doesn't necessarily equate to what a librarian would mean by a collection. (If you have a better idea for the name to use, let me know!) Then the five fields which determine the location of an item can be divided into those which determine the collection containing the item (the first three) and those which specify the location of an item in a collection (the remaining two).

It seems likely that this division will be possible for most, if not quite all, academic libraries, whatever the information which needs to be placed in each category: the fields will often be different, but the two groups of fields will still be definable. So the proposed solution to the problems of the undefinable nature of the database fields to use is this:

In order to find an item, obtain the field values which make up the two location defining groups of fields. Order them (in a vague way) in terms of specificity: this will make it easier to find the required items. Concatenate these values (with a certain amount of abbreviation, which should be configurable). The two long strings should then uniquely define the location of the item, to the level of a bookcase, so a lookup table simply checks these two strings, and takes the longest match from the table to define the location. (Which means in practice that the title will be ignored unless needed, and that shorter versions of classmarks can be used to define larger areas if this is considered desirable.)

 Is this the answer? It's certainly rather messy, but should prove both portable and lightweight. It will make updating more difficult, because exact versions of the various strings will be needed to specify the location. This could be overcome by an interface for administration which allows the user to specify the location of a single item, and then fuzz the item information, by deleting parts of the concatenated strings obtained for the item from the LMS database or using wildcards, to indicate that the same location should be used for other items with similar information stored by the LMS.