The navigation system, with its maps, floorplans, wheelchair access information, and virtual tour, required a substantial amount of code development, image translation, and information gathering. This section explains how the major subsystems of the navigational aids were implemented, broken out by subsystem.
Occupancy information (needed for zooming in to rooms) was decentralized to the point of being inaccessible: I resorted to departmental phone lists and ambulatory inspections of the buildings.
The all-campus map was scanned in from a map developed by the Office of Facilities Planning and Management. The Engineering campus map was captured from a map developed by the College of Engineering's Office for Financial Programs. The other area maps were derived from blow-ups of the all-campus map.
It was necessary to do quite a bit more translation to obtain useful floorplans.
To ensure the accuracy of the floorplans, each building was subjected to an on-site inspection. While the accuracy of the floorplan was verified, the locations of bathrooms, department offices, conference rooms, classrooms, elevators, mechanical closets, janitorial closets, photocopiers, computer laboratories, and many other features were also noted.
URL x1,y1 x2,y2where URL is the URL of the page that should be returned if the user selects a point inside the box bounded by coordinates x1,y1 and x2,y2. It would clearly be convenient for the user to be able to click on the image of a floorplan and be given the home page of that room's occupant. It would also clearly be useful to have the room number associated with the coordinates, for use by where_is. The script who_is_in was developed to allow the room number to be attached to the coordinates while still returning the proper home page(s). A level of indirection is employed; instead of the map data file containing lines like
http://www.webfoot.com/ducky.home.html 123,456 321,654the file instead includes lines like
http://www.uiuc.edu/cgi-bin/who_is_in?bldg=grainger&room=451 123,456 321,654A separate data file for each building connects the room number to the occupant's home page with additional information:
ccso 451 http://www.webfoot.com/ducky.home.html Sherwood, Ducky
Note that the image coordinates corresponding to the location of the rooms' walls, need only change when buildings are remodeled. This is usually an infrequent event. The occupancy information, which changes frequently, is arranged by room number. Segregating the rarely changing information from the frequently changing information simplifies maintenance; making the frequently changed information in well-understood terms eases maintenance even more.
The first field gives the "owner" of the room, so that buildings that are shared by more than one academic/administrative unit can be more easily updated. The second field gives the room number. The third field gives the URL of the occupant, and everything past that (a variable-length field) is the name of the occupant.
The script who_is_in determines which data file to use (based on the building name), then searches through it for the appropriate room number. Once that is found, it pulls out the URL and occupant. If there is more than one match for the room number, i.e. there is more than one occupant of a room, then an HTML page is generated with a list of all the occupants, with hyperlinks to each person's home page. If there is only one occupant, then the user is given that occupant's page directly.
If no room is specified, who_is_in notes all the lines and returns a listing of all the occupants in the building, as shown in Figure 12. The perl code for who_is_in is given in Appendix A.
http://www.uiuc.edu/cgi-bin/who_is_in?bldg=grainger&room=451 123,456 321,654From the coordinates of the box bounding the active region, the center point of the room and the radius of a circle containing the room or building can be determined. That information is passed to another script, where_is.gd written by Carlos Pero, which creates a temporary GIF of the relevant image with the appropriate room circled, as in Figure 14.
Note that care must be taken when dealing with temporary GIF files. First, because most browsers cache images, the name must be distinct enough that users are not likely to encounter a second image with the same name before the cache is cleared out. Second, the temporary image must be deleted at some point, but not before the completion of the script. Because most browsers do not download images until the text of a page has been fully downloaded, removing the image too soon will result in the browser not finding the image at all.
If the pixel-to-room data for the requested floor does not exist, or if a room is not specified, the code returns an image of the building circled on the appropriate map, as in Figure 15. Thus authors can link to a room in a building, even if the floorplan information does not yet exist, and give visitors to their pages useful information. When the floorplan becomes available, that hyperlink will switch from showing the building circled to showing the room circled.
In addition to a textual description of the buildings' obstacles, links to the floorplans were used when possible. Thus, the precise location of e.g. elevators could be shown on a floorplan.
Go up to Table of Contents