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 twodimensional 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 specialpurpose 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 singleprecision (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
wholeworld 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 twolevel 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 constraintsatisfaction system
which manages the spatial relationships between all visible
georeferenced 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 farreaching. We have thus separated
it out as a separate proposal and envision it being much more
uncertain and potentially volatile.
Proposal: Level One
Framework
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 georeferencing problem as one of establishing
georeferenced local Cartesian coordinate frames (VRMLstyle 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
zerobased 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 welldefined, absolute, earthbased 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 largescale, accurately georeferenced worlds
envisioned in the Level 2 proposal.
PROTOs
GeoOrigin
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 WGS84 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 64bit 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,
zeroorigin, 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.
GeoLocation
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 northingeasting 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 {
...
}
]
}
GeoCoordinate
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.
GeoInline
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 georeferenced 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.
GeoElevationGrid
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 nonCartesian, then the base, zeroheight
field generated will have nonzero curvature.
The example below illustrates the definition of a WGS84 ellipsoid
indexed at a fivedegree spacing specified in degreesminutesseconds
(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"
}
Proposal: Level Two
Framework
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 toplevel 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.
GeoReference
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 toplevel 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.
GeoViewpoint
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.
SEDRIS Geographic Reference Model (GRM)
(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 georeferenced location through a coordinate tuplet based
on the Earthcentered 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 GRMspecified
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
nonCartesian 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 
SemiMajor 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 
