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.
