  |
 |
 |
||
 |
|
 |
|
GeoVRML Goals
There is a strong perception among people working with geographical data that a standard means of representing three-dimensional geo-referenced data will be not only useful but essential in order to make such data generally useful and widespread. Work going on in private industry, government and academia is rapidly moving geographical information from two-dimensional cartographic representations to full three-dimensional models. VRML is an obvious building block for standardizing external representations of this kind of data. In order to be generally useful, however, such data must not only be accurately represented but easily generated and manipulated. There is a general perception in the field of cartographic modelling, however, that VRML is at the same time both inadequate and too general for such data. Therefore, we will attempt to identify the kinds of information that are either essential or especially useful in assuring the accurate geo-referencing of arbitrary datasets and recommend means of providing such external data in VRML datasets. In addition, we will attempt to identify shortcomings and inadequacies in the current VRML standard which lead to undesirable difficulties in representing common types of geographical data and then to recommend either means of bypassing these shortcomings or extensions and improvements to the standard which will be forwarded to the appropriate standardization bodies.
Coordinate Systems
A wide variety of coordinate systems have been developed by many different mapping agencies around the world for specifying accurate locations on the surface of the earth. The most familar georeferencing coordinate systems are perhaps Latitude/Longitude and UTM. In most recent work, they refer to the geodetic datum known as WGS84, the standard earth surface measurement used by the Global Positioning System (GPS). Both of these are geodetic coordinate systems, defining and making reference to the surface of the earth, and sometimes trying to represent a gravitational "up" vector. Another kind of coordinate system is the geocentric coordinate system, typically either a simple Cartesian or polar system, based around some "center". A discussion of some of the history, methods and results of the attempts to standardize earth measurement systems (geodesy) is the NIMA document "Geodesy for the Layman". With this and the "GPS Overview" from the University of Texas Geography Department we have a basis for discussion. In VRML, a world has a simple, local, Cartesian coordinate system with the Y axis defined as "up". The most basic problem in georeferencing a VRML world is thus to be able to transform from a standard georeferencing system to the VRML local system. In GeoVRML 1.0, we adopted the SEDRIS Spatial Reference Model which is an earth reference model that currently supports 12 coordinate systems. This also includes a software package for converting between various geographic coordinate systems that we converted to Java, producing the GeoTransform package. Of course one obvious significant issue is that VRML provides only an SFFloat data type, which guarantees only 23 bits of mantissa. With only this available to us, there is no straightforward way to accurately represent even a civilian-grade GPS location. The Working Group has proposed a means of managing these absolute location references using standard geographical coordinates: GeoVRML RFC 1: Coordinate Systems. This proposal is now part of the GeoVRML 1.0 Recommended Practice. 
Time Referencing
As with location, there is a need for dealing with content that is timestamped with respect to an absolute reference. At this point, it seems that the Coordinated Universal Time (UTC) time standard is the appropriate place to start. We will need to adopt one of the standard representations of the UTC, either numeric or textual, and augment that with a method for describing the accuracy and resolution of the measurements. Being able to merge and play back time-referenced recordings or interpretations of past events will also require standard tools for managing events and absolute times. Useful references on the topic of time referencing include:
Terrain representation
Typically, terrain imagery is provided (e.g. by the USGS) as ortho-rectified image mosaics of 10,000 by 10,000 pixels or greater. Such an image is clearly not going to be loaded into texture-mapped memory on any current consumer-grade graphics hardware. The obvious response to this problem has been to break the image into manageable tiles, typically 128 by 128 or 256 by 256. This is certainly straightforward and easily automated. But VRML is a 3D standard and almost everyone will wish to tie this imagery to geometry, and in this case the usual source for such geometry is digital elevation maps (DEMs). These maps typically are delivered as floating-point arrays of 1200 by 1200 pixels or more. It is here that we meet the greatest challenge, for we can't easily expect to transmit 1.4 million polygon definitions over even an ISDN line. Not only will we need to tile the DEM as well, but we will almost certainly need to manage the texture-mapped elevation geometry in some form of level-of-detail (LOD) hierarchy (typically a quad-tree).
Level of Detail
Consider a connected web of VRML worlds that move from the whole world (including near-earth space) and sub-meter resolution digital terrain photography. A conservative estimate of the resolution ratios involved gives at least a 100,000:1 change in resolution. If we assume a 2:1 change for each level of detail in a VRML LOD hierarchy, then that implies at minimum 17 levels of detail. None of the current browsers seems to perform stably with any more than 4 levels of detail in a scene. Moreover, these browsers attempt to "optimize display speed" by loading all levels of detail at read time (assuming that component LOD levels are separated into different files by Inline nodes). Clearly, new solutions for representing very deep LOD hierarchies are necessary. We have produced a mechanism to manage a quad-tree based level-of-detail with the GeoVRML 1.0 The GeoLOD Node. It selectively loads levels of the LOD tree so as to minimize the memory footprint of the browser for very deep trees.
Resolution and Accuracy
Floating point numbers in VRML97 are represented using single-precision only, which means that we are restricted to around 6 digits of precision for all of our coordinates. However, for many geographic applications we require far higher precision, such as double-precision which offers around 15 digits of precision. We are therefore faced with the problem of modeling large, geo-referenced coordinates using only single precision values. This can be done by introducing the concept of local coordinate systems (LCSs) - where any LCS contains values within single-precision range - and then selecting the most appropriate LCS to use based upon the user's viewpoint. The GeoVRML Working Group recently issued a proposal that the next generation VRML specification provide support for double-precision floating point values. As a result, double-precision support is to appear in the developing X3D standard.
Data interchange
It is hoped that by providing tools and recommended practice for representing geo-referenced data in VRML that these standards will be uptaken by the geographic community at large, thus enabling geographic VRML to be interchanged between different data producers. This is meant both in terms of using a standard syntactic representation as well as seamlessly integrating different geo-referenced data together, e.g. if one data producer generates a model of the state of California and another producer generates a model of the state of Nevada, then joining these two models together should result in the two states being correctly juxtaposed. An important issue here is the notion of metadata. Metadata means data about data, i.e. information that described the geo-referenced data. This could include details such as the dataset's name, location, resolution, extent, source of the data, copyright information, etc. GeoVRML 1.0 includes a means to represent a subset of metadata within the VRML scene and referencing some various larger metadata standard, such as:
| |||||