Adding dimensions to GIS with VRML

June 6, 2000
Share

Sharing is Caring

A presentation delivered at the annual Pennsylvania GIS Conference in Hershey, PA, June 1, 2000.

Abstract

This presentation shows how to create three-dimensional visualizations using commonly available and inexpensive tools. Objects can be queried and modified by the user and linked to underlying data, providing a GIS-like environment in three dimensions.

A standard web browser equipped with any one of many freely available "plug-ins" can become an interface into a three dimensional virtual reality. The software presents so simple an interface -- typically simpler than game software -- that most people require little practice to use it effectively.

VRML 2.0 is the present standard (ISO/IEC 14772-1:1997) for describing three-dimensional worlds on the web. Its distinguishing features are:

  • A VRML document consists of ASCII text. It can be read and modified in any text processor.
  • The document simply describes objects such as boxes, spheres, cylinders, and more complex things such as extruded surfaces, polylines, and "2.5D" surfaces.
  • There exists a facility (the "PROTO" construct) allowing you to hide the geometric complexity of the description.
  • VRML objects can interact with each other, driven either by a virtual clock or by user interaction.
  • VRML objects can be linked to text data or other web pages.
Most 3D software applications, such as ESRI's 3D Analyst add-on to ArcView, will create VRML output. However, this output (being program generated) tends to be large and cumbersome, often unusable for web delivery. Once you get started, it's actually easier to create effective VRML representations yourself using much simpler tools. (With some guidance, a third-grader was able to create a significant VRML world in an hour using only a text processor.) The output becomes small enough and efficient enough to be of practical use for serving GIS data in three dimensions over the web.

Contents

Introduction
How VRML works
Quick tutorial
A data visualization model
Visualizing GIS data with VRML
Discussion
Conclusion
References

Introduction

A Geographic Information System provides access to data that are keyed to a place and time and supports the visualization and analysis of those data. Place and time require four dimensions--two map coordinates, elevation, and time--but most GIS software inherently supports only the map dimensions. Elevation and time are handled by ad-hoc methods or specialized expensive software. Access to data, especially using Web technologies, typically is limited to map-based access.

This talk describes an existing, accessible, free technology to provide access to the third spatial dimension. (The fourth dimension--time--will be the subject of a future talk.) The technology is VRML, Virtual Reality Modeling Language. VRML was designed to enhance hypertext markup (html) documents to deliver truly three-dimensional "virtual worlds" efficiently to unsophisticated users over the Web. As an add-on to html, VRML acquires the capability to link user actions to other documents, thereby providing GIS-like access to data.

The principal "discovery," if you will, presented here is that VRML can easily be deployed using technologies no more complex than a spreadsheet or software with simple scripting capabilities. In particular, VRML is a viable technology for enhancing 2D GIS software.  The examples shown in this article are real.  They have all been created for actual projects, they display real data, and they have been delivered to clients, collaborators, and government agencies via the web.

How VRML works

A VRML document, like an html document, is a formalized text description of a Web page's contents. Unlike html, VRML is not "marked up" text. Its contents are descriptions of three-dimensional objects and their interrelationships.

In some sense, a VRML document is a 3D "shapefile": a universal way to store 3D shapes and their connections to other data. It goes beyond this, though, in also providing information about how those shapes look and how they interact with each other and with the user. It can also contain additional information such as the user's initial point of view, what lights are available, the background, and other contextual information.

You build a VRML world one piece at a time using "node" constructs. The most fundamental is the shape node. A shape node in turn contains a geometry node and an appearance node. A geometry node describes the shape of an object; an appearance node describes how it will look when lit: its color, how it reflects (or transmits) light, and its texture.

That's about all you need to know to get started, apart from a few simple details. First, a VRML "world" file ends with a "wrl" extension. Second, you need to put a magic line at the very beginning to identify your file as a legitimate VRML source. This "mantra" is

#VRML V2.0 utf8

Just put this at the beginning of a text file, provide it a .wrl extension, and you've done the hard part.

Here is a complete working VRML world:

#VRML V2.0 utf8
Shape {
  geometry Sphere {
    radius 1
  }
}#end Shape

(The lines previously introduced are grayed out, but are still required to be there.) It's easy to tell that it is a sphere of unit radius. The browser will provide a default position and default appearance parameters, typically a bright white diffuse surface. It will also provide a standard light and a simple interface for "handling" the sphere or for moving around the space surrounding the sphere.

The syntax is straightforward. A node has a special name (it is case sensitive!) followed by properties within curly brackets. The indentation and line breaks are not required but are useful for readability. Comments begin with a pound sign '#'.

A quick tutorial: building snowmen

Maybe this little white sphere doesn't look like much, but it signals infinite possibilities. Eleanor, my young daughter, quickly identified it as a snowball. And what do you do with a snowball? "Make a snowman."

We will do this in tiny steps, just as Eleanor did. Our goal is not to make snowmen--a trivial application indeed--but really to acquire enough tools to begin visualizing data.

What a child does with snow, we must do with our little virtual spheres: create them (and make them look realistic), size them, and assemble them. Once we learn that, we will want to automate snowman-making. Having mass-produced several snowmen, we will name them and deploy them.

Color and material

VRML uses the RGB (red, green, blue) model to specify colors. Thus 1 0 0 is pure red, 0 1 1 is cyan (an equal mixture of green and blue), 0.5 0.5 0.5 is 50% gray, and 0 0 0 is black.

The color is part of the appearance, so we insert an Appearance node into the Shape's description:

#VRML V2.0 utf8
Shape {
  geometry Sphere {
    radius 1
  }
  appearance Appearance {
    material Material {
      diffuseColor 1 0.9 0.9  # Light pink
      emissiveColor 0 0.7 0.7 # Medium cyan
      transparency 0.3        # Partially transparent
    }#end material
  }#end appearance
}#end Shape

Just like the syntax for the geometry was the keyword "geometry" followed by a particular kind of geometry (a Sphere node), the syntax for the appearance is the keyword "appearance" followed by another VRML node (an Appearance). This looks redundant but actually makes some sense. The "geometry" keyword is one of a Shape node's fields; the Sphere node following "geometry" is that field's value, which is another node.

Likewise, this Appearance node is the value of the Shape's appearance field. Evidently it describes the colors of the shape's surface. It could also describe a texture, which maps an image onto the shape's surface, but we have elected not to do that here.

The Material node (which is the value of the Appearance node's material field) contains information about the object's colors (there are three: in addition to its diffuse color, which describes how the surface reflects non-directional light, an object may have a specular color, which is the color of its reflected highlights, and it may have an emissive color, which glows from within the object on its own). The transparency value ranges from 0 (opaque) to 1 (completely transparent). The default is 0. I like to begin with slightly transparent objects so I can see how they fit together (see Assembly below). Later on, as you will see, it will be easy to make all objects opaque if you wish.

VRML is pretty friendly about some things: the order in which you specify fields in a node does not matter.

 

View the light pink glowing sphere.

Don't have a VRML plug-in? Download the best one here, Cosmo Worlds 2.1.

Size and position

OK, so we've made a new-age glowing virtual snowball. It's time to put that skill to work in building up a snowman. We will have to make three snowballs, in three different sizes, and stack them on top of each other.

You can already see there's a lot of fluff in VRML: all those redundant field name-node name sequences andthe deep hierarchies of curly brackets, just to specify a few. Creating just one snowman threatens to take a lot of typing. (Eleanor prides herself on her touch typing, which she is just learning, so she insisted on typing all this stuff herself--at about one word per minute. She and I have special incentive to keep the files short!) Since the key to good programming is to be lazy, we're going to jump ahead now to the automation step.

Automation: the PROTO construct

We're going to make some minor changes to the previous code and turn it into a prototype, or template, for future snowballs. This basically means replacing some of the specific characteristics by variables. I have chosen to vary the surface color and sphere radius, simply to illustrate some of your options:

#VRML V2.0 utf8
PROTO Ball [
  field SFFloat radius 1
  field SFColor color 0 1 1 # Default is cyan
] {
Shape {
  geometry Sphere {
    radius IS radius
  }
  appearance Appearance {
    material Material {
      diffuseColor IS color
      emissiveColor 0 0.7 0.7
      transparency .3
    }#end material
  }#end appearance
}#end Shape
}#end Ball

Ball {color 1 0.9 0.9}

This VRML code creates exactly the same object as before, but in a way that will permit mass-production of copies. The inner lines, from the "Shape {" line through the "} #end Shape" line, are exactly the same as before, except that the diffuseColor value "1 0.9 0.9" has been replaced by "IS color" and the radius of "1" has been replaced by "IS radius". I chose the names "color" and "radius" that appear in "IS color" and "IS radius"; I could have called them "Jeff" and "Bob" had I wanted. The keyword "IS" must be there and it must be all in caps. I hate these restrictions, but that's the way it works.

The "PROTO" section declares my names and gives a name to the template ("Ball"). It also provides default values in case I don't care to specify them later (more laziness, always a good thing). The "field SFFLoat radius 1" line states that "radius" names a floating-point value to be filled in later and that its default value is 1. The "field SFColor color 0 1 1" line does the same for "color".

Thus, all but the last line of this VRML file creates a prototype for a unit-radius sphere, cyan in color, glowing in darker cyan and slightly transparent. It does not actually create anything. That is done by the last line, "Ball {color 1 0.9 0.9}". That line tells the browser that you want it to create a single "Ball" object using the value "1 0.9 0.9" (light pink) for its "color".

Now, having set up this prototype, we can create snowballs using a single, compact, line of code. For the price of typing the declaration statements, we have reduced snowball construction from 12 lines to one. Calvin would be proud. It's time to go into production.

Size and position, continued

To position an object, you tell the browser how to move it. Not where, how. Consider Eleanor's snowman, who has a base, a torso, and a head. You can create the parts for a snowman in three lines using our "Ball" prototype:

Ball {radius 1.2 color 1 1 1}    # Base
Ball {color 1 1 1}               # Torso
Ball {radius 0.7 color 1 1 1}    # Head

(Of course you would precede these lines by the PROTO construct shown in the preceding section.) Each of these balls, however, would appear at the same location. By experimentation, Eleanor and I learned that we needed to lift the torso 1.3 units above the base and the head 2.5 units above the base to make a proper-looking snowman (she decided).

Moving things around in three dimensions requires three coordinates. VRML begins with the usual X and Y coordinates: X is to the right, Y is up. It simply adds the third, Z, coordinate pointing up out of the screen. Therefore, to "lift" the torso--move it upwards on the screen--we simply want to add 1.3 to its Y coordinate and leave the other coordinates unchanged. This is specified by the translation vector 0 1.3 0.

VRML uses a "Transform" node to move and resize objects. One field in this node, "children", describes a collection of objects to be transformed together. The other fields describe a rescaling (non-uniform change of size), translation, and rotation about a specified center point.

Eleanor assembled her first snowman with this VRML code (some of the previous lines have been omitted):

#VRML V2.0 utf8
PROTO Ball [
... 
}#end Ball

Ball {radius 1.2 color 1 1 1} # Base

Transform {
  translation 0 1.3 0
  children [
    Ball {color 1 1 1}    # Torso
  ]
}

Transform {
  translation 0 2.5 0       # Head
  children [
    Ball {
      color 1 1 1
      radius .7
    }
  ]
}

The only thing new here is the use of square brackets [] to enclose a list of objects. These lists are the values of the "children" fields. (In this example the lists have exactly one object, but often they have more.)  I have illustrated various ways to use indentation and new lines to enhance readability.

Assembly

VRML lets you group collections of objects into complexes of objects. Our snowman will be a group of snowballs To create a collection of snowmen, we will first define a snowman prototype based on the Ball prototype. As before, this is done by slightly modifying the preceding code:

PROTO Snowman [
  field SFColor color 1 1 1
] {
Group {
  children [
    Ball {radius 1.2 color IS color}
    Transform {
      translation 0 1.3 0
      children [
        Ball {color IS color}
      ]
    }
    Transform {
      translation 0 2.5 0
      children [
        Ball {
          color IS color
          radius .7
        }
      ]
    } #Transform
  ] #children
} #Group
} #end Snowman

The syntax for the Group node is similar to that of the Transform node.

This PROTO section belongs in the VRML file just after the PROTO Ball section. Following it you can create a snowman with one simple line of code:

Snowman{}

Using Transform nodes you can create a collection of snowmen with a few swift strokes:

#VRML V2.0 utf8
PROTO Ball [
...
}#end Ball
PROTO Snowman [
...
} #end Snowman

Snowman{}      # First snowman
Transform {    # Second snowman
  translation -3 0 0
  children [
    Snowman{color .75 1 1}
  ]
}
Transform {    # Third snowman
  translation -6 0 0
  center 0 -1.2 0
  scale 1.2 0.8 1.2
  children [
    Snowman{color 0 1 1}
  ]
}
Transform {    # Fourth snowman
  translation -9 0 0
  children [
    Snowman{color 0 .7 .7}
  ]
}

These translations move the snowmen to the left (negative X values). Eleanor made the snowmen different colors to differentiate them. Just for fun, we have made a short fat cyan one: it has been scaled to 20% larger in the X (side to side) and Z (in and out) directions and 20% smaller in the Y (up and down) direction.

The "center" field deserves some comment. Our snowmen have their bases along Y = -1.2 because their bodies are spheres of radius 1.2 centered at 0 0 0. The center field told the browser to shrink this snowman while keeping the bottom of his base fixed.

 

OK, so they're missing some features. You can practice your new VRML skills by adding whatever's missing: eyes, mouths, arms. Right-click on the picture and save it as a .wrl file on your computer. Edit it with any text editor--Wordpad, Notepad, VI, whatever you have.

Naming (linking)

We will finish by making these snowmen more than mere objects: we will attach data to them.

There are several ways to do this, all through the Anchor node. The Anchor node is another grouping node, like "Group" and "Transform", which assemble collections of objects. It evidently was inspired by the html anchor (<a>). It can have a description, an url, and parameter field. They work like html.

Rather than go into details, I have created an example using four approaches: a description, a link to another VRML world, a link to an html document, and a link to a new browser window. These links can execute Java scripts, if you need more sophistication.

Description
The right-hand snowman (white) has only a description. This is any text you want to have appear when the cursor brushes over him. Look for this in the browser's status line (lower left corner of its window).

Anchor {
  
description "I'm Albert"
  children [
     Snowman{}
  ]
}

Link to a VRML world
The next snowman links to one of the earlier examples. The browser will jump right out of the four-snowman world and right into the example, replacing one world by another.

Anchor {
  description "I'm Bertie--I link to the white snowman world"
  url "snowman.wrl"
  children [
    Transform {
      translation -3 0 0
      children [
        Snowman{color .75 1 1}
      ]
    }
  ]
}

Link to an html document
You saw the pattern in the preceding two examples, so here I will illustrate only the necessary Anchor fields.

description "I'm Charlie--I link to an html document"
url "charlie.htm"

Link to a new browser window

description "I'm Dave--I open a linked document in a new browser window"
url "charlie.htm#Dave"
parameter ["target=_blank"]


So what does this all have to do with GIS?

OK, so a child can build snowmen in 3D on a computer using nothing more than a modern browser with a VRML plug-in. Anybody can do better than that by springing for a commercial 3D world builder program, so what's the point?

The point is that a passing familiarity with VRML syntax and capabilities will let you turn your browser into a functional (somewhat limited, but still functional!) 3D GIS. To show you why and how, I need to digress briefly into some general principles of data visualization.

A data visualization model

A GIS visualizes data by using attributes associated with shapes to (a) determine the graphic qualities of the shape and (b) to modify the shape itself. By graphic qualities I mean all aspects of how an abstract geometric shape may appear: principally, its color (or colors if it can have several) and style (linestyle for 1D shapes, hatching for 2D shapes, symbol for points). Modifications of the shape include changing its orientation, position, size, and even its very nature (complex maps showing charts at shape locations provide a good example).

The process of visualization is therefore a process of converting data attributes into graphic qualities or shape modifications.

Almost every visualization ever produced by a GIS falls within this framework. For example,

  • Choropleth maps associate colors with ranges of an attribute.
  • Dot maps associate point symbols with values of an attribute.
  • Pie chart maps modify the angles within each pie according to values of an array of attributes.
The list can go on and on.

Three-dimensional visualization works the same way. To create a visualization, we do a few simple things:

  1. Create objects (3D "shapes") according to the values of some attributes.  (Sometimes those objects are already defined.  That's ok too.)
  2. Position those objects according to their spatial coordinates.
  3. Geometrically transform (scale, rotate) those objects according to other attributes.
  4. Create an appearance for each object according to yet more attributes.
To make the visualization really come alive, we would also like to
  1. Attach a direct link from each object to a detailed listing of the underlying attributes.
The ability to create these five things--objects, positions, transformations, appearances, and links--is the ability to provide the visualization and data access services for which a GIS is so valuable. (I am leaving aside data management and analysis in this discussion. These are highly useful services that GISes provide for which VRML is not the answer.)

Visualizing GIS data with VRML

VRML is particularly well suited to 3D visualization. In the tutorial you have seen how a VRML file creates objects using Shape nodes, positions and geometrically transforms them using Transform nodes, provides detailed control over appearance using Appearance and Material nodes, and links to anything on the Web using Anchor nodes.

Moreover, by pursuing the implications of the programming laziness principle, I have shown how PROTO constructs can provide an extremely compact means to specify a visualization. It is time to look at a real case.

Case study: 3D visualization of soils concentrations

Investigation of soils at an industrial site had produced measurements of metals at five or more depths within hundreds of borings. Investigators managed the measurements using simple data tables.

 

This is a typical data record. The location name [Location] and sample identifier [S_id] link this record to data found in other investigation documents. [X] and [Y] provide a map position while [Z] indicates the land surface. [Top] and [Bottom] describe the sample's vertical position relative to the land surface. The actual observations are contained in fields like [Chromium] and [Cadmium], [Is Cr ND?] and [Is Cd ND?].

Using 2D GIS we could map the results depth by depth, but the complex relationships we wanted to assess proved to be elusive.

We created a VRML visualization using a spreadsheet! (Microsoft Excel 95). The first step was to create a PROTO for the basic visualization object, dubbed a "glyph". Here is our glyph in its full glory:

#VRML V2.0 utf8
PROTO Glyph [
  field SFInt32 Type 0 # 0 = sphere, 1 = box
  field SFVec3f XLat 0.5 0.5 0.5
  field SFVec3f BSize 1.0 1.0 1.0 # Box size
  field SFFloat Size 1.0 # Sphere size
  field SFColor Color 1 0 0
  field SFFloat Transparency 0.1
  field SFString Desc ""
] {
Anchor {
  description IS Desc
  children [
    Switch {
      whichChoice IS Type
      choice [
        Transform {
          translation IS XLat
         
children [
            Shape {
              geometry Sphere {
                radius IS Size
              }
              appearance Appearance {
                material Material {
                  diffuseColor IS Color
                  transparency IS Transparency
                }
              }
            }
          ]
        },
        Transform {
          scale 2 2 2
          translation IS XLat
          children [
            Shape {
              geometry Box {
                size IS BSize
              }
              appearance Appearance {
                material Material {
                  diffuseColor IS Color
                  transparency IS Transparency
                }
              }
            }
          ]
        }
      ]
    }
  ]
}
}

This is a pretty complex example--usually glyphs are simpler than snowmen. If you look at it closely--don't let the ten levels of indentation intimidate you--you will see this is only one or two steps removed from Eleanor's snowman prototype. The Anchor node is now included in the prototype and there is a new Switch node that lets the browser select among shapes according to the value of a parameter ("Type") provided to it. The second shape is a "Box", which is just a 2 X 2 X 2 cube.

The Glyph provides ways to influence up to 12 of its aspects:

  • "Type" determines the object (0 = sphere, 1 = box)
  • "XLat" determines the position of the object's center (3 parameters)
  • "BSize" and "Size" determine the scale of the object in three independent directions (4 parameters, but only 3 are independent)
  • "Color" and "Transparency" determine the object's appearance (4 parameters)
  • "Desc" provides a link to other attribute data.
Here are two simple examples of how a Glyph might be used later in the VRML file:

#Glyph {Type 0 Desc "Sphere" Color 0 1 0}
#Glyph {Type 1 Desc "Box" XLat 3 0 0}

The first is a green unit sphere located at 0.5 0.5 0.5; the second is a red box, two units in each dimension, located at 3 0 0. Each has self-describing text attached to it.

Visualization is now just a matter of filling in the blanks in the Glyph object. This requires that we establish methods to convert attributes into positions, sizes, colors, and a link.

The position is almost obvious: use the actual coordinates for the position. It turns out in many applications, though, that we should exaggerate the vertical dimension relative to the horizontal. I chose a 10X exaggeration and that we should center the horizontal coordinates within the site. (VRML software typically uses single-precision floating point arithmetic for speed, leading to very 'grainy' behavior when object positions have coordinates in the millions, as they often do with GIS data.)

It is a good idea to make volumes of 3D objects more or less proportional to the data they are representing. Therefore "Size" should be proportional to the cube root of the concentration.

There are many ways to determine color. Usually one uses a numerical attribute to interpolate between two extreme colors. This can be done by interpolating the Red, Green, and Blue components separately.

The description should display quantities of interest: in this case, the sample identifier and the Cadmium and Chromium results.

This looks complex, but it's not bad when one has spreadsheet tools available. You just build the visualization components one formula at a time. This one was done with 13 formulas--essentially one formula per parameter.

For example, the record illustrated above (for the TP-09 sample 0.8 to 1.5 feet deep) became:

Glyph {Type 1 XLat 894.6 11.5 1579.2 BSize 1.429 1.429 1.429 Color 0.036 1 0.964 Desc "Sample TP-9-0.75-1.5: Cr = 18.3; Cd = 0.24"}

When the last spreadsheet column was saved as a text file and appended to the PROTO lines, we had our visualization. Here it is. The entire file displaying 632 records is 80 Kb--about the same size as the original data file.

This is the initial view looking down on the site. The cubes are centered at the sample locations and are proportional in volume to the measured concentrations. They are colored from green (lowest detected concentrations) to yellow (highest concentrations). Nondetects are shown in gray and are sized in proportion to the detection limits.

The semitransparency of the cubes allows tinier cubes (low concentrations) to show up inside neighboring boxes which, because of their sizes, may have "swallowed" them up.

Discussion

The techniques for visualizing point data described in this talk are just the beginning. Also needed, at least for visual reference, are visualizations of polyline and polygon features, extruded polygons, elevation surfaces, and images draped on elevation surfaces.

VRML can do all this, but it takes more effort. Within an ArcView (2D GIS) environment, for example, we have created scripts that can

  • Create glyph maps from point data
  • Create flat line features from polyline data
  • Create extruded polygons (such as buildings and other structures) from polygon data
  • Drape aerial photographs (in jpeg or gif format) over elevation surfaces
  • Create elevation surfaces (using ArcView's Spatial Analyst extension)
  • Produce specialized visualizations, such as detailed borehole logs shown as segmented cylinders
Collectively, these scripts are able to take a two dimensional map and place all its components meaningfully into three dimensions while retaining links to the data.

(Click on the image to link to a larger version, 62 Kb.) This image, produced entirely within the base ArcView GIS software, shows a CAD map as polylines and extruded polygons (the buildings). A portion of the CAD map representing sewer lines (shown in red, just visible in the middle of the image) has been placed at its proper location in the subsurface. All colors are the same as those determined by ArcView legends.

This visualization also documents various observations and measurements. The green slabs display concentration readings in grab groundwater samples; their apparent volumes are directly proportional to the concentrations.

Hundreds of cone penetrometer test borings are shown as cylinders with a 5X vertical exaggeration. Areas interpreted as clays and silts are nearly transparent while areas interpreted as sands and gravels are opaque and colored (at 2-5 cm intervals down to 10 m) according to the Robertson and Campanella (1986) system. (The full visualization of this site displays over 160,000 CPT readings as 80,000 colored bands covering hundreds of cylinders.)  A black and white aerial photograph is also available but was made invisible in this image.

Certainly there are disadvantages to this approach. Writing complex spreadsheet or script formulas, cobbling together different scripts from different programs to process different features, hand-editing VRML documents, and debugging the typographic errors that inevitably creep in are time-consuming and inconvenient. Crafting your own PROTOs is not for everyone.

Nevertheless, we have put these techniques to good use in current projects, some of which (as the previous example attests) offer a wealth of data and require clear visualizations of complex phenomena. Among the advantages we see are

  • The simple web browser interface lets us deliver 3D visualizations to colleagues, clients, and third parties (such as management personnel or regulatory agencies) who are not generally well versed in using 3D software.
  • We can create innovative visualizations beyond the scope of current 3D software output. The ability to hand-craft prototypes is useful.
  • Our approach to visualization fits well even within an environment where 3D visualization software is available. Such software usually can output complex data in VRML format. For example, ESRI's 3D Analyst can create fairly clean VRML renditions of elevation surfaces (TINs). Using that as the foundation, we find it is easy to add other "3D themes" to this output. (VRML has the capability to incorporate one VRML file within another by reference, making it simple to collect disparate visualizations into a coherent whole.)
  • Spreadsheet formulas and VRML prototypes are easy to re-use. You just put new data into the format of the old, paste it into the spreadsheet, and you have an instant 3D visualization. This is a fast way to look at data even when you do not intend to deliver the visualization to anyone. (I predict such capabilities will soon be built right into spreadsheets, but they are not as yet.)
There are aspects of VRML not even touched upon here. One of the most exciting is that VRML 2.0 is designed as a simulation environment. A clock is constantly ticking, triggering "events" that can be passed around among the world's objects. These objects can be made to respond to events using a predecessor of javascript ("ecmascript"). This creates all kinds of possibilities for innovative visualizations: animated objects, objects that interact with each other and with the user, objects that can be manipulated. For the time being, your only access to these exciting possibilities will be by editing VRML worlds yourself.

Conclusion

Creating three-dimensional visualizations is easier than you may have thought and it takes no investment in software to do it. By following the steps and examples here, you can turn GIS data or spreadsheet data into a truly 3D model in an hour. For those with the interest and time to invest, there are capabilities to be found in VRML that go beyond what most 3D software programs are capable of producing.

References

For the details of VRML syntax, node structures, etc., the only place to go is the standard specification. Once you learn some of the terminology and figure out how to get started (hopefully you have by now), then this document (especially the node reference) will become your bible.

There is a VRML FAQ. It was last updated in 1996, but seems current. There apparently has not been much evolution since the adoption of VRML 2.0 in 1996. There is also a FAQ for VRML + Javascript.

The Web 3D Consortium maintains a lot of information and materials on VRML (image translators, object libraries, textures, sound, art...).

The newsgroup is alt.lang.vrml.

Share

Sharing is Caring


Geospatial Newsletters

Keep up to date with the latest geospatial trends!

Sign up

Search DM

Get Directions Magazine delivered to you
Please enter a valid email address
Please let us know that you're not a robot by using reCAPTCHA.
Sorry, there was a problem submitting your sign up request. Please try again or email editors@directionsmag.com

Thank You! We'll email you to verify your address.

In order to complete the subscription process, simply check your inbox and click on the link in the email we have just sent you. If it is not there, please check your junk mail folder.

Thank you!

It looks like you're already subscribed.

If you still experience difficulties subscribing to our newsletters, please contact us at editors@directionsmag.com