GeoVRML RFC 1:
Coordinate Systems
Version 1

Introduction

This document is a Request for Comments the first stage in the definition of a standard for the management of geographically registered data in VRML using standard geographical coordinates. It is intended as a reference for discussion, debate and the basis for reference implementations. Comments and discussion should be directed to the GeoVRML Working Group mailing list at geovrml@ai.sri.com.

Background

VRML is a straightforward and useful means of representing three dimensional (3D) content, especially when data is dynamic, interactive or simply made available over networks. Moreover, VRML browsers are becoming ubiquitous and are completely integrated into standard Web browsers, thus making VRML an attractive choice for delivering 3D content via the Web.

In recent years, digital cartography and geographical information systems (GIS) have expanded beyond their two-dimensional boundaries and have begun to develop methodologies for representing and manipulating what is actually 3D data in three dimensions. However, much of this effort has lead to fragmentation and an inability to deliver results (maps and digital representations) to customers without special-purpose software. As a result, some of the community is looking toward VRML.

VRML, however, has a completely simplified notion of coordinate systems. Each VRML file (world) has a simple Cartesian local coordinate systems with origin (0,0,0) and Y up. In order to be useful to the GIS community, there must be some standard means of relating that local coordinate system to any one of the standard, global coordinate systems, a means for georefencing VRML worlds. Moreover, it would be very useful if it were also possible to locate individual objects within georeferenced VRML worlds using standard geographical coordinates.

Technical Considerations

As VRML was designed primarily by and for the computer graphics community, it has some limitations which seem like natural design constraints from the graphics perspective. The most obvious of these from a GIS perspective is the reliance on single-precision (32 bit) IEEE floating point. Since computer graphics typically deals with small screens (1600x1280 pixels at most) and locally bounded regions, there is no need to use double precision since any increases in accuracy it would bring are lost in subpixel noise. There is simply no need, from a graphics prespective to spend the bandwith, time and memory on 64 bit floats.

However, in the GIS or simulation communities we typically deal with whole-world coordinate systems. With only 23 bits of mantissa we can only be accurate to one part in 8 million. Since the earth's diameter is approximately 12 million meters, this leaves us unable to achieve resolutions better than 10 to 100 meters with 32 bit floats. 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.

Requirements

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 (e.g. the USGS software??). Clearly, a standard must fully support some global cartesian system in order to be usable

For these reasons we propose adoption of the SEDRIS Geographic Reference Model (GRM). It is a reference model and software package that currently supports 12 different coordinate systems and tools to automatically and losslessly convert reference marks between them. The standards supported include Geodetic (GDC or latitude/longitude), Geocentric (earth centered Cartesian), Universal Transverse Mercator (UTM), and Lambert Conformal Conic (LCC). It also includes a large geoid and datum library for accurate localization using geodetic coordinates. The white paper describing the standard includes a comprehensive list of the coordinate systems, their naming conventions and the geoid and datum libraries. The software will be available in source form (C) in the summer of 1998 as per SEDRIS' standardization process, which involves full source availability of the reference implementation. We hope to translate the C sources to Java in due course.

We propose a two-level solution. Level 1 consists of a means of entering geographical coordinates into VRML files so that the Cartesian VRML coordinates are generated with respect to a geographically referenced local coordinate system. Its use is straightforward and depends only on the availability of a library for converting from geographical coordinates in the GRM into a local Cartesian frame. Level 2 consists of a much more ambitious attempt to establish a means for automatically managing the relationships between the local Cartesian frames defined in Level 1. It is framed as an active constraint-satisfaction system which manages the spatial relationships between all visible geo-referenced frames. As such it is intended as the enabling technology for seamlessly integrating accurately georeferenced worlds from a wide variety of sources. However, it may be quite demanding of both browsers and programmers to actually achieve its goals. Moreover, the consequences of various design choices made in the implementation may be subtle and far-reaching. We have thus separated it out as a separate proposal and envision it being much more uncertain and potentially volatile.

The Level 1 specification is simply a means to allow users to specify VRML geometry using geospatial coordinates defined with respect to the GRM specified above.

We treat the geo-referencing problem as one of establishing georeferenced local Cartesian coordinate frames (VRML-style with Y up). We define the GeoOrigin node as the basis for a georeferenced VRML world. A single GeoOrigin node, representing a single georeferenced point, becomes the reference frame identified with the VRML world's zero-based origin. Any subsequent references to points or structures defined with geographical coordinates are translated into VRML's Cartesian geometry relative to the GeoOrigin-defined reference frame. We thus enable the conversion of coordinates from a number of well-defined, absolute, earth-based coordinate systems into a common, local Cartesian reference frame. 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. It is this aspect of the Level 1 proposal which will enable the fully seamless management of large-scale, accurately georeferenced worlds envisioned in the Level 2 proposal.

EXTERNPROTO GeoOrigin [
  field MFString geoSystem ["GDC"]
  field SFString geoCoords ""
] "urn:geovrml:protos#GeoOrigin"

Defines an absolute georeferenced location and an implicit local coordinate frame against which geometry is referenced. This node is used to translate from geographical coordinates into a local Cartesian coordinate system which can be managed by the VRML browser.

The geoSystem field selects a geographic or geocentric reference system. Refer to the naming conventions in the SEDRIS Geographic Reference Model for naming conventions (e.g. GDC, GCC, UTM). Some of these basic coordinate systems require optional arguments to fully designate the coordinates. For example, the Geodetic (GDC) system requires the selection of ellipsoid, geoid and datum references. These shall be selected with additional strings in the geoSystem field (e.g. "GDC" "W84" "WE" for Geodetic with the WGS-84 datum and ellipsoid). Each coordinate system used defines the allowable additional tags and their default values.

The geoCoords field is a specification of an absolute location using the coordinate system selected by geoSystem. It consists of a sequence of 64-bit precision values separated by spaces. Its interpretation may be determined by optional strings in the geoSystem field (e.g. "DMS" could be used to specify that the geoCoords string will consist of degree, minute and second fields for each of latitude and longitude in a GDC coordinate). Note that every geospatial location selected by a geoSystem and geoCoords pair defines an implicit orthogonal Cartesian reference frame indexed by x,y,z in meters with the designated geospatial location at the origin and with y being the up direction. Normally this is defined so that y is aligned with the gravity vector and the x axis is aligned east/west and the z axis is aligned north/south.

The GeoOrigin node is used in the geoOrigin field of the GeoCoordinate, GeoInline, GeoElevationGrid and GeoLocation nodes. For any absolute geographical coordinate to make sense in VRML it must be translated into the local, zero-origin, Cartesian coordinate system of the VRML world. In order to achieve this, we identify the VRML world's origin and coordinate frame with the local coordinate system defined by a GeoOrigin node. Any absolute geographical coordinates are then transformed to this local coordinate system before they are inserted into the VRML scene graph.

N.B. In most circumstances, it is recommended that within a single VRML world, only one GeoOrigin node is defined and all subsequent geoOrigin fields will USE this GeoOrigin node.

EXTERNPROTO GeoLocation [
  field SFNode   geoOrigin NULL
  field MFString geoSystem ["GDC"]
  field SFString geoCoords ""
  field MFNode   children  []
] "urn:geovrml:protos#GeoLocation"

This grouping node defines a local Cartesian coordinate frame whose origin is defined by the geoSystem and geoCoords fields exactly as specified in the GeoOrigin node. A Transform node which captures the translation and rotation of this coordinate frame with respect to that specified by the geoOrigin field.

The geometry of the nodes in children is thus intended to be specified in units of meters in VRML coordinates relative to the location specified by the geoSystem and geoCoords fields.

An example of the use of this node is shown below. In this case, the VRML world's origin (as specified in the node named ORIGIN is identified with location in UTM zone 13 as specified by the northing-easting of 4451349.747425, 434474.770883. Yet the geometry in the Shape nodes is defined relative to a different Cartesian frame, with origin at 4331201.15, 451171.56, again in UTM zone 13. Note that the Y axes of these two coordinate frames will be rotated relative to each other due to the difference in the vertical direction between these two different points on the surface of the earth. Note also that in each case, the fourth (elevation) string in the geoCoords field value is omitted, thus defaulting to zero, or ellipsoid surface.

DEF ORIGIN GeoOrigin {
  geoSystem ["UTM"]
  geoCoords "Z13 4451349.747425 434474.770883"
}
GeoLocation {
  geoOrigin USE ORIGIN
  geoSystem ["UTM"]
  geoCoords "Z13 4331201.15 451171.56"
  children [
    Shape {
      ...
    }
    Shape {
      ...
    }
  ]
}

EXTERNPROTO GeoCoordinate [
  field SFNode   geoOrigin NULL
  field MFString geoSystem ["GDC"]
  field MFString point     []
] "urn:geovrml:protos#GeoCoordinate"

This is equivalent to a Coordinate node except that the points specified are absolute, georeferenced coordinates in the designated geoSystem. The strings in the point array are interpreted as absolute locations in the geographical coordinates system defined by geoSystem in the same way as the coords string in the GeoOrigin node.

The geoOrigin field is a GeoOrigin node which defines a local coordinate system. The points specified in the point array are interpreted with respect to the geoSystem field and then translated into the local coordinate system of the geoOrigin node.

EXTERNPROTO GeoInline [
  exposedField MFString url                 []
  field        SFBool   visibilitySensitive TRUE
  field        SFNode   geoOrigin           NULL
  field        MFString geoSystem           ["GDC"]
  field        SFString bboxCenter          ""
  field        SFString bboxSize            ""
] "urn:geovrml:protos#GeoInline"

This is functionally identical to an Inline node except that the bounding box is given using geo-referenced coordinates. The bboxCenter is thus a geographical location specified in the geoSystem specified and bboxSize is in delta units of that same coordinate system.

The visibilitySensitive field determines whether this node operates like a standard Inline node or like a VisibilityInline, which only loads the url when the GeoInline is visible.

EXTERNPROTO GeoElevationGrid [
  field        SFNode   geoOrigin         NULL
  exposedField SFNode   color             NULL
  exposedField SFNode   texCoord          NULL
  field        MFFloat  height            []      # (-,)
  field        SFBool   ccw               TRUE
  field        SFBool   colorPerVertex    TRUE
  field        SFFloat  creaseAngle       0       # [0,]
  field        SFBool   solid             TRUE
  field        MFString geoSystem         ["GDC"]
  field        SFString geoGridOrigin     "0 0 0"
  field        SFInt32  xDimension        0       # [0,)
  field        SFString xSpacing          "1.0"   # (0,)
  field        SFInt32  zDimension        0       # [0,)
  field        SFString zSpacing          "1.0"   # (0,)
] "urn:geovrml:protos#GeoElevationGrid"

This is exactly like an ElevationGrid node, except that the height field is with respect to a grid generated in the coordinate system geoSystem. The xSpacing and zSpacing fields are delta values in that coordinate system. Thus if geoSystem is non-Cartesian, then the base, zero-height field generated will have non-zero curvature.

The example below illustrates the definition of a WGS-84 ellipsoid indexed at a five-degree spacing specified in degrees-minutes-seconds (DMS). Note that the origin used is the center of the earth as specified in GCC coordinates.

DEF ORIGIN GeoOrigin {
  geoSystem ["GCC"]
  geoCoords "0 0 0"
}
GeoElevationGrid {
  geoOrigin USE ORIGIN
  geoSystem ["GDC" "DMS"]
  geoGridOrigin "-180:0:0 -90:0:0"
  xDimension 72
  xSpacing "5:0:0"
  zDimension 36
  zSpacing "5:0:0"
}

The Level 1 specification above is probably perfectly adequate as long as only one GeoOrigin is defined within a single VRML world. The difficulty in managing absolute spatial locations only arises when two differently georeferenced objects are loaded into the same VRML browser. At minimum, some means must be provided to ensure that they are properly spatially situated with respect to each other. Of secondary import, but just as significant with respect to the VRML97 standard is the need to achieve this relative georeferencing with only single precision floating point available to us.

The basic principle behind this proposal is to respect the VRML standard's definition of each VRML world as a local Cartesian coordinate system centered at the origin and provide a means by which this local coordinate system is related to the others present in the world. If the georeferencing itself is static then the transformation between coordinate systems can be completely resolved at load time.

We also wish to allow for a mixture of world heirarchies some of which are individually georeferenced and some others which stay in the coordinate systems of their parents. A secondary, and possibly debatable goal is to allow this to happen even when the user (the VRML world loading a component world) doesn't know whether the world being loaded is georeferenced or not.

The proposal consists of a PROTO which can be used to implement this functionality. We will define a top-level GeoReference node which encapsulates the relationship between coordinate systems as an active constraint. The GeoReference node will be taken as an assertion that as long as it is visible, the geometry it encapsulates will be properly aligned with respect to all other visible GeoReference nodes in the scene.

In order to achieve the second goal of maintaining 64 bit precision with the georeferencing while using only 32 bit floats inside the scene graph we will rely on the truth of a simple assumption: no matter what the viewpoint, all currently visible objects can be accurately rendered with only 32 bit floating point values in the scene graph. This is an assumption that must be rigorously tested once a sample implementation is available.

EXTERNPROTO GeoReference [
  field SFNode geoOrigin NULL
  field MFNode children    []
] "urn:geovrml:protos#GeoReference"

This node represents a georeferenced local coordinate system and would normally be seen as the top-level node in a VRML file. It is a grouping node, and from an external perspective it can be taken as a declaration that the geometry contained within the children nodes is absolutely georeferenced with respect to the geoOrigin node, which must be a GeoOrigin. Coordinates embedded inside a GeoReference node are assumed to be in units of meters.

Each GeoReference node represents one element in a constraint satisfaction problem which maintains the relative spatial alignment between the geoOrigin-defined local coordinate systems for all visible GeoReference nodes. The constraint is most succinctly defined by asserting that there exists some translation and rotation which transforms the absolute locations and alignments of all visible GeoReference nodes to their alignment in the VRML scene graph.

N.B. It is illegal for a Transform node to appear above any GeoReference node in the scene graph.

EXTERNPROTO GeoViewpoint [ 
  eventIn      SFBool     set_bind
  field        SFNode     geoOrigin      NULL
  exposedField SFFloat    fieldOfView    0.785398  # (0,)
  exposedField SFBool     jump           TRUE
  exposedField SFRotation orientation    0 0 1 0   # [-1,1],(-,)
  exposedField MFString   geoSystem      []        # (-,)
  exposedField SFString   geoPosition    ""        # (-,)
  field        SFString   description    ""
  eventOut     SFTime     bindTime
  eventOut     SFBool     isBound
] "urn:geovrml:protos#GeoViewpoint"

This is equivalent to a Viewpoint node with the addition that the location is specified in geographic coordinates (fields geoSystem and geoPosition) and that when this node is bound, the geographical (i.e. gravitational) up vector is properly maintained.

(Taken from the SEDRIS Web Site)

A GRM serves to define coordinate systems, and forward and reverse transformations of geospatial measurements taken in relation to different coordinate systems."

Spatial addresses [or locations] can consist of a wide variety of measurements and data types. Classical navigation employed a method of describing geo-referenced location through a coordinate tuplet based on the Earth-centered angular measurements of longitude and latitude. Modern geographic information processing generally uses a tuplet of easting and northing with a possible elevation measurement. In SEDRIS, all location specifications are triplets, including an elevation (or altitude) measurement." A wide variety of addressing measurements are in use - 12 spatial reference systems have been adopted for support by SEDRIS. The parametric and mathematical relationship between these 12 systems must be clearly defined to enable SEDRIS to accommodate each and to provide a common base which enables interoperability between differing coordinate systems.

For each of the coordinate system types defined below, we need to complete the description of the translation from a GRM-specified location to a GeoOrigin. This includes: the format(s) of the coordinate strings, the alignment of the Cartesian coordinate frame associated with a geographic location, and the format of delta elements.

In addition, since much georeferenced data expresses elevation with respect to mean sea level (MSL) and not directly against one of the usual ellipsoids, it will be necessary to provide some standard geoid reference as well. The choice and specification of this datum is currently undecided.

The 12 coordinate systems supported by SEDRIS include the non-Cartesian and the Cartesian. In the following table, the SEDRIS identity code precedes the coordinate system name.

 

SEDRIS GRM Coordinate Systems

Code	Name
GDC	Geodetic
GCC	Geocentric
GEI	Geocentric Equatorial Inertial
GSE	Geocentric Solar Ecliptic
GSM	Geocentric Solar Magnetospheric
SM	Solar Magnetic
GCS	Global Coordinate System
PS	Polar Stereographic PCS
LCC	Lambert Conformal Conic PCS
TM	Transverse Mercator
UTM	Universal Transverse Mercator
LST	Local Space Rectangular

 

SEDRIS Ellipsoids: Names and constants for GDC ellipsoids

Code	Ellipsoid Name	Semi-Major Axis (meters)	Inv. Flattening (F-1)
AA	Airy 1830	6377563.396	299.3249646
AM	Modified Airy	6377340.189	299.3249646
AN	Australian National	6378160	298.25
BN	Bessel 1841 (Namibia)	6377483.865	299.1528128
BR	Bessel 1841 (Ethiopia Indonesia...)	6377397.155	299.1528128
CC	Clarke 1866	6378206.4	294.9786982
CD	Clarke 1880	6379249.145	293.465
EA	Everest (India 1830)	6377276.345	300.8017
EB	Everest (Sabah & Sarawak)	637298.556	300.8017
EC	Everest (India 1956)	6377301.243	300.8017
ED	Everest (W. Malaysia 1969)	6377295.664	300.8017
EE	Everest (W. Malaysia & Singapore 1948)	6377304.063	300.8017
FA	Modified Fischer 1960	6378155	298.3
HE	Helmert 1906	6378200	298.3
HO	Hough 1960	6378270	297
IN	International 1924	6378388	297
KA	Krassovsky 1940	6378245	298.3
RF	Geodetic Reference System 1980 (GRS 80)	6378137	298.257222101
SA	South American 1969	6378160	298.25
WD	WGS 72	6378135	298.26
WE	WGS 84	6378137	298.257223563