Abstract. Three integrated tools are presented to solve the problems of: 1) discovering appropriate global grid and associated data on the Internet, 2) modeling complex 3D structures using a standards-based geospatial reference model, and 3) visualizing global grids using 3D Web-streaming technology. Specifically, the GeoWeb is an infrastructure for indexing and discovering any data on the Internet based upon its location, GeoVRML is an open standards-based file format for georeferenced 3D models that is undergoing ISO standardization, and TerraVision is a freely-available Web-based 3D terrain visualization system. These components are integrated in the TerraVision client browser, which can automatically query the GeoWeb to discover all available data for the region being viewed and which can render GeoVRML format data overlaid on a global grid that is streamed incrementally over the Web using view-dependent techniques.[1]

Introduction

Taken as a coherent suite of solutions, these products provide the ability to index all geographic data on the Web in an open and highly scalable infrastructure, to support the use of accurately georeferenced 3D models using an ISO standard data format, and to enable users around the world to discover and visualize all these data using freely-available 3D clients for their desktop computers.

[top]

The GeoWeb Infrastructure

Even though search engines can now find almost all Web-accessible documents about a given topic, it is currently difficult to find Web-accessible data about a given location because the location is typically not a part of the data themselves. Examples of such georeferenced data include aerial and satellite images, 3D models of buildings and weather systems, and vacation pictures taken with GPS-enabled cameras. Thus, today's search engine technology is not applicable and the huge amount of georeferenced digital data that are available on the Web today is virtually inaccessible.

In an attempt to make georeferenced data accessible, a number of companies and organizations have created private or governmental databases that hold a small fraction of all georeferenced data. For example, companies like MapQuest maintain private map databases with associated street addresses and links to businesses like restaurants and shops. These databases hold searchable metadata, a summary description of the data that includes geographic location, which can either be searched directly, or via a clearinghouse. However, none of these organizations is either capable of, or willing to, create a database that would allow anybody in the world to publish and search georeferenced metadata. Indeed, this task is so large that no single, regional, organization could do it alone.

What is needed instead is a coordinated global infrastructure with participating organizations from around the world. We call this open standards-based infrastructure the GeoWeb, which could be realized as a new top-level domain (e.g., .geo) that would enable anybody to publish and search for all metadata referring to a given area (Leclerc et al., 2001a; Leclerc et al., 2001b; Leclerc et al., 2000). The infrastructure is based on a hierarchy of servers whose domain names represent geographic areas. An example hierarchy, described below, is nominally of the form minutes.degrees.tendegrees.geo. (For convenience, we use ".geo" as the top-level domain name in all of our examples of the GeoWeb hierarchy, although existing top-level domains could be used such as ".dotgeo.net".)

Using the GeoWeb hierarchy, Web sites or specialized applications will let users specify a search profile (keywords and other pertinent information) and find all georeferenced data satisfying the profile in a given area. Because the data are georeferenced they can be embedded in 2D maps or 3D models of the Earth, letting the users navigate through the map or model, providing a much more natural means of finding data than traditional search engines.

GeoWeb Design Principles

1. Naive transparency: Mapping from categories to metadata content is syntactically and semantically trivial. It should not be a difficult task to put together a sophisticated query involving a combination of criteria for a search.
2. Latitude/longitude and temporal extent: Since the basic search criteria are lat/long, elevation, and time, these must be explicit and required fields in the metadata.
3. Efficient coverage: In general, search fields should all be of relatively equal relevance. So that there is no overhead due to making something explicitly available for search that is rarely used.
4. Abstract query formats: One should explicitly avoid exposing any of the internal structure of the database in order to formulate queries. Moreover, one needs to allow for the possibility of sophisticated Boolean combination of simple queries in order to find exactly the desired set of metadata.
5. Standard format: It is desirable to adopt or at minimum support one of the existing standard metadata formats for external publishing (e.g., Dublin Core, FGDC, ISO/TC211).
6. Multilingual: It is important to respect the need to publish and discover metadata in languages other than English. This demands support for both multilingual descriptions and cross-linguistic categorizations of objects and services (e.g., the Universal Standard Products and Services Classification (UNSPSC) system).
7. Privacy and Information Security: It is vital for many potential uses of the GeoWeb infrastructure to ensure that privacy can be maintained in the face of a publicly accessible searchable infrastructure. A general framework is needed for restricting access to links, disallowing "tracking" of dynamic metadata items and allowing third parties to validate or endorse metadata entries.

GeoWeb Metadata

For example, a physical object such as a restaurant may have a metadata entry keyed to its location that contains a description and links for several distinct data elements (e.g., a home page, a menu, and a VRML model of the building) and services (e.g., a Voice over IP address, an online takeout order form, etc.). A user should be able to search for "a South Indian restaurant with an online menu and photographs within walking distance of my hotel." While it makes a great deal of sense to provide a semantic nexus for information at this level, this does not correspond to a traditional view of geographic metadata. Nevertheless, we have endeavored to build this level of capability on top of existing metadata work such as the ADL Collection Metadata (Hill et al, 1999).

It is worth noting, however, that the semantic break is not actually that great. It should be clear that traditional geographic metadata are actually encompassed by this broader conceptualization. A publisher could consider a single piece of data to be the appropriate conceptual object to be described by a metadata entry. It should be up to the metadata publisher to choose which level of object description is most appropriate for representing information within the index. Given that the choice to register a metadata entry is a very simple form of advertising, this flexibility can be considered to be one of the advantages of an opt-in registration strategy.

The GeoWeb DNS Hierarchy of Servers

Metadata in the GeoWeb are distributed across a number of servers for scalability. The servers have distinct Internet Domain Names that identify regions on the Earth bounded by latitude and longitude. Such a region is called a cell, and the domain name that identifies it is called a geographic domain name (see Figure 1). Following are example applications of geographic domain names using the minutes.degrees.tendegrees.geo name schema. (This schema is used here for simplicity, although the schema currently favored is actually of the form tenminutes.degrees.tendegrees.ninetydegrees.geo.)

• The geographic domain name 20e30n.geo identifies the 10-degree x 10- degree cell whose southwest corner is located at 20 degrees east, 30 degrees north.
• The geographic domain name 2e4n.10e50n.geo identifies the 1-degree x 1-degree cell whose southwest corner is located at 12 degrees east, 54 degrees north.
• The geographic domain name 11e21n.3e7n.30e10n.geo identifies the 1-minute x 1-minute cell whose southwest corner is located at 33 degrees, 11 minutes east and 17 degrees, 21 minutes north .

Metadata are placed in the hierarchy according to the number of cells that overlap the geographic coverage of the data they correspond to (see Figure 2). Specifically, the level with the smallest cells is used so that no more than four cells overlap the geographic coverage. At this chosen level, the metadata are stored in all the overlapping cells.

This naming convention and metadata placement strategy allows clients to determine which host(s) to query for metadata referring to a given area, thereby distributing the load over many servers with no single point of failure or congestion. This distribution and query method also reduces the storage and bandwidth requirements of any given server, making it possible for thousands of high-speed visualization systems to be simultaneously searching for and retrieving metadata and data.

The use of DNS also allows metadata to be transparently moved to new hosts and subdomains as needed. For example, initially all metadata may be physically hosted on a single computer, with all .geo domain names aliased to that machine. But over time, as areas fill with metadata (such as large urban areas), their corresponding subdomain and metadata can be transparently transferred to new computers. These computers may be maintained by other organizations who may, when necessary, transfer data to new computers (and new organizations) deeper in the hierarchy.

Dynamic GeoWeb Content

For example, an aircraft equipped with GPS receivers and secure wireless Internet access could periodically contact the dynamic directory server to update its current location, velocity, and other attributes. This information would then be used to update the geographic coordinates (and other attributes) in the corresponding metadata record in the GeoWeb hierarchy, and, when necessary, transfer the metadata record to a new cell. This dynamic metadata can then be used for many purposes, including air traffic analysis and providing global near-real-time maps of air traffic. Of course, the aircraft could in turn use the GeoWeb to download or access localized flight/airspace support information.

In the case of weather data, the dynamic directory server might be maintained by the U.S. National Weather Service itself, since its mandate includes the maintenance of real-time, public weather maps and storm information. As in the example above, the dynamic directory server would periodically update the corresponding metadata record and, when necessary, transfer it to a new cell.

Should the resource and network loads on these dynamic directory servers become too great for traditional single-point database methods, it would be relatively straightforward to take advantage of the strategy used by the location-based GeoWeb hierarchy and create a distributed DNS hierarchy to represent an object-identity index. For example, airplanes already have a registration ID that could be translated (and possibly encrypted for privacy) to a DNS name/id pair such as us.air.geo/AC7321. This server/id pair could then be used with exactly the same protocol as is used to update GeoWeb registry cells to update a dynamic directory server which then automatically updates the associated entry in the location-based GeoWeb hierarchy. In database terms, we can provide a second primary index into the global metadata database using exactly the same update protocols. These secondary indices could be either private or public, depending on data privacy concerns in the particular domains implemented.

Validation of Metadata and Data

GeoWeb Advantages

• Open opt-in scheme. No one company or institution can hope to index all geographically related information for the whole planet. Therefore, the GeoWeb is an opt-in scheme where users can register their own data, be it information about their bed and breakfast, or pictures of their trip to the Big Island.
• Integrate disparate data sources. Instead of being restricted to one company's view of the world, the GeoWeb allows users to discover and integrate disparate sources of information for improved decision-making.
• Massively scalable architecture. The entire GeoWeb index could be stored on one server, but as demands and database size grow individual cell servers can be split off on to additional physical machines. To illustrate the inherent scalability, there are over 60,000,000 1-minute servers possible over the land regions of the earth.
• No one-server bottleneck. Most contemporary search and indexing interfaces require going through a single point-of-failure server. In the GeoWeb, the client works out which cell server to contact based on the geographic extent of the query.
• Transparent load balancing. Using the DNS hierarchy enables transparent load balancing by moving data to new servers and organizations as needed. The IP addresses change and the bandwidth improves, but the domain names remain the same.
• Index any content. The GeoWeb can index any content, not just HTML. Movies, sound files, text, 3D models, terrain, etc. can all be indexed. Content such as HTML with geographic meta tags allows an easy way to register that content in the GeoWeb.
• Built-in security. Security is imperative to ensure that private data remains private, while still providing easy access to public information. In addition, there is a scheme to allow appropriate organizations to validate and/or endorse data.
• Support high bandwidth demands. Massive distribution of the geographic database enables many clients around the world to retrieve data simultaneously and at high speed.
• Reduced server costs. As the GeoWeb infrastructure is distributed over many cell servers, there is no need for a single massive server with huge storage requirements. The size and speed needed per server is therefore reduced, for example, divided by 10,000 or more for 10-minute servers.
• Local control. Companies, institutions, or local governments can manage the cell servers for their region of the world, and also host the cell servers in their geographic region.

GeoWeb Clients

Text-based: The most basic kind of interface would be similar to the types of search engines that we use today. However, in addition to entering a search criterion, you would also enter a location for your search. This could be a latitude/longitude coordinate, or more intuitively, a street address or a feature name that can be translated to a geodetic coordinate using a gazetteer service. The results could be presented as a simple list of links (ordered by distance), as is the case for most search engines today. This type of interface has the advantage that it scales down well to current handheld devices such as a PalmPilot &#153 or iPad &#153, as shown in Figure 3(a).

Map-based: There are already various mapping sites on the Web that will generate a 2D map for a region of interest, e.g., MapBlast!, Yahoo! Maps, MapQuest, Maps.com, etc. It is easy to imagine a GeoWeb client that lets users search over a particular geographic region and return the results as a map image with various icons overlaid (see Figure 3(b)). These icons could be hyperlinked so that clicking over them would take you to more information about that item, for example, clicking over the icon for a restaurant might take you to their menu or on-line reservation page.

TerraVision: TerraVision &#153 is a distributed, interactive terrain visualization system developed by SRI International. It allows users to navigate, in real time, through a 3D graphical representation of a real landscape created from elevation data and aerial images of that landscape. TerraVision is described in detail later in this chapter. It is designed as a GeoWeb client so that, as the user flies around the world, the system is constantly querying the GeoWeb index to discover all relevant information about the place being viewed. This information is then streamed automatically to the user's display for browsing.

Geoster: The popularity of file sharing protocols and applications has been amply demonstrated with the enormous usage of services like Napster and Gnutella. SRI is developing a file sharing application along the lines of Napster, but using the GeoWeb as the underlying indexing and search infrastructure. Geoster (pronounced jester) is an application built for sharing photos over the Web using the GeoWeb (see Figure 4). It lets users index photos from around the world and to share these with the rest of the world. This would allow users to do searches such as, show me all photos that have been taken of the Great Wall of China. Geoster is freely available from http://www.geoster.com/ and is written in Java and hence available across multiple platforms. This type of client could produce a large interest in the GeoWeb and generate a substantial amount of GeoWeb registrations.

[top]

The GeoVRML Standard

GeoVRML 1.0 content can be browsed interactively in any standard VRML97 browser. A number of these browsers exist as freely available plug-ins for common Web browsers such as Netscape Communicator and Microsoft Internet Explorer. Tools have been written to simplify the authoring and conversion of geospatial data to GeoVRML. In addition, GeoVRML is an open standard: its specification is published openly and a source-level sample implementation is provided. In this section, we will concentrate on a few of the commercially available tools that support the GeoVRML format, and also describe some of the capabilities that this solution provides geoscientists for the purpose of integrating their geographic data directly into a 3D computer graphics scene graph.

Tools

ArcInfo / ArcView: With version 8.1 of the 3D Analyst extension for the ArcView and ArcInfo products, released in April of 2001, ESRI added GeoVRML support to their range of capabilities. These products now allow export of GIS data to the GeoVRML file format for viewing over the Web. Figure 5 was created with ArcInfo 8.1 by combining an orthographic image (retouched to have a blue color) with a DEM of the Squaw Valley ski resort, near Lake Tahoe. The ESRI home page is http://www.esri.com/.

ShapeViz: Bashir Research produces a tool that allows you to view Shape files. This file format was created by ESRI as a way to interchange geometry data and is supported by their range of GIS products. ShapeViz can take Shape files and convert these to VRML for interactive visualization over the Web. With version 1.2 of ShapeViz, GeoVRML export support was added, along with the ability to specify the coordinate system of the Shape file (as this information is not ordinarily included in the Shape file). Figure 6 shows an example Shape file converted to GeoVRML using the ShapeViz tool. The Bashir Research home page is http://www.my3d.com/.

Cortona: ParallelGraphics produce a popular VRML browser caller Cortona, which is provided as a plug-in for Netscape and Internet Explorer. With version 3 of the Cortona browser, ParallelGraphics added a native implementation of the GeoVRML extensions. The implementation for these nodes can be automatically downloaded and installed when GeoVRML nodes are first used. The original GeoVRML implementation is written in Java so that it can run within any VRML browser that supports Java as a scripting language. With a native implementation, the Cortona browser offers more integrated and efficient support for this geospatial format. Figure 6 shows the converted Shape file being viewed with the Cortona browser. The Cortona browser can be found at http://www.parallelgraphics.com/.

DEM2GeoEG: DEM2GeoEG is a program to convert USGS

Digital Elevation Model (DEM) data into a VRML .wrl file that uses the GeoVRML 1.0 GeoElevationGrid (see below). The GeoElevationGrid is a version of the standard ElevationGrid but it lets you georeference the data to geographic coordinate systems such as UTM (Universal Transverse Mercator). One benefit of this is that you can fuse multiple GeoElevationGrids into a single scene and they will be correctly located with respect to each other. Figure 7 illustrates a USGS DEM converted to GeoVRML using this utility. The program and source code can be found from the GeoVRML home page at http://www.geovrml.org/.

tsmApi: The Tile Set Manager Application Program Interface (tsmApi) from SRI International is an Open Source library of high-level C functions for reading, writing, and processing the terrain data used by the TerraVision terrain visualization application. The tsmApi library can ingest a number of standard mapping products and produce GeoVRML representations of these terrain models. Specific formats that are supported include USGS DEM and DOQ, DTED level 0, GeoTIFF, TIFF, GIF, JPEG, PPM, and PGM. For further details, refer to http://www.tsmapi.com/.

Capabilities

1. Geographic Coordinate Systems. Most 3D graphics systems, including VRML, use a simple Cartesian (x,y,z) coordinate system to model all data. GeoVRML provides the ability to also specify locations using geodetic or projected coordinate systems such as those commonly used in the geosciences. Specifically, GeoVRML 1.0 has support for geodetic (latitude/longitude), Universal Transverse Mercator (UTM), and geocentric coordinate systems. In addition, 21 ellipsoids and 1 geoid are supported. This support is built upon the SEDRIS Spatial Reference Model (see http://www.sedris.org/).
2. Data Fusion. GeoVRML can handle data from disparate servers across the Web, generated from different sources, at different resolutions, and specified in different coordinate systems. These are all fused into a single global context for visualization. For example, you can overlay a Global Positioning System (GPS) track of latitude/longitude coordinates over a UTM-rectified terrain model.
3. High Precision. VRML97 provides only single-precision floating-point values. This is insufficient to represent data on a planetary scale down to around meter resolution or beyond. GeoVRML provides solutions to extending this precision to sub-millimeter by employing the specification of local coordinate systems.
4. Dataset Scalability. Terrain models often involve large elevation grids or image files. GeoVRML provides various scalability features to manage the streaming of large, multi- resolution models, thus facilitating real-time access and display of arbitrarily large terrain models.
5. Metadata Linking. GeoVRML provides the ability to specify a generic subset of metadata describing geographic objects, including the ability to link to a full metadata description.
6. Animation Support. The ability to perform key frame animations within the supported geographic coordinate systems is provided so that animations can be defined with respect to key points on the surface of the planet.

Implementation

GeoCoordinate: The GeoCoordinate node enables the specification of coordinates by using geographic coordinate systems. This node can be used within standard VRML geometry nodes such as IndexedFaceSet, IndexedLineSet, or PointSet, enabling the modeler to specify coordinates in a system such as UTM. For example, a GPS will normally output location as a latitude/longitude coordinate. With the GeoCoordinate node, we can insert these coordinates directly into a VRML file and have them integrated with any other geospatial data.

GeoElevationGrid: The GeoElevationGrid node provides the capability to define a grid of height values offset from the ellipsoid or geoid used to model the planet. It supports the specification of height fields in latitude/longitude or UTM coordinate systems. VRML97 already provides an ElevationGrid node; however, in this node all values are offset from a single flat plane. This is acceptable if the area being modeled is small in extent, for example, less than 1 km2, but for larger areas the curvature of the earth becomes significant. Figure 7 illustrates an example showing a GeoElevationGrid.

GeoLocation: The GeoLocation node lets the user georeference an arbitrary VRML model, that is, locate it at a specific point on the earth. It also orients the model correctly, depending upon its position on the earth, so that +Y is aligned with gravitational up, +Z points true north, and +X points east. This ensures that a model built using the standard VRML right-handed coordinate system will be placed on the earth so that its base is aligned with the surface of the planet. Figure 8 illustrates the capabilities of the GeoLocation node by georeferencing models of individual buildings of the SRI International main campus to an underlying terrain model of Menlo Park, CA.

GeoLOD: The GeoLOD node provides the capability to browse multi-resolution, tiled terrain data that are streamed over the Web. It automatically manages the progressive loading of higher-resolution data as the user approaches the terrain, and also unloads terrain data that the user has flown past. These are essential memory management and scalability operations for browsing massive terrain datasets. For example, Figure 9 illustrates a large multi-resolution dataset that is built using the GeoLOD node. We illustrate the capability to fly down through several levels of detail while higher-resolution data are streamed over the Internet to the user's display.

GeoPositionInterpolator: One of the many strengths of VRML is its ability to model dynamic systems. GeoVRML therefore incorporates the capability to animate models using geographic coordinates. This is implemented through the GeoPositionInterpolator node, which functions in much the same way as the standard VRML97 PositionInterpolator node, except that the key frame values can be specified using geographic coordinates. For example, if a GeoPositionInterpolator is created and given two geodetic coordinates, (122.413 W, 37.7483 N, 10000) and (116.388 E, 39.906 N, 10000), and the output is routed to a VRML model of a Boeing 777, then this aircraft would fly over the surface of the planet, from San Francisco to Beijing, at a constant altitude of 10,000 m. Using this capability, a vehicle could be animated based upon the list of latitude/longitude coordinates from a prerecorded GPS track, or from a live feed of Distributed Interactive Simulation (DIS) Protocol Data Units (PDUs).

GeoVRML Standards Positioning

The GeoVRML work is of major relevance to several exciting initiatives that are currently evolving. For example, this work provides the technical foundation to build the vision of a highly accurate and large-scale model of the earth into which we can embed massive quantities of georeferenced data: a vision that is sometimes referred to as the Digital Earth (Leclerc et al., 1999; Reddy et al., 1999b). See http://www.ai.sri.com/digital-earth/ and http://www.digitalearth.gov/.

On a related topic, the OpenGIS Consortium (OGC) is evolving its Web Mapping Testbed (WMT) technology as a means to revolutionize the use of geospatial data on the Web (de La Beaujardière, 2002). Its efforts to date have focused largely on 2D presentations and also on the cataloging of geographic data. As such, the GeoVRML work is well positioned to integrate with the OGC efforts and add Web-based 3D visualization capabilities to this initiative; for example, SRI has produced an OGC-compliant Web Map Server (WMS) that can produce results in GeoVRML format as well as the more common GIF and JPEG image formats.

Additionally, the GeoVRML working group is contributing to the evolving X3D development. X3D is the next-generation VRML specification and supports extensibility through a number of profiles that can be plugged into a core browser (Daly and Williams, 2002; Bietler et al., 2002). The GeoVRML nodes have already been added as a Geospatial profile for X3D and a document type definition (DTD) for this profile has been developed. For further information, see the X3D Web page at http://www.Web3d.org/x3d.html.

Finally, the GeoVRML group is currently compiling issues for a future version of GeoVRML, including support for more coordinate systems, ellipsoid definitions for all other planets in the solar system, new GeoVRML nodes, and additions to various current nodes.

[top]

The TerraVision System

User Scenario

Performance, scalability, and portability make TerraVision (and its associated data) a useful tool for numerous applications, such as military personnel performing mission planning and battle damage assessment, emergency teams fighting a forest fire or organizing disaster relief efforts, environmental workers evaluating a floor, or other time-critical conditions.

Technology Overview

TerraVision Features

• Distributed Data. TerraVision can browse data that is distributed over a wide- area network, e.g., the Web, as well as locally installed data. TerraVision was specifically designed to cope with the inherent unpredictability of accessing data over a network.
• Massive, Scalable Datasets. TerraVision can view massive datasets, in the order of terabytes. It achieves this by employing powerful optimization algorithms including: view frustum culling, terrain and imagery level-of-detail, horizon culling, caching, and prediction.
• Entire Earth Visualization. TerraVision can handle datasets in a variety of geographic coordinate systems, e.g., lat/long, UTM, LVCS, and can transform these on the fly to a round-earth, or geocentric, representation.
• Multiple Datasets. TerraVision can view multiple datasets at once. For example, you can have a 1 km resolution globe model, with a 25 m model of the San Francisco Bay Area, and 1 m inset for Palo Alto.
• Multiple Viewers. TerraVision allows you open up multiple viewer windows. This lets you look at the same dataset from different perspectives at the same time, or different combinations of sets. You can even control the view of one viewer through another.
• GeoVRML Model Overlays. 3D models can be overlaid on the terrain to provide support for cultural features, such as buildings and roads, and atmospheric simulations, such as wind vectors and clear air turbulence models. We use GeoVRML to represent all models with a precise geographic location.
• OGC WMS Support. The OpenGIS Consortium (OGC) developed the Web Mapping Server (WMS) interface as a standard way to serve and integrate maps over the Web. TerraVision can access data from any OGC-compliant WMS, and we include an OGC- compliant WMS Apache module to serve TerraVision and GeoVRML models.
• Flight Paths. You can set up predefined flight paths by marking a number of viewpoints and then telling TerraVision to fly a path connecting those viewpoints. You can vary the velocity, loop the path, close the loop, and select linear or spline interpolation.
• Viewpoint Bookmarks. If you like a particular viewpoint, for example if you have found your house, then you can bookmark that viewpoint and TerraVision will remember it so that you can fly back to it later, or next time you use TerraVision.
• Heads Up Display. A simple HUD is available to provide information such as viewer location (in lat/long), orientation, number of tiles display, data burst rate, and frame rate.
• Documentation. A Web-based user guide is available to help new users familiarize themselves with the TerraVision system. TerraVision offers Help menus that bring up appropriate sections of this user guide in their Web browser.
• Cross platform. TerraVision is available for SGI IRIX (6.3 and up), Linux, and Windows 98/ME/NT/2000. It is available as a full version with Tcl/Tk interface, a Netscape plug-in, and an ActiveX component for embedded in Microsoft applications such as Internet Explorer and PowerPoint.

Managing Multiresolution Grids

A pyramid is simply a multi-resolution hierarchy for a dataset (DeFloriani, 1989). For example, if an original image is 1024 x 1024 pixels at 1m resolution, then an example pyramid might contain this original image along with down-sampled versions at resolutions of 512 x 512 pixels (2m), 256 x 256 pixels (4m), 128x 128 pixels (8m), and so on. Each image of the pyramid is then segmented into rectangular tiles, where all tiles have the same pixel dimensions, e.g., 128 x 128 pixels as in Figure 11(a). A tile at one level of the pyramid will therefore map onto four tiles on the immediately higher resolution level. That is, the tiles at the higher resolution level cover half the geographical area of the former.

Using this representation, it is possible to recursively resolve certain regions of a dataset in more detail than other regions. For example, in Figure 11(b) we have displayed the lower-right corner in high resolution with the surrounding regions displayed in progressively lower resolution. Assuming a tile size of 128 x 128 pixels, this example requires downloading and rendering only 491 KB (10 tiles) instead of the entire 3.1 MB high-resolution image. If the user is located at the bottom-right corner, then we gain the effect that distant imagery is rendered at lower resolution than near imagery, i.e. we have implemented distance-based LOD.

For simplicity, we have only considered pyramids of images so far. However, the same techniques can be applied to elevation grids, as well as other types of terrain data. By employing a tiled pyramid representation for the geometry as well as the imagery, TerraVision is able to optimize the amount of data transferred over the network, the number of polygons in the scene, and the amount of memory required for texture maps. The effect of this technique is that we only need to fetch and display data for the region that the user can see, and only at a sufficient resolution for the user's viewpoint. This solution scales well to arbitrarily large datasets because it effectively attempts to keep the polygon count constant for any viewpoint.

[top]

Summary

As a fundamental new service on top of the Web, the GeoWeb provides a unique solution for harnessing the power of the Internet. It is based on the way human beings perceive and comprehend their world: geospatially, in three dimensions, and over time. The GeoWeb enables Internet users to navigate, access, and visualize georeferenced data as they would in a physical world, but without the barriers imposed by space and time in the physical world (see http://www.dotgeo.net/).

GeoVRML provides the geosciences field with a rich suite of enabling capabilities that cannot be found elsewhere as a Web browser plug-in. That is, the ability to model dynamic 3D geographic data that can be distributed over the Web and interactively visualized using a standard browser configuration. With the presence of this standard, and the recent emergence of many low-cost 3D accelerator cards for common desktop computers, the scene is now set to allow researchers, educators, and businesses to publish their rich, 3D geospatial products to a wide audience over the Web (see http://www.geovrml.org/).

TerraVision provides a freely available and cross-platform capability to browse massive terrain datasets in 3D. It can browse huge datasets, in the order of terabytes, and these data can be distributed over multiple servers across the Web. It is available as a full application, a Netscape plug-in, and an ActiveX component. The system supports the overlay of 3D GeoVRML models and offers an OGC-compliant Web Mapping Server interface. The tools to generate TerraVision datasets are released as Open Source for anyone to download and augment (see http://www.tvgeo.com/).

References

M. Bietler, M. Bourges-Sevenier, D. Brutzman, P. Diefenbach, T. Parisi, M.Reddy and D. Silverglate (2002). "X3D Architecture and Profiles". Tutorial at the 7th International Conference on 3D Web Technology, February 24-28, 2002.

L. Daly and J. Williams (2002). "Introduction to X3D". Tutorial at the 7th International Conference on 3D Web Technology, February 24-28, 2002.

L. DeFloriani (1989). "A Pyramidal Data Structure for Triangle-based Surface Description". IEEE Computer Graphics and Applications, 9(2), pp. 67-78.

L. L. Hill, G. Janée, R. Dolin, J. Frew and M. Larsgaard (1999). "Collection Metadata Solutions for Digital Library Applications", Journal of the American Society for Information Science, 50(13): 1169-1181.

Y. Leclerc, M. Reddy, L. Iverson, and M. Eriksen (2001a). "The GeoWeb (aka dot-geo) --- Indexing Data on the Internet by Location". Digital Earth 2001, New Brunswick, Canada, 24- 28 June 2001.

Y. Leclerc, M. Reddy, L. Iverson, and A. Heller (2001b). "The GeoWeb --- A New Paradigm for Finding Data on the Web". In Proceedings of the International Cartographic Conference (ICC2001), Beijing, 6-10 August 2001.

Y. Leclerc, M. Reddy, L. Iverson, M. Eriksen, and A. Heller (2000). "The .geo-web: A Scalable Index for the Digital Earth". In Proceedings of GIScience 2000, Savannah, Georgia. October 28-31, 2000

Y. Leclerc, M. Reddy, L. Iverson, N. Bletter (1999). "Digital Earth: Building the New World", In proceedings of the 5th International Conference on Virtual Systems and Multimedia (VSMM'99), pp. 250-262. 1-3 September. Dundee, Scotland.

Y. G. Leclerc and S Q Lau (1994). TerraVision: A Terrain Visualization System. Technical Report Technical Report 540. SRI International. Menlo Park, CA. April 1994.

D. Luebke, M. Reddy, J. Cohen, A. Varshney, B. Watson and R. Huebner (2002). "Level of Detail for 3D Graphics", Morgan Kaufmann Publishers, San Francisco, CA.

J. de La Beaujardière (Editor). "OpenGIS Web Map Server Interface Implementation Specification," 16 Jan 2002. http://www.opengis.org/techno/implementation.htm

M. Reddy, L. Iverson, Y. Leclerc, and A. Heller (2001). "GeoVRML: Open Web-based 3D Cartography". In Proceedings of the International Cartographic Conference (ICC2001), Beijing, 6-10 August 2001.

M. Reddy, L. Iverson, and Y. G. Leclerc (2000a). "Under the Hood of GeoVRML 1.0". In Proceedings of Web3D-VRML 2000: The Fifth Symposium on the Virtual Reality Modeling Language. Monterey, California. February 21-24, pp. 23-28.

M. Reddy, L. Iverson, and Y. Leclerc (2000b). "GeoVRML 1.0: Adding Geographic Support to VRML". GeoInformatics, Volume 3, September 2000.

M. Reddy, Y. G. Leclerc, L. Iverson, N. Bletter, and K. Vidimce (1999a). "Modeling the Digital Earth in VRML". In Proceedings of SPIE - The International Society for Optical Engineering. Volume 3905, pp. 113-121.

M. Reddy, L. Iverson, Y. G. Leclerc (1999b). "Enabling Geographic Support in Virtual Reality Modeling with GeoVRML", Cartography and Geographic Information Science. 26(3):180.

M. Reddy, Y. G. Leclerc, L. Iverson, and N. Bletter (1999). "TerraVision II: Visualizing Massive Terrain Databases in VRML". IEEE Computer Graphics and Applications (Special Issue on VRML), 19(2): 30-38.

The Virtual Reality Modeling Language. International Standard ISO/IEC 14772-1:1997. 1997.