To previous section


Examples of GIR on the InterNet

Indexing texts and other geo-referenced objects (such as photographs, videos, remote sensing data sets, etc.) by coordinates permits the use of the hypermap concept, as discussed above. Use of coordinates also provides the capability of using a graphical interface to the information in the database or Digital Library, where representations of the objects are displayed as icons or footprints on a digital map. As suggested above, a map-based graphical interface has a number of advantages over one which uses text terms or which simply uses direct specification of coordinates. It has been suggested that different cognitive structures are used by people in dealing with graphical and spatial information than those used for verbal information (Jones & Dumais, 1986), and that spatial queries cannot be adequately expressed by verbal queries (Furnas, 1991). Geographical queries are inherently spatial, and a map-based geographical interface tends to be intuitive and comprehensible to anyone who is somewhat familiar with maps and geography. Morris (1988) suggests that when users are given a choice between menu (text-based) and map-based graphical interfaces to a geographic database, they prefer the maps. A graphical interface, including digital maps and hypermaps, also permits dense presentation of information (McCann, Taylor & Tuori, 1988; DiBiase et al., 1993).

In this section we will examine some examples of GIR and spatial browsing that are currently available via the World Wide Web (WWW). This "state-of-the-art" survey is by no means a comprehensive review of such systems, but provides some examples to illustrate the concepts of GIR and spatial browsing as they have been implemented in current systems. The URL addresses of the systems discussed are indicated in square braces.

Figure 10 shows a hypermap from the UC Berkeley Environmental Digital Library prototype [http://elib.cs.berkeley.edu](Wilensky, et al., 1994). The base map shows the San Francisco Bay Area, and overlaid on the base map are three boxes showing the footprints of related hypermaps. Clicking a mouse button over the leftmost box brings up the more detailed map shown in Figure 11. Each of the labelled boxes overlaid on Figure 11 represents an aerial photograph (each image is actually a composite of digital remote sensing data acquired from an airborne platform) taken in order along a particular flightline. Clicking on the box marked 1-4 retrieves the image for the area centered under the box, as shown in Figure 12. The arrows above the image in Figure 12 permit the user to "navigate" up and down the though the images in a particular flightline, and left and right to images in parallel flightlines. In this prototype browser, the database is limited, and the maps are static entities. In the interface planned for the Digital Library, maps that can be scrolled and that provide the ability to "zoom" in and out will be used. A much more complex example of this type of hypermap access to information resources (jumping from static map to static map and eventually to data of interest) is provided by the "Virtual Tourist" system of the WWW, that provides access to WWW servers by geographic location [http://wings.buffalo.edu/world/].

An example of the ability to scroll about and zoom in and out in a dynamic digital map is provided by the prototype version of the US Bureau of the Census' TIGER Mapping Service (TIGER stands for Topologically Integrated Geographic Encoding and Referencing system, which was developed to support the activities of the Census Bureau starting with the 1990 census). Figure 13 shows a page from the TIGER Mapping Service prototype [http://tiger.census.gov/] that is centered on the New York City area. Using the four "arrows" surrounding the map, the user can move the view (pan or scroll) left or right, up or down.

The "zoom in" and "zoom out" buttons provide reduce or increase the scale of the map displayed. Figure 14 shows the results after "zooming in" on the area of Central Park. In Figure 14, much more detail (such as individual streets) is shown, and the legend has been changed to reflect the types of information that might be visible at the current scale. As noted on the WWW pages shown in Figures 13 and 14, the map that is shown is generated "on-the-fly" from the underlying TIGER digital mapping database. This means that instead of a static map (such as that in the Digital Library prototype discussed above) the maps in the TIGER Mapping Service are created on demand, in response to a user's mouse click on one of the scrolling or zooming button.

Figures 15 and 16 show an example of a full-scale geographic information system being made available via the WWW. The GRASSLinks system [http://www.regis.berkeley.edu/grasslinks/], was developed at UC Berkeley by Dr. Susan Huse as part of her Ph.D. work (Huse, 1995). It uses the GRASS (Geographic Resources Analysis Support System) GIS developed by the US Army Corps of Engineers, with an interface tailored to simple access over the WWW. Figure 15 shows part of the page that permits the user to specify the contents of the map desired, and

Figure 16 shows the map generated by GRASSLinks (in this case fairly simple simple map showing the counties of the San Francisco Bay area). GRASSLinks, like the TIGER system, allows the user to zoom in or out on particular areas, but it adds the additional capability to query the underlying geographic datasets and display values (using a point-in-polygon search to identify the characteristics of an area surrounding a user-selected point), as well as to overlay multiple types of geo-referenced data (ranging from data from the National Wetlands Inventory to geological maps of the San Francisco Bay area). A similar WWW interface to a somewhat less sophisticated GIS was developed for Canadian National Atlas data [http://ellesmere.ccm.emr.ca/naismap/naismap.html].

Not all GIR systems on the internet support graphical searching (at least at the present time). For example, the US Geological Survey node of the National Geospatial Data Clearinghouse [http://h2o.er.usgs.gov/nsdi/](part of the National Spatial Data Infrastructure (NSDI) effort by the Federal government) has a GIR system for identifying relevant data sets that permits users to specify their requirement by both keywords and by specifying the latitude and longitude coordinates of a bounding rectangle for their area of interest (Nebert, 1995).

A wide variety of other geographically referenced (or related) information sources are available via the internet. One of the best clearinghouses providing pointers to such information is the US Geological Survey "Geographic Information Referral Page" [http://waisqvarsa.er.usgs.gov/wais/html/geog.html].

Many of the network based systems discussed above have some significant problems resulting from current technological limitations. One problem is that the time required for generating and transmitting maps such as those used in the TIGER Mapping System and the GRASSLinks system is much too long for convenient interactive use. Scrolling and zooming in the TIGER prototype may take as much as a minute to display the response to a single mouse click. In addition, the current version of the HTTP protocol and HTML "map widgets" used in the WWW for these systems, have no way of transmitting continuous information from mouse movements, or from multiple mouse selections of points on a map. This makes it impossible for current versions of WWW clients, such as Mosaic and Netscape, to have the users interactively draw a bounding rectangle or polygon over the area they are interested in order to submit a region query. Although support for such interaction is promised in the next version of HTTP, there are other problems with the HTTP protocol for use in information retrieval, including in GIR systems. The primary drawbacks are that the protocol is "stateless", meaning that each transaction between a client and server is treated as a completely distinct event, and the server keeps no information about clients from transaction to transaction. Some systems have finessed this limitation by adding state information to the query sent to the server, but these tends to be server-specific extensions to the protocol without standardization between servers.

There are other standard protocols, such as the Z39.50 information retrieval protocol (NISO, 1992), where the server does maintain a connection with the client, and which are better oriented to conventional information retrieval tasks. The National Geospatial Data Clearinghouse mentioned above is currently using the WAIS protocol based on an earlier version of Z39.50, and is moving to a full Z39.50 implementation, with support for map browsing and bounding box selection (Nebert, 1995). Z39.50 is also being used for spatial indexes for the Government Information Locator Service [http://www.usgs.gov/gils/]. In the following section we describe a toolkit for building geographical browsing interfaces that also provides Z39.50 access to remote servers of geographic and geo-referenced information. Another possible solution is the Java programming language which permits Java-compatible WWW browsers to download and execute interactive programs (von Hoff, 1995).

Figure 10: Hypermap from the UC Berkeley Digital Library Prototype.

Figure 11: Detail map from the UC Berkeley Environmental Digital Library Prototype

Figure 12: Aerial Photograph from UC Berkeley Environmental Digital Library

Figure 13: US Census Experimental TIGER Mapping System--New York Area

Figure 14: US Census Experimental TIGER Mapping System--New York Area zoomed

Figure 15: GRASSLinks specification page.

Figure 16: GRASSLinks Map Display

Geographic Browsing Toolkit

Most Geographic Information Systems were designed to support the work of cartographers, city and regional planners, and others with a need to create maps. As such they tend to be "heavy-weight" systems that often have a monolithic structure, proprietary data formats and a tendency to be very complex to use. As such, these systems are ill-suited for applications where a user wishes to simply use spatial browsing to examine a variety of geo-referenced information.

In this section we will examine the features of a toolkit for constructing such browsing interfaces developed by the author that provides a simple solution to rapid development and presentation of geographical information retrieval systems. We will first look at a bit of background on the toolkit and then describe one application using it and how a user might interact with that application. This is followed by a more detailed discussion of the toolkit contents.

In the Sequoia 2000 project, which was concerned with the design and development of very-large-scale information systems for Earth scientists studying global change phenomena, a new browser paradigm was proposed to provide access to database information using a spatial paradigm (Chen, 1992). In this system, now called Tioga (Stonebraker, Chen, Nathan, Paxson & Wu, 1993), information is displayed topologically according to continuous characteristics which are attributes of the data. For example, documents may be displayed on a map according to their latitude and longitude. Documents might also be displayed according to the time at which they were generated and the time to which they refer, as well as by more abstract functions such as the reading level of the document, the author's attitudes as expressed in the document, etc. A prototype of the geographical browsing component for Tioga was developed by the author and included in the Lassen Geographic Browser (shown in Figures 17-19) as part of an interface for document retrieval that included both known item searching and probabilistic retrieval based on document contents (Larson, 1994). The current version of the geographic browser toolkit is a revised and refined version of the Lassen browser.

Using the Lassen browser, any geo-referenced object in the database can be indicated by an icon on the map. The user employs the mouse to center the map on any location and to zoom in or out for more or less detailed maps, either by clicking on the map with the mouse, or by moving the scroll bars below the map to set particular coordinates and zoom levels. With local processing handling all map drawing and updates, the Lassen Geographic Browser is fast enough to redraw the entire world map in less than a second. When zoomed in on a location map updates are faster due to hidden line clipping. At reduced levels of detail, the browser can redraw the screen fast enough to provide an animated "real-time" zooming and scrolling effect. Icons can be placed at any coordinates on the map and for any range of "zoom" values. The icon will only appear when the coordinates are visible and the current "zoom" level is within the specified range. This helps to reduce clutter on the screen. Clutter is further reduced by placing references to multiple objects that deal with the same area into a pop-up menu. When an icon is selected by the user, the menu of objects geo-referenced at the icon coordinates and detail level are displayed for selection.

In Figure 17, a the initial global view of the Lassen browser is shown in a typical X window system display window. By clicking with the left mouse button on the United States, the map was centered on that, clicking the middle mouse button zooms in one unit (and the right mouse button zooms out). The units used in zooming are logarithmic, so that zooming from a global scale to the scale shown in Figure 18 requires only a single mouse click, but as the view "closes in" more clicks are needed to increase the zoom by the same amount. The convention adopted for displaying icons in this version of the browser, is that the underlying objects represented by the icons should represent geographic coverage approximately equal to the area shown in the map window. In Figure 18 a single icon is shown as a small box in the center of the U.S., when selected a pop-up menu listing data objects associated with the entire area visible, including such things as satellite images of the entire region shown. Select an object from the menu invokes a viewer appropriate to the type of data (the Lassen prototype shown here included geo-referenced texts, images in a variety of formats, and MPEG videos). Figure 19 shows a "closer" view centered on Southern California. In this window, the "place names" button was selected to show the names of cities in the visible area (the prototype uses a small gazetteer of international city names, which is not very accurate as to geographic location). When a user enters a place name at the bottom of the screen, the name is searched in the small international gazetteer, and in a much more comprehensive and detailed U.S. gazetteer. When a name is found, the map is centered on the referenced location, and zoomed to intermediate scale with the name displayed.

Figure 17: Lassen Browser--Global View

Figure 18: Lassen Browser--Centered and Zoomed on U.S.

Figure 19: Lassen Browser--Further zoomed to Southern California with Place Names activated.

The Lassen prototype browser shown in Figures 17-19 uses the geographic browser toolkit to display and manipulate the map information shown in the main window. The toolkit has been developed as an extension to the Tcl/Tk language (Ousterhout, 1994) developed to provide the ability to create interactive scripts for applications. The toolkit shares all of Tcl/Tk's ability to simply construct X window-based interfaces using simple commands. For example, to create the map shown in the main window only required one statement in a Tcl script:

map .mp.win1.mapwin -mapfile map.data -width 7i -height 3.5i

-detail 4 -aspect 100

This statement starts with the "verb" map that indicates a request for a new map "widget" (the term used in Tcl/Tk for all interface elements such as sliders, buttons, and text entry boxes). The verb is followed by the name to be used for the widget window created. Tcl/Tk uses an object-oriented style of object creation, with all subsequent operations on an object treated as commands where the "verb" is the name of the object involved, called "widget commands". In the statement shown above, the widget name is followed by a number of options specifying some characteristics of the map. The -mapfile option indicates the file name of where the map data is located. The browser currently uses data in a compressed format derived the World Data Bank II data set originally created by the Central Intelligence Agency and released to the public domain. Additional formats are planned for support of such things as TIGER map data. The next options in the command above (-width and -height) provide the dimensions of the widget and may be specified in inches, centimeters, millimeters, printer's points, or screen pixel units. The -detail option indicates how detailed the map drawing should be, ranging from 1, representing the highest detail available, to 5 indicating that only about 1/5 of the detail will be displayed. The -aspect option is used to correct the appearance of map when zoomed in at high and low latitudes (the map widget uses a cylindrical projection, so there is a "spreading out" of features when drawing high and low latitudes). There are an number of additional options that can be specified in the map command, these include:

1. Latitude and Longitude for the centerpoint of the display, these default to 00'0"N and 00'0"W.

2. Zoom to specify the level of detail to be shown.

3. MapBackground to specify the color of the window background (default is black).

4. Coastlines to specify the color of continental coastlines (default is green).

5. Countries to specify the color used for national boundaries (default is red).

6. States to specify the color used for states in the US and for international zones (default is yellow).

7. Islands to specify the color of island coastlines (default is light green).

8. Lakes to specify the color of lake shorelines (default is light blue).

9. Rivers to specify the color of river shorelines (default is blue).

Any of these options can be changed after the initial creation of a widget using the map command by using the configure "widget command". For example, to change the color of the coastlines displayed from green to violet in the map widget created above (named .mp.win1.mapwin), the command:

.mp.win1.mapwin config -coastlines violet

could be issued in a script. In addition, multiple map widgets can be used in an interface. In Figure 20, for example, an interface with two map widgets is shown. The main map widget is the primary display, while the smaller widget is used to move the view of the main map widget to center on a point "clicked" in the small widget. Additional widget commands are used for a variety of operations such as recentering the view of an existing map widget. These widget commands include:

Figure 20: Map Widget Example, with overlays.

1. CenterPixel - this tells the widget to redraw itself centered on the point indicated by xy pixel coordinates of the window supplied as an argument.

2. Display or ReDisplay - causes the widget to re-draw itself immediately.

3. ZoomMap - Zooms in or out of the current map display to the "zoom value" supplied as an argument. This can be an absolute value or an increment to the current value (indicated by a plus sign) or a decrement to the current value (indicated by a minus sign).

4. GetCenter - this asks the widget to report the current latitude and longitude of the center of the map display.

5. GetFrame - this asks the widget to report the current latitudes and longitudes of the top-left and bottom-right corners of the map display.

6. GetLatitude - this asks the widget to report the current latitude of the center of the map display.

7. GetLongitude - this asks the widget to report the current longitude of the center of the map display.

8. GetLatLon - this asks the widget to report on the latitude and longitude of a point indicated by xy pixel coordinates of the window supplied as an argument.

9. GetXY - this asks the widget to report on the xy pixel coordinates of the window that represent the location specified by a latitude and longitude supplied as arguments.

In addition to these widget commands, there are three others: Create, Destroy, and Rubberband. Create creates a geometric object and places it in the map at the geographic coordinates specified in the create command it also returns a unique identification number for the object. The Destroy command takes an object's identification number as an argument and removes the object from the display and from memory. The Rubberband command functions the same as a create command, but permits dynamic changes to the coordinates of the object that is displayed. It is intended for interactive drawing of objects to show, for example, a rectangle that "stretches" over the base map following mouse movements until the mouse button is released. A Rubberband command with the single argument "end" finishes the interactive drawing of and object, automatically connecting the final point of a polygon with its start point. Each object created remains attached to the geographic coordinates specified in the create command, so that scrolling the display, or zooming in or out, will redraw the object appropriately. There are several types of objects supported in the current version of the map widget, including:

1. point - a single point indicated by latitude and longitude.

2. line - a straight line defined by the latitudes and longitudes of its end points.

3. rectangle - a rectangle defined by latitudes and longitudes of its top-left and bottom-right corners.

4. filledrectangle - a rectangle defined by latitudes and longitudes of its top-left and bottom-right corners, and filled with a transparent color.

5. polygon - an arbitrary polygon defined by a set of latitudes and longitudes of each vertex, and filled with transparent color.

6. polyline - an arbitrary set of connected line segments defined by a set of latitudes and longitudes of each vertex, and filled with transparent color.

Circles, ovals and arcs are not supported in the current version, but support is planned for the future. The color of each object is specified in its create statement. These colors, like all colors in Tcl/Tk can be specified using X color names, or by specifications of color values as 4-bit, 8-bit, 12-bit or 16-bit hexadecimal values for the Red, Green, and Blue components of the color, Most X window servers have a rich variety of color names (e.g., BrickRed1, LightSkyBlue3, NavajoWhite1, SeaGreen2) including all common color names like Red, Green, Black, and so on. For example, the following statements were used to create the objects shown on the main map in Figure 20:

.map create line white 0o0'0''N 179o0'0''W 0o0'0''N 179o59'59''E

.map create polygon white 50o0'0''N 0o0'0''W 0o0'0''N 50o0'0''W 0o0'0''N 50o0'0''E 50o0'0''N 0o0'0''W

.map create polygon blue 23o0'0''N 120o0'0''W 24o0'0''N 120o0'0''W 25o0'0''N 22o0'0''W 20o0'0''N 122o0'0''W 23o0'0''N 120o0'0''W

.map create polyline yellow 23o0'0''N 120o0'0''W 24o0'0''N 120o0'0''W 25o0'0''N 22o0'0''W 20o0'0''N 122o0'0''W 23o0'0''N 120o0'0''W

.map create point white 23o0'0''N 120o0'0''W

.map create rectangle red 50o0'0''N 70o0'0''W 10o0'0''N 20o0'0''W

.map create filledrectangle violet 55o0'0''N 75o0'0''W 5o0'0''N 15o0'0''W

Note that latitude and longitude are expressed in the conventional degrees minutes' seconds" direction (N, S, E, W) format, slightly adapted to permit entry on an ascii keyboard (lower case o is substituted for the degree symbol). The toolkit also contains conversion routines to convert a variety of geographic coordinates into latitude and longitude.

Naturally, additional statements other than the one shown above are required to group and arrange the elements of the interface, and to specify the characteristics and behavior of the other interactive elements on the screen, but Tcl/Tk handles a surprising amount of this work automatically. Any widget type, including maps, can have actions bound to X window events, such as mouse movement or mouse button presses, keystrokes, window movement, etc. For example, the Tcl statements:

bind .map <1> "%W centerpixel %x %y"

bind .map <2> "%W zoom +1.0 ; inczoom"

bind .map <3> "%W zoom -1.0 ; deczoom"

attach particular actions to mouse buttons 1, 2, and 3 when clicked on the map widget called .map. The current window name is substituted for %W by the bind command, and the current mouse xy location in window pixel units is substituted for %x and %y, in the statements shown. Thus, the first line above sets up the map widget so that the view is centered on the point indicated by the current mouse position whenever mouse button 1 (the left) is clicked on the map widget. The next lines attach zooming in and out to the middle and right mouse buttons, respectively. Any arbitrary Tcl/Tk script can be included as the last element of the bind command. In the last line above, there are two Tcl statements, the first handles is the zoom widget command and the second is an invocation of a script procedure named "deczoom" that handles updating the other widgets on the screen (such as the "Zoom Value" slider widget) to reflect the new zoom value. Any other Tcl/Tk widgets, such as buttons, text or graphical labels, menus, scales and scroll bars can be placed anywhere on the map display (using the GetXY widget command to convert Latitude and Longitude to the appropriate pixel location on the map display). These other widgets can also have any arbitrary script attached to them.

Tcl/Tk and the geographic browser toolkit provide a convenient and flexible way to prototype and implement user interfaces for geographic information retrieval and spatial browsing applications. It is being used in an updated version of the Lassen geographic browser, and is also being included in the Cheshire II next-generation online catalog system (Larson, Moon, McDonough, Kuntz, O'Leary, in press). Planned additions to the toolkit include more map data formats, ability to express coordinates in a larger variety of coordinate systems (e.g., Universal Transverse Mercator) and formats (e.g., Latitude and Longitude expressed as positive or negative decimal degrees instead of degrees, minutes and seconds).

Conclusions

Digital Libraries are multimedia information systems that will include digital "documents" in a variety of formats. In the Environmental Digital Library being constructed at Berkeley (Wilensky et al., 1994), we are building a digital collection that includes text documents such as Environmental Impact Reports, County General Plans, magazines and publications of the California State Resources Agency in both scanned page images, ASCII text form from Optical Character Recognition, and a number of other forms. The collection also includes scanned 35mm slides of places in the State of California from a collection of over 500,000 (with about 10,000 converted to digital form at the present time), and videos produced by State agencies. In addition, USGS topographic data, U.S. Census TIGER data, the contents of a large-scale GIS for the San Francisco Bay Area, and collection databases for classification and distribution of California flora and fauna. All of this data, in one way or another, has a geographic component to be considered in indexing and retrieval. We believe that geographic browsing will play a key role in providing effective access to this information, permitting scholars, scientists, government agency personnel, librarians, and students to quickly and easily find and retrieve the information they need for tasks ranging from research to environmental planning. To implement such a Digital Library and make it available to such a user population, a number of important research and development questions need to be examined. These include:

1. Is it possible to create a coherent content-based view of such a diverse collection of digital objects? Geographic Information Retrieval and Spatial Browsing, as discussed in this paper, can provide at least one coherent framework within which to coordinate many disparate resources in such a system.

2. How large can such a Digital Library be and still provide efficient and effective access to its contents? That is, how well do all the components of the Digital Library scale up in size from small prototypes to multi-terabyte databases with hundreds of simultaneous users.

3. How can the contents and indexes of a Digital Library be distributed amongst many different computers over a wide-area network, and still provide coherent and comprehensive access to its contents?. How will such distributed systems communicate and share information, and how will they communicate with other Digital Libraries and databases? How can such large amounts of data be transmitted most effectively and efficently?

4. How will information be added to the Digital Library, what forms will these documents take, and how will content and characteristics of the documents be defined? Can these processes be automated and how effective will such procedures and techniques be in providing access to the collection. There is much work to be done on effective automatic indexing and classification for both full-text documents and the other sorts of digital objects included in the Digital Library.

5. What are the modes of interaction with the Digital Library? As suggested above, GIR and Spatial Browsing will play a large role. But more conventional information retrieval and DBMS querying techniques will also be required.

These open research questions hint at the outlines of the research being conducted in support of the development of Digital Libraries. The Berkeley Digital Library Project and the Alexandria Digital Library Project at U.C. Santa Barbara (Frew et al., 1995) have adopted a geographical information retrieval approach as one of the primary interaction paradigms for Digital Library access. We are just beginning research into the problems, effectiveness, and usability of geographic information retrieval and spatial browsing, but I believe that a GIR and Spatial Browsing paradigm will provide an elegant and comprehensible method of interaction for a wide variety of users and needs.

Acknowledgements

Some of the research described here, including GIPSY and the Lassen prototypes was sponsored by the University of California and Digital Equipment Corporation as part of the Sequoia 2000 project under DEC Research Grant #1243. Current work on GIPSY and the browser toolkit are being carried out under the auspices of the U.C. Berkeley Environmental Digital Library Project sponsored by NSF, NASA and ARPA.

REFERENCES

Anderson, J. R., Hardy, E. E., Roach, J. T. & Witmer, R. E. (1976). A land use and land cover classification system for use with remote sensor data. Geological Survey Professional Paper. Washington : USGS.

Brimicombe, A. J. (1993). Combining Positional and Attribute Uncertainty Using Fuzzy Expectation in a GIS. In GIS/LIS Proceedings, (pp.72-81). Bethesda, MD : American Society for Photogrammetry and Remote Sensing, American Congress on Surveying and Mapping.

Chen, J., Larson, R. R., & Stonebraker, M. (1992). Sequoia 2000 object browser. In Digest of Papers. COMPCON Spring 1992. Thirty-Seventh IEEE Computer Society International Conference, (pp. 389-394). Los Alamitos : Computer Society Press, 1992.

De Floriani, L., Marzano, P. & Puppo, E (1993). Spatial Queries and Data Models. In A. Frank & I. Campari (Eds). Spatial Information Theory: A Theoretical Basis for GIS. (Lecture Notes in Computer Science # 716). Berlin: Springer-Verlag.

DiBiase, D., Reeves, C., MacEachren, A. M., Krygler, J. B., von Wyss, M., Sloan, J. L. & Detweller, M. C. (1993). A Map Interface for Exploring Multivariate Paleoclimate Data. In Auto-Carto 11 Proceedings, (pp. 63-71). Bethesda, MD : The American Society for Photogrammetry and Remote Sensing.

Egenhofer, M. J. & Frank, A. U. (1988). Designing Object-Oriented Query Languages for GIS: Human Interface Aspects. In Proceedings: Third International Symposium on Spatial Data Handling, (pp. 79-95). Columbus, Ohio : International Geographical Union, Commission on Geographical Data Sensing and Processing, Dept. of Geography, Ohio State University.

Egenhofer, M. J. & Richards, J. R. (1993). The Geographer's Desktop: A Direct-Manipulation User Interface for Map Overlay. In Auto-Carto 11 Proceedings, (pp. 63-71). Bethesda, MD : The American Society for Photogrammetry and Remote Sensing.

Frank, A. U. (1991). Properties of Geographic Data: Requirements for Spatial Access Methods. In Guenther, O & Schek, H.-J. (eds) Advances in Spatial Databases, (pp. 225-234). Berlin : Springer-Verlag.

Frew, J., Carver, L., Fischer, C., Goodchild, M., Larsgaard, M. Smith, T. & Zheng, Q. (1995). The Alexandria Rapid Prototype: building a digital library for spatial information. In 1995 ESRI User Conference Proceedings. Redlands, CA: Environmental Systems Research Institute, 1995. http://www.esri.com/resources/userconf/proc95/to300/p255.html

Furnas, G. W. (1991). New graphic reasoning models for understanding graphical interfaces. In Human Factors in Computing Systems: Reaching Through Technology, CHI `91 Conference Proceedings, (pp.71-78). New York : ACM.

Griffiths, A. (1989). SAGIS: A Proposal for a Sardinian Geographic Information System and an assessment of alternative implementation strategies. Journal of Information Science, 15, 261-267.

Holmes, D. O. (1990). Computers and geographic information access. Meridian, 4, 37-49.

Huse, S. (1995). GRASSLinks: A New Model for Spatial Information Access in Environmental Planning. (Doctoral Dissertation, University of California, Berkeley, 1995)

Jones, W. P. & Dumais, S. T. (1986). The Spatial Metaphor for User Interfaces: Experimental Tests of Reference by Location versus Name. ACM Transactions on Office Information Systems, 4, 42-63.

Larsgaard, M. L. (1987). Map librarianship : an introduction (2nd ed.). Littleton, Colo. : Libraries Unlimited.

Larson, R. R. (1994). Design and Development of a Network-Based Electronic Library. In Navigating the Networks: Proceedings of the ASIS Midyear Meeting, (pp. 95-114). Medford, NJ: Learned Information.

Larson, R. R., Moon, R., McDonough, J., Kuntz, L., O'Leary, P. (in press). Cheshire II: Design and Evaluation of a Next-Generation Online Catalog System. To appear in the Proceedings of the American Society for Information Science Annual Meeting, 1995.

Laurini, R & Thompson, D. (1992). Fundamentals of spatial information systems. San Diego, Calif. : Academic Press.

McCann, C. M., Taylor, M. M. & Tuori, M. I. (1988). ISIS: The interactive spatial information system. International Journal of Man-Machine Studies, 28, 101-138.

Miller, G. A., Beckwith, R., Fellbaum, C., Gross, D. & Miller, K. (1990). Five papers on WordNet (CSL Report 43). Princeton University : Cognitive Science Laboratory.

Morris, B. (1988). CARTO-NET: Graphic retrieval and management in an automated map library. Special Libraries Association, Geography and Map Division Bulletin, 152, 19-35.

NISO - National Information Standards Organization (1992). Information Retrieval Service Protocol for Open Systems Interconnection (ANSI Z39.50-1992). Bethesda, MD : NISO.

Nebert, D. D. (1995). Serving Digital Map Information through the World-Wide-Web and Wide-Area Information Server Technology. (available here). Reston, VA : U.S. Geological Survey.

Ousterhout, J. K. (1994). Tcl and the Tk Toolkit. Reading, Mass. : Addison-Wesley.

Salton, G. (1989). Automatic Text Processing: The Transformation, Analysis, and Retrieval of Information by Computer. Reading, Mass. : Addison-Wesley.

Stonebraker, M., Chen, J., Nathan, N., Paxson, C. & Wu, J. (1993). Tioga: Providing Data Management Support for Scientific Visualization Applications. In R. Agrawal, S. Baker & D. Bell (Eds.), Proceedings of the 19th International Conference on Very Large Data Bases (pp. 25-38). Palo Alto, Calif.: Morgan Kaufmann Publishers.

United States Department of the Interior, U.S. Geological Survey (1985). Geographic Names Information System: Data Users Guide 6. Reston, VA : United States Geological Survey.

von Hoff, A. (1995). Java and Internet Programming. Dr. Dobb's Journal, 20(8), 56-61.

Walker, D. R. F, Newman, I. A., Medyckj-Scott, D. J. & Ruggles, C. L. N. (1992). A System for Identifying Datasets for GIS Users. International Journal of Geographical Information System, 6, 511-527

Wilensky, R. et al., (1994). An Electronic Environmental Library Project (Proposal to NSF). Available as html doc

Woodruff , A. G. & Plaunt, C. (1994a). GIPSY: Geo-referenced Information Processing System. Journal of the American Society for Information Science, 45, 645-655.

Woodruff, A. G. & Plaunt, C. (1994b). Automated Geographic Indexing of Text Documents (Sequoia 2000 Technical Report 94/41). Berkeley, Calif.: University of California, EECS.