Discovering, Modeling, and Visualizing
Yvan G. Leclerc Martin Reddy
Global Grids over the Internet
SRI International, Menlo Park, CA 94025, USA.
Leclerc, Y. G., Reddy, M., Iverson, L., & Eriksen, M. (2002). Discovering, Modeling, and Visualizing
Global Grids over the Internet. In M. Goodchild and A. J. Kimerling
(Eds.), Discrete Global Grids. Santa Barbara, CA, USA: National Center
for Geographic Information & Analysis.
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.
This chapter presents a collection of integrated tools that address the
problems of discovering appropriate global grid data on the Internet, modeling
associated 3D data in a standards-based file format that supports accurate
georeferencing, and producing compelling 3D visualizations of all these
where data can be progressively streamed over the Internet. We begin by
describing the GeoWeb infrastructure, a distributed geographic index for
the Web built on top of the Domain Name System (DNS). We then describe the
GeoVRML file format, an open extension to the Virtual Reality Modeling Language
(VRML) that supports geographic coordinate systems and fusion of disparate
data sources. Finally, we describe our TerraVisionTM terrain visualization
system, a cross-platform application for browsing massive multiresolution
terrain databases over the Web in 3D.
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.
The GeoWeb Infrastructure
The Web has revolutionized the way documents are published, found, and viewed.
This revolution has succeeded in part because Web protocols and publishing
standards are open, and there exist freely available tools for publishing
and reading Web documents. Just as importantly, powerful search engines
let users find documents of interest almost instantaneously. Without these
search engines, the Web would be almost useless.
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
GeoWeb Design Principles
The GeoWeb is a distributed searchable database of metadata. It comprises
the metadata standard, the distributed searchable database in the form of
a DNS hierarchy of servers, and an API library for publishing, searching,
and validating/endorsing metadata in the servers. The GeoWeb is designed
according to a few basic principles, similar in many ways to the Alexandria
Digital Library (see http://www.alexandria.ucsb.edu/):
- 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.
- 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.
- 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.
- 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.
- 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).
- 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).
- 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.
As the concepts that lead to the GeoWeb have developed, it has become clear
that we have a somewhat different view of what may be considered georeferenced
information and thus envision a very different kind of metadata than is
traditional. Traditional metadata (e.g., Dublin Core, FGDC, or ISO/TC211)
usually describe a particular, single data item or service (e.g., a single
Web site, Web page, aerial image, or photograph). The searchable metadata
we have been developing are different from this in a fundamental way: we
wish to provide a semantic and geographical description of physical or conceptual
objects that may have a number of different manifestations as data or services.
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
Many objects that might gain some advantage by being registered in the GeoWeb
do not have fixed positions at all, and it is their current position (and
potentially history and planned future of movement) that should be reflected
in the GeoWeb. These dynamic objects require a different interface to maintain
their positions in the GeoWeb hierarchy and their associated geographic
domain names. One must design a facility whereby an intermediate directory
server can manage the metadata for such objects based on a globally unique
object identifier instead of geographic location. This intermediate server
then translates updated locations to the appropriate geographic domain name
and updates the metadata in the GeoWeb hierarchy, taking care to remove
metadata entries when they dynamically move out of particular cells. These
intermediate servers may be either public or private (depending on the need
to advertise or hide the object-ID to metadata mapping) and may offer other
associated services. By structuring the solution this way, all of the distribution
and localized discovery advantages of the GeoWeb architecture are retained
while allowing dynamic objects to efficiently update their locations.
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
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
To ensure the accuracy and validity of certain classes of data for certain
purposes (such as elevation data used for city planning purposes), the metadata
record has a field for one or more optional validation certificates issued
by validation organizations. The digitally signed certificate will certify
that one or more elements of the metadata/data meet certain qualifications,
such as accuracy or completeness, or compliance with local, national, or
international standards or conventions. While essential for validation purposes,
this facility also has a number of other uses, such as for reviews. For
example, an organization such as the American Automobile Association could
annotate hotel and restaurant listings with references to their own independent
descriptions of the facilities and quality of service that these businesses
provide. Clearly this facility has further implications for security and
privacy than those already outlined above.
The GeoWeb infrastructure offers a number of advantages over today's state-of-the-art
technology. It is specifically designed as an extremely scalable, open,
and global geographical index to the Web. Below are a few of the key benefits
of this technology.
- 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
- 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.
Naturally, users will not normally browse the GeoWeb by typing in domain
name addresses such as 11e21n.3e7n.30e10n.geo. The benefit of the
GeoWeb is that a client application or portal can trivially work out the
server to contact for any given region of the earth. A range of possible
GeoWeb clients can be envisioned. The following sections introduce a few
of the interfaces that are proposed or are already under development.
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 ™
or iPad ™, 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
TerraVision: TerraVision ™ 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.
The GeoVRML Standard
Dealing with 2D maps and simple feature overlays has long been a common
task for traditional Geographic Information Systems (GISs). However, enabling
interactive, accurate, and dynamic 3D visualizations of geospatial data
that can be disseminated over the Web is only now becoming a reality. The
GeoVRML working group of the Web3D Consortium recently announced an extension
to the ISO standard Virtual Reality Modeling Language (VRML, 1997) to enable
just these capabilities. This extension is called GeoVRML 1.0 (Reddy et
al., 2001; Reddy et al., 2000a; Reddy et al., 1999b). GeoVRML is an official
recommended practice of the Web3D Consortium and is included in an upcoming
amendment to the VRML97 ISO 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.
A number of companies have developed tools that support the GeoVRML file
format. These include modeling tools that can export to GeoVRML, conversion
tools to take standard mapping products and produce GeoVRML representations
of these, and visualization technologies that allow the user to browse GeoVRML
content. The follow sections present a selection of these tools. More examples
can be found from the GeoVRML home page (http://www.geovrml.org/).
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/.
The following list provides a high-level description of the capabilities
that are specifically addressed by GeoVRML 1.0.
- 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/).
- 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.
- 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.
- 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.
- 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.
- 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.
Essentially, GeoVRML 1.0 consists of ten new extensions, or nodes, that
sit on top of VRML97, i.e. GeoVRML includes all of VRML97 as a subset. These
nodes are defined using VRML's EXTERNPROTO extensibility features. For the
purposes of the initial sample implementation, these nodes have been implemented
using Java class files that are embedded within the new nodes; although
we have already noted that at least one commercial VRML browser has now
implemented these nodes natively. The following sections detail a small
selection of the nodes that are provided by GeoVRML 1.0 (Reddy et al., 2000b).
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
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
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
GeoVRML 1.0 is currently an accepted recommended practice of the Web3D Consortium.
In addition to this, the GeoVRML nodes have been submitted to ISO as part
of an amendment to the VRML97 specification. The intention is that these
capabilities will eventually become an optionally implementable part of
the current VRML ISO specification, and also an additional profile in any
future revisions of the specification.
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/
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.
TerraVision is a system for interactively browsing 3D representations
of large geographic areas (Leclerc and Lau, 1994; Reddy et al., 1999). It
was developed in response to shortcomings in other systems that can only
browse terrain data from local disk resources, and hence are limited by
users' ability to store and maintain entire datasets locally. TerraVision
can therefore retrieve and merge massive volumes of remotely located data,
including aerial and satellite imagery, topography, weather data, buildings,
and other cultural features (see Figure 10). These data can be terabytes
in size, distributed over multiple servers across the Web, and can be automatically
discovered using the GeoWeb technology described earlier in this chapter.
The user starts TerraVision and sees a 3D view of the Earth. As the user
travels around the globe, browsing for a particular area, TerraVision automatically
fetches data distributed across many sites throughout the Internet by querying
the GeoWeb. The user flies down to ground level and is able to find all
nearby restaurants, places of interest, and even the local garage sales
on that day.
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.
To interact with massive, remotely located repositories in real-time, TerraVision
employs a tiled, multi-resolution data representation (described in detail
below). This involves segmenting the original data into rectangular tiles
over a range of resolutions, where each tile contains the same number of
pixels or elevation data. By employing customized caching, culling, and
data fetching optimizations, the number of polygons and texture maps required
for rendering remains approximately constant, independent of dataset size
and the viewpoint. Tiles are requested for an area using a coarse-to-fine
progression so that TerraVision always has low-resolution data for the area
of interest. TerraVision supports the open standard GeoVRML format for representing
building, weather, and other 3D entities. TerraVision handles multiple types
of imagery; allowing the user to select or blend between different datasets,
e.g., full aerial and weather Earth models where parts of the surface will
have imagery down to 1 m resolution. The user can navigate the terrain data
with standard software on a personal computer connected to the Internet.
A user can employ a graphics workstation connected to a fast network with
high-speed disk servers to quickly navigate around a large area, but can
also access this same data from a laptop machine over a wireless link when
working in the field.
- 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,
- 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
- 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
Managing Multiresolution Grids
Level of detail (LOD) is the technique of changing a model's complexity
based upon some selection criteria, such as distance from the viewpoint
or projected screen size (Luebke et al., 2002). The basic premise for these
two selection criteria is that any distant detail that projects to less
than a single pixel on the screen will not generally be visible. In order
to implement this, we need a mechanism to simplify the geometry and imagery
for a dataset. Several polygon simplification algorithms exist that work
well for terrain. However, many of these are view independent techniques
that force the same degree of simplification across the entire terrain.
These are not appropriate for our application because switching to the highest
resolution would still involve loading every point of the original dataset.
Instead, we require a view independent technique where the degree of simplification
can be varied with respect to the current viewpoint. This is often done
using a hierarchical data structure, such as a quad-tree. A further requirement
is that the LOD algorithm must not require access to the entire high-resolution
version of the dataset. This is necessary because we do not want to be limited
to viewing only datasets that can fit onto the user's local storage system.
These requirements suggest that a tiled, pyramid representation is best
suited to our needs.
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
Three tools have been developed to solve the problems of discovering, modeling,
and visualizing global grids and associated data.
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/).
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,
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.
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
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.
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
The work performed by SRI International was funded in part by the Defense
Advanced Research Projects Agency (DARPA) under contracts MDA972-97C-0037,
subcontract 12165SRI of contract no. F19628-95-C- 0215), and MDA972-99-C-0011.
The views and conclusions contained in this document are those of the authors
and should not be interpreted as representing the official policies, either
expressed or implied, of the Defense Advanced Research Projects Agency,
the United States Government, or SRI International.
1. The work performed by SRI International
was funded in part by the Defense Advanced Research Projects Agency (DARPA)
under contracts MDA972-97C-0037, subcontract 12165SRI of contract no. F19628-95-C-0215),
and MDA972-99-C-0011. The views and conclusions contained in this document
are those of the authors and should not be interpreted as representing the
official policies, either expressed or implied, of the Defense Advanced
Research Projects Agency, the United States Government, or SRI International.