Maps Alive: Viewing Geospatial Information on the WWW

Michael Potmesil
Bell Laboratories, Lucent Technologies
Holmdel, New Jersey 07733, USA


We describe a WWW-based system - consisting of browsers, servers and connecting protocols - which allows users to view, search and post geographically-indexed information of the Earth. Much information available on the WWW, such as weather reports, home pages of National Parks, VRML models of cities, home pages of Holiday Inn hotels, Yellow and White Page directory listings or traffic and news reports, is better located and visualized when displayed directly or via clickable anchors on top of 2D maps or in full 3D environments.

We have developed two geographical browsers: a 2D map browser capable of continuous scroll and zoom of an arbitrarily large sheet and a 3D flight-simulator browser capable of continuous flight around the Earth. Both browsers download and cache geographical information, geometrical models, and URL anchors in small regions called tiles. The tile caching process is based on the user's current position, velocity, and acceleration in the 2D/3D space as well as on the latency of server replies. A user can program these browsers by adding small application programs - mapplets.

On the server side, we have developed geographical and geometrical servers which contain very large data bases of images, elevations, lines, points and polygons stored in tiles structured into hierarchical pyramids or quadtrees. We have also developed a metadata server which contains, in hierarchical layers, URL pointers and geographical coordinates of various WWW documents, geographical information and geometrical models.

Keywords: Geography, Geographical Browsers, Spatial Indexing and Metadata, Flight Simulators, 3D Visualization, Digital Maps

1. Introduction

Internet-based computers and communications can be very effective in enhancing our ability to visualize and to search 3D environments in the great outdoors where we move, work, play and learn. In this paper, we describe a WWW-based system - consisting of browsers, servers and connecting protocols - which allows users to view, search and post geographically-indexed information.

Much information available on the WWW, such as weather reports, home pages of National Parks, VRML models of cities, home pages of Holiday Inn hotels, Yellow and White Page directory listings or traffic and news reports, is better located and visualized when displayed directly or via clickable anchors on top of 2D maps or in full 3D environments. In addition, very large data bases of geographical information itself, such as terrain elevation, satellite and aerial images, detailed street maps and geometrical models of buildings and similar man-made structures (present, past and future) are also becoming available. We seek to build an integrated system which will allow its users to browse in such spatial data, make queries and post new data.

Two geographical browsers have been developed for this system: a 2D map browser capable of continuous scroll and zoom of an arbitrarily large sheet of 2D information and a 3D flight-simulator browser. Both browsers download and cache geographical information, geometrical models, and URL anchors in small regions called tiles. The tile caching process is based on the user's current position, velocity, and acceleration in a 2D/3D space as well as on the latency of server replies. The browsers query servers only for relevant data around the user's current and predicted future locations and expect to receive such data and to prepare them for display before the user reaches it. Around this core concept of tile caching, various specialized visualization applets - written in C, C++ or Java - are developed. Such applets run simultaneously on top of the browser and convert all their respective data into a common coordinate system specified by the browser. Examples of such applets are weather and traffic reports, bird migrations, and a spatial bulletin board applet which displays an anchor of any WWW document at any geographical location. Each applet typically queries two servers: a spatial meta server, which knows what information is available at what geographical location and where on the WWW to find it, and the server which contains the information itself. The geographical system outlined in this paper is based on these assumptions:

By making this system programmable - preferably in Java - a user can develop applications not foreseen by the system's designers:

There are many WWW projects related to geographical information systems. The Virtual Tourist was probably the original HTML-based system allowing a Web browser to visit home pages of individual countries and states by clicking on a map. MapQuest is typical of image-based systems which allow users to specify, via an HTML interface, map coordinates and layers and to obtain GIF images of maps. Virtual Sardinia [10] is an example of a more advanced system which contains 2D maps, 3D models and video clips of Sardinia. There are two noteworthy 3D flight simulators: the T-vision Earth visualization project developed by ART+COM has a 3D viewer with the ability to prefetch geographical and geometrical models over an ATM network. The U.S. Department of Defense uses Powerscene [13], a 3D flight simulator developed by Cambridge Research Associates. In addition, Bigbook, a Yellow Page provider, is starting to build Bigbook3D which will let users view 3D VRML models of cities and find business locations. The Alexandria Digital Library [15] is a part of the NSF's Digital Library Initiative (DLI) specializing in geographical meta information.

2. Geospatial Servers

The concept of a geography server system recognizes that a digital map or a 3D geographical model is held by many independent sources, distributed over a network. The objective of a browser is to gather all the necessary geographical layers, on as-needed basis, without having to store them locally and to display them. Our architecture of a geography server system has three major components: a directory scheme for finding servers, a common interface protocol for talking to the servers, and a strategy for implementing the servers themselves. We have developed four different types of servers, so far, in this project: the first three contain actual geographical geometry - (1) points sampled on grids, (2) random points with names, and (3) lines and polygons with names - while the last type stores metadata - information about where to find spatial and geographical information.

2.1 A Tile Server

The tile server stores data that was obtained by sampling on a 2D grid. This may be satellite and aerial images, terrain elevations and gradients or geoid corrections. A data set is stored in a tile index. A data set may have several components such as: elevation, gradient, and rgb image. All tiles in a data set have usually the same size with the possible exception of tiles along the edges of the data set. Tiles in an index are stored in a power-of-two pyramid to allow fast access and scroll and zoom operations [Figure 1]. Storing data in a power-of-two pyramid requires 1/4 + 1/8 + 1/16 + 1/32 + ... = 1/3 additional storage space. A data set may also be stored on one or more compressed formats. The index of each tile data set is read into the server at startup time and stored in a quadtree [14].

The server was designed to maintain maximum tile output to a large number of clients which are connected by fast networks. The server is multi-threaded: it serves multiple clients simultaneously. For each opened connection it spawns a separate process. If a connection is permanently kept opened, a second process is spawned to send tiles to the client while the first process receives tile requests from the client. Tiles, which have been recently read from discs, are saved in shared memory so that other clients can obtain them more quickly. This is useful when multiple clients are browsing in the same data as would happen in a networked game.

The server, using the HTTP/1.0 protocol [3], accepts two types of query: (a) send me a description of the requested tile index, (b) send me the contents of the requested tile. The output of the server has several pipelined stages which: (a) reformat the tile if the requested tile is not aligned with tiles stored in the server; (b) resample the tile if the requested tile is not in the same coordinate system; (c) dither the tile if the requesting client has only a limited number of colors; (d) add a digital watermark [2] if the tile data is copyrighted or encrypt the tile if it is to be seen only by the client; (e) compress the tile if the network bandwidth requires it.

[Image Pyramid]

Figure 1 A hierarchical representation of tiles in a pyramid: 2×2 tiles are filtered [11]
into a single tile in the next higher level.

2.2 Geographical Name, Point, Line and Polygon Servers

A geographical name server provides clients with geographical names and their locations. The server loads its index of points from data files into virtual memory at startup time. The index is also sorted into a quadtree. Three versions of the server are being used with different data bases: full GNIS - currently about 1.7 million names in the U.S., short GNIS - about 44,000 names in the U.S. and DCW gazetteer - about 200,000 names world wide. The server is queried by a regular expression name, a type, a distance and a bounding rectangle or circle. An HTML page can be used to search directly the name data bases and to start the geographical browsers from an HTML browser. The line server is similar to the name server but uses lines, polylines and polygons as data elements. This server is queried by a type and a bounding rectangle.

2.3 A Spatial Bulletin Board Server

To provide a spatial browser with a directory system of spatially-indexed documents available on the WWW, including the above geographical servers, we have developed a Spatial Bulletin Board (SBB) server. Here, a WWW user can metaphorically take any Web document and pin to any place on Earth and place it into a layer with a unique name. The server contains geographical layers in named tree hierarchies such as:

	/Regional/Countries/United States/National Parks
	/Travel/Lodging/Motels/Best Western
	/Travel/Lodging/Motels/Holiday Inn
	/Travel/Lodging/Bed & Breakfast
	/Commerce/Car Dealers/Toyota
	/Geography/Terrain/United States/30-meters
	/Geography/Terrain/United States/3-arc-seconds
At the leaf node of each layer, there is a list of anchors, a procedure or a URL. The tree hierarchy of layers can contain symbolic links so that a layer can appear in more than one location of the layer hierarchy. When the server is started, it reads a layer file which contains the layer hierarchy and builds the layer tree. At each populated leaf node, it reads an anchor file and builds a quadtree of anchors. Quadtrees are again used for fast anchor query. A layer has read/write rights and owner and password fields to allow multiple users to own and to post their data. The anchors are currently limited to points with names, polylines, polygons and icons. At startup time, they are read from files that store them in a home-grown SGML format:
	<!--	US National Park System	-->

		layer="/Regional/Countries/United States/National Parks",
		comment="U.S. National Parks",
		icon="/icons/nps-large.gif" >

	<!--	Abraham Lincoln Birthplace NHS, Hodgenville, KY	-->

		name="Abraham Lincoln Birthplace NHS",
		comment="Hodgenville, Kentucky",
		ll="-85.6381,37.6114", icon="/icons/nps.gif" >

	<!--	Acadia NP, Bar Harbor, ME	-->

		name="Acadia NP",
		comment="Mount Desert Island, Maine",
		ll="-68.2833,44.3560", icon="/icons/nps.gif" >

The server also uses the HTTP/1.0 protocol. When it receives a request from an HTML browser, it generates an HTML page from its layer and anchor data and a user can browse all the layers and see all the anchors in the HTML browser. The current organization of the layers looks much like that in the Yahoo directory system. When or if a spatial metadata standard, such as that proposed in [6] or being developed in [15], is widely accepted, we will adapt it in this server.

2.4 Posting Spatial Meta Information on the Server

In order to populate this server with meaningful information, we had to develop a number of tools. They allow us to scan various text documents, including HTML pages, for geographical names or postal addresses and to convert them to spatial coordinates, typically, longitude and latitude, possibly with a bounding rectangle or circle.

We use the traditional Unix tools such as awk and sed to extract specified fields using regular expressions from HTML and ASCII files. The appropriate files are usually manually downloaded from the Web. The HTML files typically include a long list of anchors pointing to other HTML pages or Web documents. We extract three fields from a list item: a geographical name or postal address, a Web document URL and an optional comment. Next, another tool which queries one of our geographical name servers (Section 2.2) finds spatial coordinates of each geographical name. A final tool generates the SBB anchors in our SGML format. If the geographical name field contains a U.S. postal address we query a conversion service available on the Web which presumably uses address information from the TIGER census data base. We have also developed a tool that automatically extracts business information from the NYNEX Yellow Pages and residence information from the AT&T Rainbow Pages.

Since the leaf node of a layer can contain, in place of a local anchor file, a URL to a WWW document, it is possible for users to own, create and edit their own SBB layers in their own HTTP servers.

3. A Geographical Browser

In this paper, we describe a system for viewing geospatial models which reside in server hosts across the Internet network. The client browsers, which are described here, have the ability to cache parts of the geospatial models before a user needs to display them. The servers can generate the models in small sections - called tiles - because they store them in hierarchical representations or have the ability to clip all parts of a model outside the requested area (or volume). We base this approach on the assumption that the amount of such models far exceeds the ability to store these models locally.

Much work in this paper is centered around two data representations: quadtrees for geometrical elements such as points, lines and polygons and image pyramids for 2D lattice data such as images, elevations or gradients. Quadtree data structures and algorithms, many of them for geographical applications, are described in books and papers by Samet [14]. The concept of prefiltered power-of-two images for texture mapping was introduced by Williams [17] who named them mip maps. Since his seminal paper, it has become a rendering standard implemented, for example, in OpenGL software [12] and hardware [1]. In the 2D browser we use any type of data sampled on a 2D lattice. However, our techniques are applicable to any other model representations such as TIN's (Triangulated Irregular Networks) of terrain or VRML models which are clipped to rectangular regions. In more complex environments, such as furnished interiors of buildings, one must use more sophisticated data structures and display algorithms to maintain interactive display rates [8].

The browser consists of two processes: caching and compositing. The former process is responsible for managing the local cache while the latter process reads tracking data, synchronizes all application mapplets, and composites the final image. It also makes space (data and user) and time (either real or simulated) consistent among all the mapplets.

3.1 Tile Caching

The cache process allocates a common tile memory that is shared by all mapplets. It controls how the cached tiles are allocated in space and time. This cache allocation is currently based on five parameters: x, y, z, level-of-detail and time. In a 2D mode, the level-of-detail parameter is used as a discrete z level in a 3D pyramid. Time in this context is interpreted as discrete time slices.

The caching algorithm uses the user's current position, velocity, and acceleration to estimate where the user is moving and allocates new tiles there. This process is shown in Figure 2. When the tile cache is full, some resident tiles need to be deleted. These can be tiles furthermost from the user, least-recently visible tiles, or least-recently arrived tiles.

[Cache A] (a) [Cache B] (b)
[Cache C] (c) [Cache D] (d)

Figure 2 Contents of the browser's cache memory after (a) flying from Egypt to Britain,
(b) to Alaska, (c) to Australia, and (d) hovering above Australia.

The caching process receives information about the current view from the compositing process. A 2D browser may have multiple windows opened, each with an orthographic projection of a different location and scale of a map. A 3D browser may have also multiple windows opened, each with a different perspective projection. Each window can be moving completely independently of all the others, or they may be different views from one user (e.g., left and right views from a cockpit, or the view of a tail gunner). The caching process computes one or more estimated positions of each view and intersects their bounding volume with the tile coordinate system. Any intersected tiles not present in the cache are sorted by distance from the user, and the caching algorithm determines how many of them can be loaded into the cache. This depends on the total number of allocated tiles for we need to prevent tile thrashing. The more disc and memory space the host machine has available, the more tiles can be brought into the cache and remain there. There are several implemented caching strategies:

When the caching process has generated a new list of tiles to be cached, each mapplet can start loading its data into each tile. Mapplets also provide feedback to the cache process: each tile is marked by each mapplet when it has been drawn, and each mapplet saves the average time it takes to receive and draw the tile data.

3.2 Tile Compositing

The tile compositing process composites tile data from the off-screen cached tiles into the on-screen window image. While compositing tiles, it checks whether all mapplets have drawn their layer(s). If there are layers that have to be drawn before a tile can be shown, the process must wait. This process is also responsible for synchronizing all mapplets, obtaining the user's tracking data from a tracking device and obtaining real time or computing simulated time. This assures that all mapplets are in the same space and time. Directions where and how the browser should move in space can come from one of these sources:

The two processes run independently and asynchronously. The cache manager keeps rearranging the cache memory even while the user has stopped and the image is not regenerated.

3.3 Mapplets: Geographical Applets

The core of the geographical browser, which consists of the display and caching processes, is programmable with small application programs called mapplets. They are preferably written in a platform-independent and down-loadable code such as Java. The programmability of the browser gives a user the ability to mix-and-match mapplets and to view data in novel ways - not foreseen by the authors of the browser. In this section, we describe some of the mapplets that we have developed.

Mapplets obtain pertinent geographical and other data from Internet servers, convert them, if needed, from external representations, and render them via the browser's graphical and image-processing libraries. These are the basic rules that apply to mapplets:

There are several libraries that the core browser makes available to the user mapplets:

An individual mapplet may consist of several processes, usually 1-3, which divide the typical mapplet tasks into 3 stages: (1) obtaining metadata and data from servers, (2) converting obtained data into an internal representation, and (3) drawing the data. If a mapplet also needs to obtain meta information from a server or data from multiple information servers, additional processes may have to be spawn. Much of this design depends on the number of simultaneous requests a mapplet will be making and the size and latency of the returned data.

3.3.1 An Image Applet

This is the fundamental mapplet, by default always enabled by the browser. It obtains tile data from the tile server described in Section 2.1 and converts them into images in the cached tiles. The tiles received from the server are processed in three pipelined steps: (1) an optional decompression, (2) mapping into an image, (3) conversion to the local display format. The mapplet may request compressed tiles from the tile server if the speed of the network connection justifies the additional time spent by the mapplet in tile decompression. The elevation data are usually compressed using a wavelet compression [7], while the gradient and image data are usually compressed using JPEG. When using a slower network, the gradient data may be computed locally by the mapplet rather than downloaded from the server. When all the tile components are decompressed, they are converted into an image using one of these mappings:

Finally, following the above mappings, if the local display buffer is 24/32-bits deep, a true-color image is displayed. However, if the frame buffer is only 8-bits deep, a dithered image - using ordered dither algorithm - or a monochrome image is displayed.

[Death Valley]

Figure 3 Death Valley, California: terrain, boundary, name and road layers
obtained by four mapplets from four different servers.

3.3.2 A GIF Applet

This mapplet obtains image tiles, stored or generated as GIF images, from several WWW servers. The mapplet obtains a GIF image, decodes it and draws it on top of the current tile contents. Optionally, in addition to the GIF transparency value, an alpha-blending value can be specified to make the image background partially visible.

Currently, the mapplet can obtain maps and images from three outside sources: (1) the well-known Xerox PARC map server which contains data from the DMA's Digital Chart of the World and the USGS's 1:2,000,000 Digital Line Graph, (2) the U.S. Bureau of the Census TIGER street map server, and (3) the multi-resolution Mars image server at the Los Alamos National Laboratory.

3.3.3 A Geographical Name Applet

This mapplet obtains geographical names and coordinates from the server of Section 2.2 and draws them into the cached tiles or the on-screen window. The received names are kept in a per-tile quadtree which is created by the mapplet when the cache manager allocates a new tile and deleted by the mapplet when the cache manager deletes the corresponding tile. The names can be clickable with a URL query attached to them by the mapplet. The names are drawn simply as a horizontal text; currently, no additional text layout is done. Because of this simple minded layout and potentially high density of names, the mapplet can also draw only the name nearest to the cursor or names in a small region around the cursor directly into the on-screen window. Queries can also be triggered by the user's movements: if the user hovers near a name, its query can be automatically executed.

Figure 4 shows names on Attu Island, Alaska; if the names are used to query the Encyclopedia Britannica, clicking on the Attu Island name produces a reply which is received by our HTML browser. A 3D version of this mapplet displays the geographical names as text floating in the air, always facing the viewer, with a pointer to the surface [Figure 8(b)].

[Attu Island]

Figure 4 Geographical name queries to WWW: Attu Island, Alaska.

3.3.4 A Line and Polygon Applet

This mapplet draws lines, polylines and polygons into the cached tiles. The line segments and their textual labels can be clickable and an attached URL query can be executed. In addition, crossing inside or outside of a polygon can be detected and a query automatically executed. For example, crossing a country's border or crossing a city limit can download an appropriate home page.

3.3.5 A Spatial Bulletin Board Applet

This mapplet draws layers of pushpins obtained from the Spatial Bulletin Board server as clickable icons and text. The size of the icons and appearance of the text depend on the current resolution of the image in the browser. The mapplet works in conjunction with an HTML browser which obtains HTML pages from the SBB server. A user browses in HTML pages of the SBB server by clicking on layer names. A user can enable and disable layers by clicking on appropriate anchors in an HTML page. The mapplet listens on a well-known port with the HTTP protocol for a request from the HTML browser to enable or disable a layer. When the mapplet receives such a request, it adds or removes the layer to or from a list of active layers. Whenever a new tile is allocated by the cache system, the mapplet makes a request to the SBB server for all active layer information inside the tile and draws the received data. Since all layers are hierarchical, enabling or disabling a layer also enables or disables all layers below it in the layer hierarchy.

Figure 5 shows an image of Cape Hatteras, North Carolina, with these layers enabled:

	/Regional/Countries/United States/National Parks
	/Travel/Lodging/Motels/Holiday Inn
Clicking on the Holiday Inn icon or address brings the motel's home page, which contains a reservation form, from the Holiday Inn server, clicking on the telephone number makes a phone call to the motel. Similarly, clicking on the Boddie Island Lighthouse icon or name produces its home page.

[Cape Hatteras]

Figure 5 Spatial Bulletin Board mapplet: Cape Hatteras, North Carolina.

3.3.6 A Weather Report Applet

This mapplet obtains weather reports from several sources as HTML pages, parses them into an internal representation and displays them as a layer either in the cached tiles or in the on-screen window. The three external sources of weather reports are a Michigan State University (MSU) server, which reports weather conditions in about 1400 U.S. and Canadian cities (actually, mostly airports), a CNN server, which reports weather conditions, including 4-day forecasts, in about 250 cities around the world, and finally a Weather Channel server, with about 1200 weather reports world wide.

For each cached tile, this mapplet queries the Spatial Bulletin Board server at an appropriate layer and receives a list of weather stations within the tile. For each weather station, the mapplet makes a query to the weather report server and receives an HTML document which it parses into an internal format. The mapplet can display different aspects of weather reports (temperature, conditions, humidity, pressure, etc.) or different days of a forecast, possibly in an animated loop, as whimsical icons. The icons can be animated (rain and snow) and composited with alpha blending (fog, haze). This mapplet is also internationalized: English units are used inside the U.S. and metric units in the rest of the world.

[MSU Text Weather] (a) [MSU Icon Weather] (b)
[CNN Icon Weather] (c)

Figure 6 Weather mapplet: (a) MSU reports as text, (b) MSU reports as icons
around San Francisco Bay, and (c) CNN reports in Europe.

All three weather report servers periodically update their reports: the MSU server once an hour and the other two every six hours. If this mapplet runs for a long time - perhaps as a screen saver - it is desirable to load a new report as soon as it becomes available. For this purpose, the HTTP protocol [3] contains an Expires: HTTP-date field in the HTTP Full-Response header. Unfortunately, none of the servers implements this field, and therefore this mapplet had to be hard-coded with the times when the servers are updated with new reports.

In addition to drawing weather reports at coordinates of reporting weather stations, this mapplet can also obtain data about current or past tropical storms and draw them. There are two tropical-storm servers - at University of Hawaii and at Purdue University - that we have found, with storm tracks available as HTML or ASCII documents with longitude, latitude, pressure, speed, date/time sample points. For storms currently in progress, the tracking data also includes forecast data. A 3D version of this mapplet can create actual atmospheric conditions [Figure 8(a)].

3.3.7 A Land, Water and Vegetation Monitoring Applet

The North American Land Characterization (NALC) project is a joint program of USGS, NASA and EPA to produce LANDSAT images at 60-meter resolution of the 48 conterminous U.S. states and Mexico. The image data consists of a 4-band MSS data and a 1-band NDVI vegetation index for three time periods: 1970's, 1980's and 1990's.

[Mt. St. Helens: 1970's] (a) [Mt. St. Helens: 1990's] (b)
[Mt. St. Helens: 1980's - 1970's] (c) [Mt. St. Helens: 1990's - 1980's] (d)

Figure 7 Land cover mapplet: Mount St. Helen's, WA (a) 1970's (snow capped peak), (b) 1990's (crater), (c) vegetation decrease between 1970's and 1980's in red (d) vegetation increase between 1980's and 1990's in green.

We have developed a Java mapplet that computes changes in land cover by computing differences between images from different epochs. This allows a user to see changes caused by forest fires and forest logging, water reservoirs, urbanization, and even barrier island movement.

Figure 7 shows LANDSAT images of Mount St. Helen's (a) before the volcanic eruption in 1979, and (b) after the eruption. From the changes in the vegetation index we can display areas with decreased vegetation in red tint and areas with increased vegetation in green tint. Figure 7(c) shows the decrease in vegetation cover between 1970's and 1980's caused by the eruption, and Figure 7(d) shows the subsequent increase in vegetation cover between 1980's and 1990's due to nature's recovery.

3.4 A 3D Geographical Browser

We have developed a preliminary version of a three-dimensional browser which displays terrain data cached from the tile server and geographical names cached from the name server. The browser uses the OpenGL library to render 3D graphics. To make the three-dimensional browser truly global, we represent the Earth as an ellipsoid or geodetic datum called World Geodetic System 1984 (WGS84) [4].

[Tuolumne Meadows] (a) [Devils Tower] (b)
[Strait of Gibraltar] (c) [Mount Everest] (d)

Figure 8 Four views from the 3D browser: (a) Tuolumne Meadows, Yosemite National Park, California in fog, (b) Devils Tower, Wyoming with names, (c) east from Atlantic Ocean across Strait of Gibraltar, and (d) southwest from the top of Mount Everest towards India.

Figure 8 shows four frames captured while flying with this browser in different types of terrain data. Figure 8(a) shows (in good quality prints) light fog about 1 mile from the viewer. Figure 8(b) shows geographical names drawn by a 3D version of the name mapplet. In Figures 8(a,b) there is a pseudo-random texture mapped on the terrain; in Figures 8(c,d) the ambient color of the terrain is procedurally generated from the elevation and gradient values.

4. Summary, Conclusions and Future

We have described the makings of a comprehensive geographical system based on the WWW. A client browser obtains geographical models and other spatially-indexed information from WWW servers and renders them locally into a displayable image. The browser is composed of a display and caching mechanism and a number of applets. The final image can be that of a 2D continuously scrolled and zoomed map or a 3D perspective projection of a flight simulator. Unlike an image-based system, where all computations are done on a server and only the final image is downloaded, this system makes use of the power of the local client hardware, allows for a scalable system, and has the potential of client-to-client interaction.

Meta information about spatially-indexed information is posted on a Spatial Bulletin Board server. The metaphor used by this server is that any WWW document can be pinned to any geographical location. When a user enables a named layer stored in the SBB, a mapplet can find the actual documents and process them - typically convert them to a displayable form or load them into an accompanying HTML browser. Rather than just sending GIF images from a server to an HTML client - perhaps at the rate of one image every five seconds - we have developed browsers that can scroll and zoom in 2D spatial data or fly in full 3D environments - at interactive speeds of 10-20 frames/s. In this paper, we have attempted to illustrate - using mostly 2D examples - how a complete, Web-based visualization system of the Earth can be developed - one that makes a compelling and integrated presentation of spatial models and other spatially-indexed information.


This work has greatly benefited from frequent discussions with my colleagues Cati Laporte, Jakub Segen and Joe Worth. All icons drawn by the weather mapplet as well as most icons drawn by the Spatial Bulletin Board mapplet were designed by Cati Laporte.


[1] Akeley, Kurt, "RealityEngine Graphics," ACM Computer Graphics (Proceedings of Siggraph '93), 27, (3), August 1993, pages 109-116

[2] Bergher, Hal, and O'Gorman, Lawrence, "Protecting Ownership Rights through Digital Watermarking," Computer, 29, (7), 101-103, July 1996

[3] Bernes-Lee, T., Fielding, R. T., and Frystyk Nielsen H., "Hypertext Transfer Protocol - HTTP/1.0," Internet Draft, March 8, 1995,

[4] Distributed Interactive Simulation (IEEE 1278-1993 standard) - Frequently Asked Questions,

[5] Evenden, Gerald I., Cartographic Projection Procedures for the UNIX Environment - A User's Manual, USGS Open-File Report 90-284, February 1994

[6] Federal Geographic Data Committee, Content Standards for Digital Geospatial Metadata, June 8, 1994,

[7] Franklin, Wm. Randolph, and Said, Amir, "Lossy Compression of Elevation Data," Seventh Intl. Symp. on Spatial Data Handling (SDH '96), Delft, the Netherlands, August 1996

[8] Funkhouser, Thomas A., Sequin, Carlo H., and Teller, Seth J., "Management of Large Amounts of Data in Interactive Building Walkthroughs," ACM SIGGRAPH Special Issue on the 1992 Symposium on Interactive 3D Graphics, March 1992, pages 11-20

[9] Gobbetti, Enrico and Leone, Andrea O., "Virtual Sardinia: A Lage-Scale Hypermedia Regional Information System," Computer Networks and ISDN Systems (Proceedings of the 5th WWW Conference), 28, 1539-1546, 1996,

[10] Horn, Berthold K. P., "Hill Shading and the Reflectance Map," Proceedings of the IEEE, 69, (1), 14-47, January 1981

[11] Mitchell, Don P., and Netravali, Arun N., "Reconstruction Filters in Computer Graphics," ACM Computer Graphics (Proceedings of Siggraph '88), 22, (4), August 1988, pages 221-228

[12] Neider, Jackie, Davis, Tom, and Woo, Mason; OpenGL Architecture Review Board, OpenGL Programming Guide, Addison-Wesley, Reading, MA, 1993

[13] New York Times, "High-Tech Maps Guided Bosnia Talks," November 24, 1995, page A14

[14] Samet, Hanan, The Design and Analysis of Spatial Data Structures, Addison-Wesley, Reading, MA, 1990

[15] Smith, Terence R., "A Digital Library for Geographically Referenced Materials," Computer, 29, (5), 54-60, May 1996,

[16] Williams, Lance, "Pyramidal Parametrics," ACM Computer Graphics (Proceedings of Siggraph '83), 17, (3), July 1983, pages 1-11

Return to Top of Page
Return to Technical Papers Index