Part 2: Nodes and Functions
Part 2: X3D
 More of this Feature
• Part 1: Overview
 Join The Discussion
"animated character..."
 Related Resources
• Tutorials
• Learning VRML
 From Other Guides
• JavaScript
• Animation

Getting back to geocoordinates, the concept isn't that difficult, remember latitude and longitude? Well those are geocoordinates. GeoVRML, enables you to directly use and manipulate lat, long coordinates. The four primary concepts you need to understand to deal with GeoVRML are Geographic Coordinate Systems, Multi-resolution Terrain Representation, Limitations Of Single-Precision, Navigation Issues.

Geographic Coordinate Systems - Most geographic coordinate systems use geodetic systems to specify coordinates. These geodetic system specify a point relative to the sphere which, for example is the earth (more precisely the earth and most other natural objects aren't pure spheres but are an ellipsoid). GeoVRML provides Nodes to allow authors to directly use geographic coordinate systems.

Multi-resolution Terrain Representation - If you were flying in to an image of the earth and got closer and closer eventually seeing details of mountains and lakes and closer still until you saw details of houses and driveways and so on, you can understand that to keep high detail representations of the entire earth would be unmanageable. There are two interrelated techniques to help manage the detail. The chief technique to manage the data is something called Level-Of-Detail (LOD). The idea is that based upon some distance threshold you only bring into memory the data needed for display. If for example we are far away from a city so that the entire city fits into a single pixel on the display screen, we wouldn't need to keep data for all the building in the city in memory. Geographic data is a little simpler than the arbitrary case and techniques exist to automatically reduce the terrain data based on the viewers distance. This second technique of variable resolution is used by GeoVRML to again manage complexity. In this case again image looking at terrain from far away you might represent it with a few gently tilted polygons. As you approach close each of the gently sloped polygons turns into many polygons more accurately representing the terrain.

Limitations of Single-Precision: In the world of computer graphics single precision 32 bit (IEEE) floating point numbers provides plenty of accuracy for display screens which are only a couple of thousand pixels in x and y. In the real world this level of accuracy doesn't cut it. Moreover VRML deals with only single precision values, so what's a geographer to do? The solution is to provide a local coordinate system (LCS) and as you need to move to data farther away you establish more and more local coordinate systems. Within each LCS the data remains within the single precision values but since we don't need to cover that much area that precision is fine. To quote again from GeoVRML spec:

To illustrate this concept, imagine an example where we specify the LCS origin 
to be (310385.0 e, 4361550.0 n, 0 m, zone 13) in UTM coordinates. 
This will be transformed to a double-precision geocentric coordinate 
of (-1459877.12, -4715646.92, 4025213.19). If we then supply an absolute 
UTM coordinate of (310400.0 e, 4361600.0 n, 0 m, zone 13), then this will be 
transformed internally to a geocentric coordinate of 
(-1459854.51, -4715620.48, 4025252.11). Finally, we transform this absolute 
geocentric coordinate to a single-precision local Cartesian coordinate system 
by subtracting the LCS origin location to give (22.61, 26.44, 38.92), which is 
within single-precision range. 

Navigation Issues: The two navigation issues that should be dealt with for geographic data are velocity scaling and terrain following. GeoVRML 1.0 does not address terrain following and which will likely be dealt with in future versions. Velocity scaling is the case where you are flying around the earth and then want to fly to, for example, the planet Jupiter. While flying around the earth at say a few thousand miles per hour the terrain of the earth would pass by at a reasonable rate. Taking off for Jupiter however at that same speed would require many days or months to reach the planet, not a reasonable user interaction. By increasing the velocity depending on how far from Jupiter you are you can vastly increase the speed giving the user a much better interaction. These velocity scales are generally controlled by the distance from a terrain, the elevation. This elevation scale velocity is partially dealt with by GeoVRML but is also likely the subject of future improvements.

The actual Nodes in GeoVRML 1.0 are as follows: The following table provides an overview of all of the new nodes that are covered by this version of the GeoVRML recommended practice. Each of these nodes are specified in full detail later in this section.
Node Name Description
GeoCoordinate Build geometry using geographic coordinates
GeoElevationGrid Define a height field using geographic coordinates
GeoInline Inline a file with control over when to load and unload the data
GeoLocation Georeference a vanilla VRML model onto the surface of the earth
GeoLOD Level of detail management for multi-resolution terrains
GeoMetadata Include a generic subset of metadata about the geographic data
GeoOrigin Specify a local coordinate system for increased precision
GeoPositionInterpolator Animate objects within a geographic coordinate system
GeoTouchSensor Return the geographic coordinate of the object being pointer to
GeoViewpoint Specify viewpoints using geographic coordinates

GeoVRML provides content developers interested in the manipulation, interaction and distribution of geographic data with a practical freely and openly available standard. Next week we'll look at some examples of the types of worlds we can create.

[Tutorials] [Web3D Technology Comparison] [Virtual Humans]
[Virtual Reality] [Art] [People of Web3D]
[Panoramic Imaging] [FAQs] [Companies]

Previous page > Overview > Page 1, 2