The Database API v6 changes

From University Map Wiki
Revision as of 14:43, 11 December 2012 by dje39 (talk | contribs)
Jump to navigationJump to search

This document briefly lists the changes between version 5 and version 6 of the University Map Database API. See the Full documentation for version 6.




In v5, institution info objects indicated that they should be presented in some related group (as for example the phone, fax and email of a part or function of an institution, like the Box Office details for the ADC theatre, separate form the administrative details), by a repeated (explicit or implicit with a ditto mark) role element.


In v6 this is now explicit using the subsection, subsection-AKA and subsection-end elements. The string value of subsection and subsection-AKA (which differ only in their searchability) represents a sub-heading for the subsection.

A subsection is ended by the start of another subsection or subsection-AKA, and explicit subsection-end element, or the end of the info object.

As well as making the structure much more explicit, this also allows the role of individual elements within a subsection to be included.

Locations and entrances


In v5, the geographical locations and entrances of an institution were returned in the top level institution object as

 locations: [ ... ]
 entrances: [ ... ]

being arrays of location and entrance objects respectively. The relationship of a postal address (an info.address element) was indicated by

 location: i

where i was the (1-based) index of the corresponding location in the locations array. This was cumbersome, and did not relate entrances to locations other than by implication in the structure of their reference numbers.


In v6, location and entrance are removed from the top level institution object and subsumed into the address object.

An address object has at most one location element, which is now a location object not a number, and if there is a location then zero or more entrance elements corresponding to that location. This means postal addresses are directly related to their geographical locations, and entrances directly tied to their corresponding locations.

There may be addresses with no location (either we do not know it, or there is a postal address, such as a PO Box, for correspondence only), and addresses with only a location (we do not know the postal address, or more commonly there is a single postal address and then other locations in separate "address" elements which are to be pinned on a map but which are not for postal correspondence.

Useful code

Though the relationship between addresses, locations and entrances is now explicitly shown, it is nevertheless still useful when processing locations to have them to hand in a single, iterable JavaScript object, rather than dispersed among the addresses.

The following JavaScript function may be useful in creating and caching such a structure. It puts the entrances of a location into the location object and retains an index to the address info object to which the location (and entrances) are related, and both returns and stores this in the top level institution object.

 function get_locations(ji) {
   if (! ji.locations) {
       ji.locations = [];
       if ("info" in ji) {
           for (var ii in {
               var info =[ii];
               if (info.type != "address") { continue; }
               var icurloc = -1;
               for (var ia in info.address) {
                   var address = info.address[ia];
                   if (address.type == "location" && address.location != null) {
                       icurloc = ji.locations.push(address.location) - 1;
                       ji.locations[ji.locations.length-1].entrances = [];
                       ji.locations[ji.locations.length-1].iinfo = ii;
                   } else if (address.type == "entrance" && icurloc >= 0) {
   return ji.locations;