Maps Alive: Viewing Geospatial Information on the WWW

Abstract

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:

• the amount of available geographical data by far exceeds the storage capacity of any one client machine: the system needs to be network based with data stored in server hosts (An extreme example is the USGS's 1-meter resolution monochrome image of the United States - when completed it will be available on 3,300 CD-ROM's!),
• the system is model based: servers provide clients with models of spatial and other data and all image rendering is done locally by client hosts,
• there is a large variety of data, relevant to this system, located on many servers in many formats: a directory system is needed to find such data,
• some geography-related data (weather satellite and radar images, traffic reports, news, hotel reservations) need to be accessed in (almost) real time: the system must be network-based to obtain such data,
• the system will used in traditional computers (PC's, workstations, NC's) as well as in many unforeseen or futuristic devices (ITV's, game boxes, exercise bicycles, multi-media kiosks, cellular phones, sunglasses, heads-up displays on car windshields),
• a user may need to write custom application programs to visualize some particular data while applications developed by others display related data.

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

• a telecommunications company can develop an applet using its own visualization techniques to see the load on its network from data available on the company's intranet while simultaneously other applets are obtaining related data (maps, news, weather and earthquake reports) from the public Internet,
• a lighthouse enthusiast can develop a multimedia applet with lighthouses that flash their lights and beep their identification codes just as real lighthouses used to do,
• a hotel reservation applet/agent can search the Web for available hotel rooms closest to a given location and make reservations,
• a news organization can index its archive of photographs and video clips by the location (and orientation) where they were taken.

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.

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
	/Architecture/Lighthouses
	/Geography/Terrain/United States/30-meters
	/Geography/Terrain/United States/3-arc-seconds
	/Geography/Terrain/Earth/30-arc-seconds

	<!--	US National Park System	-->

	<LAYER type=POINTS,
		layer="/Regional/Countries/United States/National Parks",
		comment="U.S. National Parks",
		url="http://www.nps.gov"
		icon="/icons/nps-large.gif" >

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

	<APOINT type=ANCHOR_DEFINED,
		name="Abraham Lincoln Birthplace NHS",
		comment="Hodgenville, Kentucky",
		url="http://www.nps.gov/parklists/index/abli.html",
		ll="-85.6381,37.6114", icon="/icons/nps.gif" >

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

	<APOINT type=ANCHOR_DEFINED,
		name="Acadia NP",
		comment="Mount Desert Island, Maine",
		url="http://www.nps.gov/parklists/index/acad.html",
		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.

(a)	(b)
(c)	(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:

• obtain only tiles in a narrow corridor along the user's path; the cached tiles look like a snake with a growing head and disappearing tail [Figure 2(a,b,c)],
• obtain as many tiles as close to the view as possible; this may be used in low speeds (hovering) when the direction of flight is uncertain [Figure 2(d)],
• obtain as many tiles ahead as possible, in a widening wedge, and delete any tiles already visited; this may be used during high-speed flight.

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:

• a user can click on an anchor in an HTML document concurrently displayed by an HTML browser,
• a user can use a mouse or some other tracking device (hand gestures, force-feedback joystick, GPS receiver), or
• a mapplet can take control of the browser and compute directions procedurally (e.g., the great circle) or in any other way, perhaps even including the two above methods.

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:

• After the core browser has been started, a user may launch additional mapplets - typically, from a mapplet HTML page. By default, the image mapplet, described in Section 3.3.1, is always started with the core browser.
• Mapplets are ordered top to bottom in a stack, a mapplet can draw into one or more top-to-bottom ordered adjacent layers.
• Before drawing a layer, a mapplet may have to wait for specified lower layers to be drawn first.
• A mapplet draws static data (which changes infrequently) into the off-screen tiles, and dynamic data (which changes from frame to frame) into the on-screen window.
• If a mapplet needs to redraw one of its layers in a cached tile, it invalidates the contents of the tile. All other running mapplets must then redraw their layers in that tile. This means that the mapplets may have to reload their server's data or must maintain their own independent tile cache.
• Before compositing the cached tiles into the final window image, the browser may have to wait for specified layers to be drawn. By default it always waits for the image mapplet to draw its layer(s).
• When a mapplet draws directly into the on-screen window, it likely requires a separate drawing process, in order to maintain the browser's interactive update rate.
• A mapplet can register with the core browser to receive events from the user's tracking device. An event can be received by all the registered mapplets or can be passed from top to bottom mapplets until a mapplet acts on it.

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

• a socket library provides a general client/server network connection functions,
• an HTTP library provides an interface for the HTTP/1.0 protocol [3] on both the client and server sides. This library also implements an interface to an HTML browser (Netscape Navigator, Mosaic) running concurrently. Moreover, it provides a uniform interface for filling out URL templates.
• a caching library allows HTTP documents to be cached in the local client machine in memory or on disc,
• a graphical library draws geometrical primitives either to the off-screen tiles or directly to the on-screen window, as it clips geometrical primitives to within a tile, it puts any clipped parts on a waiting list and draws them later when the adjacent tiles become available,
• an image processing library performs some elementary image processing functions; as in the graphical library case, if an image-processing function, such as a filter, needs pixels from adjoining tiles, the library needs to preserve them and provide them to adjacent tiles,
• a geographical library converts the coordinates of geometrical primitives among various geographical coordinates systems; it is based on the USGS cartographic library [5].

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:

• elevation + gradient -> color shaded relief - maps elevations into ambient colors - via an elevation lookup table - and adds relief shading based on the local surface gradient - via a second lookup table; Horn [10] describes many relief shading techniques,
• elevation -> elevation-mapped color - maps elevations into elevation colors without gradient shading using only the first lookup table above,
• gradient -> grey-tone shaded relief - maps gradients into a monochrome shaded relief image using only the second lookup table above,
• rgb + gradient -> shaded-relief image - maps gradients into a monochrome shaded-relief image which is added to a color image (typically a LANDSAT image),
• mono + gradient -> shaded-relief image - same as above but the shaded-relief is added to a monochrome image (typically a DOQ image).

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.

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)].

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
	/Architecture/Lighthouses

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.

(a)	(b)
(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.

(a)	(b)
(c)	(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].

(a)	(b)
(c)	(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.

Acknowledgements

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.

References

[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, http://www.ics.uci.edu/pub/ieft/http/draft-ieft-http-v10-spec-00.ps.Z

[4] Distributed Interactive Simulation (IEEE 1278-1993 standard) - Frequently Asked Questions, http://ftp.sc.ist.ucf.edu/STDS/docs

[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, ftp://fgdc.er.usgs.gov/gdc/metadata/meta.6894.ps

[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, http://www.crs4.it/PRJ/VIRTSARD/

[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 http://www.sgi.com/Products/appsdirectory.dir/Applications/Visual_Simulation/ApplicationNumber113820.html

[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, http://alexandria.sdc.ucsb.edu

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