Peter Berger, Paul Meysembourg, Jim Sales, and Carol Johnston

Geographic Information Systems depict spatially-distributed data as they would be shown on a map: two-dimensional surfaces viewed from nadir via a high platform, with spatial objects represented by different patterns and colors. However, humans located in an actual landscape view features much differently: the land surface is undulating, vegetation is three-dimensional and has characteristic structures, objects appear smaller in the distance, and features are located above, below, and around the observer. Consequently, many people find it difficult to visualize the data represented by a GIS.

We are developing a software interface which combines the visualization capabilities of virtual reality with the spatial display capabilities of GIS. Landscapes are rendered as perspective views using actual elevation and land cover data, such that they depict realistic scenery. The user can specify a vehicle (e.g. airplane, all-terrain machine) and a path for travel, viewing landscape features from different perspectives. We use the term "virtual reality" to denote a system which provides the tools for users to interact with a simulated environment, but not necessarily in real time.

The ultimate goal of the research is to develop a prototype virtual reality interface with data from the Mid-Atlantic Integrated Assessment (MAIA) region, in support of the U.S. EPA's Environmental Monitoring and Assessment Program EMAP). The MAIA region falls in the states of PA, VA, WV, DE, NJ, and MD, and the District of Columbia, and includes the entire Chesapeake Bay watershed. Virtual rendering is being accomplished with two basic datasets: (1) digital elevation models (DEMs), and (2) land cover data derived from classified satellite imagery. Specific technical objectives are:

1. Interface DEM with virtual reality software.
2. Drape classified land cover over DEM.
3. Set camera location, elevation, and view angle.
4. Render image, enabling 3-D structures.

Vistapro renders realistic scenary by level slicing the landscape color palette to realistically shade cliffs and hills. It does this through user definable variables, a rules system, fractals, and chaotic math to add non-uniform textures to the rendering (Virtual Reality Laboratories, 1993). Lifelife landscapes are depicted despite a limited number of possible terrain types: water, beach, vegetation, bare, snow, cliff, and buildings.

Input data for defining landscapes can be DEMs and/or PCX files. PCX is a standard graphic file format commonly used by Paint programs in Windows applications. Landscapes can be built using only DEMs, only PCX files, or a combination of both. When only DEMs are used, terrain types are defined based on elevation (Fig. 1). For example, low, intermediate, and high elevations could be defined as water, vegetation, and snowfields, respectively. Alternatively, the white and tan colors of snowfields and bedrock on a PCX- format aerial photo of a mountaintop could be used to define those areas as user-defined elevation ranges, as well as terrain types. When both DEM and PCX files are used, the DEM is used to generate topography, and the PCX file is used to generate land cover.

Although Vistapro generally worked well for our purposes, importing GIS data into Vistapro was not straightforward, requiring the development of special protocols and the use of other software packages to pre-process the data (see Results).

Two types of land cover data, both derived from satellite imagery, were draped over the DEM-generated landscape: (1) the Conterminous U.S. AVHRR Global Data Set, and (2) the Chesapeake Drainage Basin Land Cover Grid. The first data set was produced by the U.S. Geological Survey, and consists of 1-km resolution data derived from AVHRR satellite imagery, classified into vegetation types based upon spectral reflectance values and seasonal onset of greenness (Eidenshink 1992). The second data set was produced at the EPA EMSL-Las Vegas Laboratory from Landsat TM data (30 x 30 m pixels) of the Chesapeake Bay region, and consisted of six land cover classes: high-density developed, low- density developed, woody, herbaceous, exposed land, and water.

Table 1. Software packages used.

Files in PCX format with up to 8 colors can be used to define terrain types in Vistapro, each color representing a different terrain class. Vistapro uses these classes to generate shading patterns and 3-D objects associated with particular vegetation types. To ensure that the colors in the land cover files corresponded with the desired terrain type, we converted them to a TIFF format and imported them into XV, a UNIX graphics utility, for color manipulation. After color editing, we ported the files to a PC and converted them from TIFF to PCX using Graphics Workshop, a shareware graphics conversion utility that runs under Windows 3.1.

Files to be overlaid had to be aligned before importing them into Vistapro. Vistapro uses row and column addresses rather than true geo-referencing, so it was necessary to create DEMs and land cover files covering exactly the same area and with exactly the same number of rows and columns. There were several steps involved in this procedure.

The first step was to georeference the DEMs and land cover datasets. We used ARC/INFO GRID to perform this georeferencing, but also had excellent results with ERDAS IMAGINE (ERDAS, Inc., 2801 Buford Highway, NE, Suite 300, Atlanta, Georgia 30329-2137), particularly for scanned aerial photographs or USGS 7.5' topographic maps.

The second step was to resample the files so that the cells in each dataset were of the same size and aligned exactly. The cells in the 1:250,000 DEMs were approximately 90 x 90 m, whereas the cells in the Landsat TM-derived land cover layer were 30 x 30 m. This was also done using ARC/INFO GRID.

The third step was to change the nodata values (-9999) of the DEM file to a value equal to one less than the lowest elevation in the DEM. If this is not done, Vistapro uses the -9999 value as elevation, thus severely distorting the landscape.

The fourth step was to clip both datasets to one of four standard sizes used for display by Vistapro. This step was essential because Vistapro displays DEMs and PCX files differently: DEMs are centered within the display screen, whereas PCX files are justified with the lower left corner of the display window. Vistapro pads the edges of files with 0 values if the rows and columns don't match one of its four standard sizes, which also causes misalignment of overlaid datasets. The clipping was done with the row and column references used by Vistapro, rather than actual locational information. After these procedures were done in ARC/INFO GRID, we exported the DEM into an ASCII format, and passed it through the import/export process in SAGE Capture (see Objective 1).

The script file generated by Makepath is a comma delimited ASCII file with one record per frame defining camera x, y, and z coordinates, heading, pitch, and angle of view. Vistapro uses the scripts to generate individual frames which can then be played back as an animation. Makepath permits only a limited range of motion consistent with the vehicle type chosen, and uses the elevation of the DEM to determine the elevation of the path for every frame.

The ASCII script file that Makepath generates can be edited to vary elevation along the chosen route or to simulate other types of motion. We used the Microsoft Excel 5.0 spreadsheet program to edit the script file, simulating a parachute jump into Crater Lake and a space capsule zooming into an entire 1:250,000 DEM quad. Neither of these vertical drops are inherent to Makepath. Several iterations were usually needed to fine tune the desired path. At this trial and error stage, low detail and course resolution were used to get a feel for the visual results of the fly-by because of the long amount of time required for final rendering (see Objective 4). Script editing can also be used to reduce rendering time by decreasing the detail and quality of files produced.

Computer performance was an important determinant of rendering speed. Although the minimal hardware requirements for the DOS version are a 386 with a VGA display, 4 Megabytes of RAM and 3 Megabytes of hard disk space, more powerful equipment provided much faster results. Rendering speed benchmark tests were performed using the Vistapro supplied DEM of Crater Lake (258 x 258 cells) on three different computer configurations (Table 2). Display modes were all set at 8 bit VGA 320 X 200 resolution. Results of the rendering speed benchmark tests are shown in Table 3.

Table 2. Computers used in benchmark tests. Speed tests were done with the Norton Integrator Software Advanced Edition, Version 4.50.

The ability to render very accurate 3-D structures was important in our decision to use this software package. Fractal generated trees were used with various controllable settings such as: light source and direction, density, size, detail, and colors. These also affected the time required to produce the final output. Generating many fractal trees was extremely time consuming, but the visual results were well worth it (Fig. 3).

Virtual reality renderings are computationally intensive, so it was not possible to make our applications interactive in real time with devices such as a headset or data glove. As the power available on consumer-grade desktop computers increases, however, progressively more realistic presentations become possible using ubiquitous hardware. These hardware advances have enabled a generation of low cost visualization and virtual reality software packages for the experimenter. Although the results of these low cost solutions only approximate the realism (measured in rendering detail and speed) available on high-end platforms, some are now good enough to enable serious work, and the results obtained can be improved markedly simply by moving the software to faster hardware as it becomes available.

At the extreme, virtual reality promises a fully immersive environment which fully engages all the user's senses and provides full interactivity in real time. At the minimum it provides a visualization environment that encourages a user to imagine being within the virtual world -- to suspend disbelief in the simulation. At this stage in our project, user interaction is limited to importing digital elevation and land use data and navigating within the resulting environment. Once we complete experiments with our prototype, we plan in later stages to port our model from Vistapro to a more open-ended virtual reality software package, which will allow us to effect changes to the model from within the virtual environment.

Virtual Reality Laboratories, Inc. 1993. Vistapro User Guide, IBM DOS Version.