GeoVRML 1.0 Recommended Practice
This section contains discussions of various important concepts that
are integral to GeoVRML. This includes the specification of geographic
coordinate systems, the representation of large multi-resolution
terrain datasets, the issues of dealing with limited precision
floating point values, and the issues surrounding navigation of
large geographic areas.
2.1 Geographic Coordinate Systems
Each VRML world uses a simple Cartesian local coordinate system (LCS) with an origin at (0,0,0) and +Y representing the up direction [VRML97]. However, most georeferenced data are provided in a geodetic or projective coordinate system. A geodetic (or geographic) coordinate system is related to the ellipsoid used to model the earth, for example the latitude/longitude system. A projective coordinate system employs a projection of the ellipsoid onto some simple surface such as a cone or a cylinder, for example, the Lambert Conformal Conic (LCC) or the Universal Transverse Mercator (UTM) projections [SNY87]. In order to be useful to the geographic community, there must be some standard means of relating VRML's Cartesian coordinate system to any one of the standard geographic coordinate systems, i.e. a means for georeferencing VRML worlds.
There already exist a number of standards for the representation of geospatial information and the georeferencing of arbitrary data. We cannot presume to adopt all of them, instead we must choose one which is broad enough to encompass our needs and for which we have a reference implementation which is usable from a Script node, e.g. Java. Moreover, many of these systems, and the software packages which support them, do not actually support a translation to a Cartesian coordinate system. Clearly, a standard must fully support some global Cartesian system in order to be usable.
For these reasons, we have adopted the SEDRIS Spatial (or Geospatial) Reference Model (SRM) [SED97]. It is a reference model and software package that currently supports 12 different coordinate systems and tools to convert reference marks automatically and losslessly between them. The coordinate systems supported include Geodetic (GDC or latitude/longitude), Geocentric (earth centered Cartesian), UTM, and LCC, among others. It also includes a large geoid and datum library for accurate localization using geodetic coordinates.
In order to use these facilities within new VRML nodes, SRI
International embarked upon a process to convert part of the SEDRIS
Conversions API to Java. The result is the freely-available, open
source Java package called GeoTransform
The GeoVRML 1.0 sample implementation is built on top of the
GeoTransform package. It therefore supports
conversions between geodetic, geocentric, and UTM
coordinate systems, and also includes all of the SEDRIS ellipsoid
2.2 Multi-resolution Terrain Representation
Terrain models are typically massive in size. For example, the U.S. Geological Survey (USGS) produce Digital Elevation Models (DEMs) that contain over one million points, and Digital Orthoquad (DOQ) images that can contain over 12 million pixels. The time to download and render terrain models of this complexity would prohibit any form of real-time interaction using the current generation of VRML browsers. It therefore becomes essential to implement some form of level of detail (LOD) management.
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. 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 tend to be inappropriate for web-based applications because switching to the highest resolution would still involve loading every point of the original dataset. Similarly, there are various dynamic LOD techniques that can simplify a large height field grid in real-time taking the user's viewpoint into consideration. However, once again, these require the high-resolution dataset to be resident in memory first.
For large distributed terrain datasets, a tiled pyramid approach is
a common solution. This involves taking a high-resolution dataset and
progressively downsampling it to produce a multi-resolution
pyramid. Each level of this pyramid is then segmented into a grid of
equally-sized rectangular tiles, for example 128 x 128 pixels. A tile
at one level of the pyramid will therefore map onto four tiles on the
immediately higher-resolution level, i.e. the tiles at the
higher-resolution level cover a quarter of the geographical area of
the former. Using such a representation, we can progressively display
higher resolution data around some area of interest (e.g. the user's
viewpoint) while other regions remain in low resolution. The use of
tiling also allows us to only fetch and display sections of the
dataset that are visible from a certain vantage point.
2.3 Limitations Of Single-Precision
VRML was designed primarily by and for the computer graphics community, and as such it has some limitations which seem to be natural design constraints from the graphics perspective. The most obvious of these from a geosciences perspective is the reliance on single-precision (32-bit) IEEE floating point values. Since computer graphics typically deals with small screens (1600 x 1280 pixels at most) and locally bounded regions, there is no need to use double-precision since any increases in accuracy that it brings would be lost in sub-pixel noise.
However, single-precision is insufficient to model data over the range of the earth at accurate ground resolutions. With only 23 bits of mantissa we can be accurate to only one part in 8 million; or about 6 digits of precision. Since the equatorial diameter of the earth is 12,756,274 m (under the WGS84 ellipsoid), this leaves us unable to achieve resolutions better than 10s of meters using single-precision floating point numbers. Below this threshold, we will experience various floating point rounding artifacts such as vertices coalescing and camera jitter. With the widespread distribution and future ubiquity of GPS transceivers, and the increased public availability of differential references, virtually anyone can now obtain accurate absolute locations with 1 meter resolution. There is no reason to suppose that professional cartographers should settle for less. We therefore desire to represent floating point values to precisions beyond that of single-precision.
We treat this georeferencing problem as one of establishing a georeferenced local Cartesian frame, or LCS. We define an absolute georeferenced location as the origin of the LCS. This becomes the reference point that correlates to the VRML world's (0,0,0) origin. Any subsequent geographic locations are translated into VRML's Cartesian coordinate system relative to this LCS origin. Moreover by allowing the user to define these local frames easily, we allow the creator of the georeferenced data to manage the accuracy of a 32-bit floating point representation by creating VRML worlds of only limited local extent.
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
2.4 Navigation Issues
There are a number of navigation issues that are specific to the task of browsing large geographic areas. The two principal issues that we mention here are elevation scaled velocity and terrain following.
The velocity at which users can navigate around a world should depend upon their height above the terrain. For example, when flying over the coast at a height of 100 m above the terrain, a velocity of 100 m/s could be considered relatively fast. However, when approaching the earth from outer space, a velocity of 100 m/s would be intolerably slow. Creators of geographic visualization systems have therefore learned to scale the velocity of the user's navigation in an attempt to maintain a constant pixel flow across the screen. A simple linear relationship between velocity and the user's elevation above an ellipsoid such as WGS84 often provides an acceptable and easily computable solution to this problem.
The second issue is that of terrain following. The earth is, of course, not a flat surface. As we navigate over the earth's surface we should therefore expect to follow a curved flight path through 3-D space. However, default navigation methods in VRML, such as WALK and FLY, propel the user along a linear flight path that is parallel to the X-Z plane. A more correct approach in terms of planetary visualizations would be to maintain a particular height about the surface of the earth. Note that, while elevation scaled velocity is partly addressed by this GeoVRML recommended practice document, the issue of terrain following is not addressed.
Questions or comments.
Copyright 2000, SRI International.