previous
next
contents 

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 multiresolution terrain datasets, the issues of dealing with limited precision floating point values, and the issues surrounding navigation of large geographic areas.
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 freelyavailable, open source Java package called GeoTransform [GEO]. 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 definitions.
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 realtime 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 webbased 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 realtime taking the user's viewpoint into consideration. However, once again, these require the highresolution dataset to be resident in memory first.
For large distributed terrain datasets, a tiled pyramid approach is a common solution. This involves taking a highresolution dataset and progressively downsampling it to produce a multiresolution pyramid. Each level of this pyramid is then segmented into a grid of equallysized 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 higherresolution level, i.e. the tiles at the higherresolution 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.
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 singleprecision (32bit) 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 doubleprecision since any increases in accuracy that it brings would be lost in subpixel noise.
However, singleprecision 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 singleprecision 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 singleprecision.
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 32bit 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 doubleprecision 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 singleprecision local Cartesian coordinate system by subtracting the LCS origin location to give (22.61, 26.44, 38.92), which is within singleprecision range.
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 3D 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 XZ 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.