GeoVRML 1.1 Specification
This section describes the set of new nodes that form the major
part of the GeoVRML effort. These nodes provide various features that
are particularly useful in the modeling of geospatial data. Here we
detail the specification of each node, document its purpose, and
how it is to used. A number of example VRML worlds that use these
nodes are provided in the Examples
section. Note that an open source sample implementation is provided
for these nodes. Information on this implementation can be found in
the Sample Implementation section.
3.1 Node Summary
The following table provides an overview of all of the new nodes that are covered by this version of the GeoVRML recommended practice. Each of these nodes are specified in full detail later in this section.
|GeoCoordinate||Build geometry using geographic coordinates|
|GeoElevationGrid||Define a height field using geographic coordinates|
|GeoLocation||Georeference a vanilla VRML model onto the surface of the earth|
|GeoLOD||Level of detail management for multi-resolution terrains|
|GeoMetadata||Include a generic subset of metadata about the geographic data|
|GeoOrigin||Specify a local coordinate system for increased precision|
|GeoPositionInterpolator||Animate objects within a spatial reference frame|
|GeoTouchSensor||Return the geographic coordinate of the object being pointer to|
|GeoViewpoint||Specify viewpoints using geographic coordinates|
|InlineLoadControl||Inline a file with control over when to load and unload the data|
3.2 General Concepts
3.2.1 Representing Geographic Coordinates
All the GeoVRML nodes transform their geographic coordinates into earth-fixed geocentric coordinates (displacement from the center of the earth in units of meters). An offset may be applied to these coordinates if a GeoOrigin node is supplied. The resulting coordinates are then passed to the VRML browser. This approach means that we preserve the default spatial unit of meters that is defined by VRML97.
Geographic coordinates tend to be large and require at least
double-precision floating point values to represent detail at
sub-millimeter range. VRML only provides single-precision floating
point values (SF/MFFloat). Therefore, in order to represent
double-precision values in a standard VRML97 file, we store all
geographic values as strings (SF/MFString). These strings are then
passed into Java scripts because Java has support for double-precision
variables. We can therefore parse these strings and operate on the
double-precision values from within Java. This means that we require a
VRML browser that supports Java in the Script node. In the next
revision of the VRML specification, referred to as X3D, support for a
double floating-point type will be included, and so the X3D geospatial
profile can specify geographic coordinates as lists of numbers instead
of strings. This offers the advantage of the extra type checking
facilities and producing a cleaner representation.
3.2.2 World Scale and Navigation Issues
Geographic scenes can vary widely in the physical extent that they model. For example, we could produce a model of the entire world, or build a scene of a small neighborhood of houses. This has an affect on navigation issues within VRML because we need to modify the navigation speed to a suitable setting for the desired scale, and also change the near clipping plane appropriately. This can be achieved by altering the speed and avatarSize fields of the currently bound NavigationInfo node.
The default VRML97 navigation speed is 1 m/s (defined by the speed
field of a NavigationInfo node). This provides good interactivity for
models in the order of tens of meters in size. For larger models we
need to scale the navigation speed appropriately, and we should also
scale the avatarSize by the same value in order to define suitable
clipping planes. For GeoVRML scenes, we recommend that the speed of
user interaction be defined as ( elev / 10.0 ) m/s, where
elev is the user's elevation above the WGS84 ellipsoid in units
of meters. This functionality is addressed by the GeoViewpoint node.
3.2.3 Specifying A Spatial Reference Frame
All GeoVRML nodes that support spatial reference frames do this by providing a field called geoSystem. This field is used to specify the particular spatial reference frame that will be used for the geographic coordinates in that node. This is an MFString field that can include a number of arguments to fully designate the coordinates. Each argument is to appear in a separate string within the MFString array. Argument matching is case sensitive. Optional arguments may appear in any order. The following values should be supported.
"GD" - Geodetic spatial reference frame (latitude/longitude). An optional argument may be used to specify the ellipsoid using one of the ellipsoid codes that are defined in Section 4.2: Ellipsoid Definitions. If no ellipsoid is specified, then "WE" is assumed, i.e. the WGS84 ellipsoid. An optional "WGS84" string can be specified if you wish all elevations to relative to the WGS84 geoid, i.e. mean sea level; otherwise, all elevations will be relative to the ellipsoid. An example spatial reference frame definition of this format is [ "GD", "WD" ], for a geodetic coordinate system based upon the WGS72 ellipsoid with all elevations being relative to that ellipsoid. The string "GDC" may be used as an alias for "GD", but this functionality may be deprecated in future versions of this specification.
"UTM" - Universal Transverse Mercator (UTM). One further required argument must be supplied for UTM in order to specify the zone number (1..60). This is given in the form "Z<n>", where <n> is the zone number. An optional argument of "S" may be supplied in order to specify that the coordinates are in the southern hemisphere (otherwise, northern hemisphere will be assumed). A further optional argument may be used to specify the ellipsoid using one of the ellipsoid codes that are defined in Section 4.2: Ellipsoid Definitions. If no ellipsoid is specified, then "WE" is assumed, i.e. the WGS84 ellipsoid. An optional "WGS84" string can be specified if you wish all elevations to relative to the WGS84 geoid, i.e. mean sea level; otherwise, all elevations will be relative to the ellipsoid. An example spatial reference frame definition of this format is [ "UTM", "Z10", "S", "GD" ], for a southern hemisphere UTM spatial reference frame in zone 10 with all elevations being with respect to mean sea level.
"GC" - Earth-fixed Geocentric with respect to the WGS84 ellipsoid. No additional arguments are supported. An example spatial reference definition of this format is [ "GC" ]. The string "GCC" may be used as an alias for "GC", but this functionality may be deprecated in future versions of this specification.
If no geoSystem field is specified, then the default value is
[ "GD", "WE" ].
3.2.4 Specifying Geographic Coordinates
A single geographic coordinate is specified as a tuple of three values encoded as an SFString. Lists of geographic coordinates are encoded as an MFString. The format of this string value depends upon the particular spatial reference frame that was defined via the geoSystem field in the same node. Given the following geoSystem definitions, the format of a coordinate string is defined as:
GD - "<latitude> <longitude> <elevation>" or <longitude> "<latitude> <elevation>". The order of latitude and longitude is controlled by the geoSystem field. If "latitude_first" is specified, the order is latitude then longitude. If "longitude_first" is specified, the order is longitude then latitude. If neither is specified, "latitude_first" is the default. Elevation is always specified third. Latitude and longitude are given in units of degrees. Latitude is in the range -90..+90, and longitude can be in the range -180..+180 or 0..360 (0 deg longitude is the same point in both cases). Longitudinal values are relative to the Greenwich Prime Meridian. Elevation is given in units of meters above the ellipsoid (the default) or above the WGS84 geoid (if you supplied the "WGS84" parameter in the geoSystem field). For example, "37.4506 -122.1834 0" is the latitude/longitude coordinate for Menlo Park, CA.
UTM - "<northing> <easting> <elevation>" or <easting> "<northing> <elevation>". The order of northing and easting is controlled by the geoSystem field. If "northing_first" is specified, the order is northing then easting. If "easting_first" is specified, the order is easting then northing. If neither is specified, "northing_first" is the default. Elevation is always specified third. Eastings, northings, and elevation are all given in units of meters. The zone of the coordinate, and whether it is in the southern hemisphere, are defined in the geoSystem string. Elevation is given with reference to the ellipsoid (the default) or the WGS84 geoid (if you supplied the "WGS84" parameter in the geoSystem field). For example, "4145173 572227 0" is the zone 10 northern hemisphere UTM coordinate for Menlo Park, CA.
GC - "<x> <y> <z>". These values are all given in units of meters. The coordinate represents an (x, y, z) offset from the center of the planet, based upon the WGS84 ellipsoid. The z-axis passes through the poles while the x-axis cuts through the latitude/longitude coordinate (0,0) degrees. For example, "-2700301 -4290762 3857213" is the geocentric coordinate for Menlo Park, CA.
Note that we only use strings to specify geographic coordinates because VRML does not support double-precision floating point values. If there were support for double-precision, then whenever a geographic coordinate is specified as an SFString type, this would be represented as an SFVec3d type; and wherever the geographic coordinate is specified as an MFString type, then this would be a MFVec3d.
When a list of geographic coordinates can be provided for a field, then this will normally be specified as an MFString. The list of values can be supplied in either of the follow two representations.
[ "x1 y1 z1 x2 y2 z2" ] [ "x1 y1 z1" "x2 y2 z2" ]
All GeoVRML nodes that deal with geometry support a
geoOrigin field to specify the local coordinate system for the
geometry. This field will contain a single GeoOrigin node defining
the local coordinate system. In GeoVRML 1.1, all nodes within a single
scene must use the same local coordinate system. If not defined, then
the geocentric coordinate (0,0,0) will be used, i.e. the center of the
planet. It is recommended that an appropriate GeoOrigin specification
should be provided for any worlds that deal with geographically
small-scale models, such as less than a few kilometers in extent.
EXTERNPROTO GeoCoordinate [ field SFNode geoOrigin # NULL field MFString geoSystem # [ "GD", "WE" ] field MFString point #  ] [ "urn:web3d.org:vrml97:node:GeoCoordinate" "file:///C:/Program%20Files/GeoVRML/1.1/protos/GeoCoordinate.wrl" "http://www.geovrml.org/1.1/protos/GeoCoordinate.wrl" ]
The GeoCoordinate node lets you specify a list of coordinates in a spatial reference frame. These are then transparently transformed into a geocentric, curved-earth representation. For example, this would allow a geographer to create a VRML world where they specify all coordinates in terms of latitude, longitude, and elevation.
The GeoCoordinate node can be used wherever you can use a standard Coordinate node, e.g. within an IndexedFaceSet, IndexedLineSet, or PointSet. The fields geoSystem and geoOrigin are described above in Sections 3.2.3 and 3.2.5 above. N.B. The text after the hash symbols (#) in the EXTERNPROTO definition are VRML97 style comments to indicate the default value for each field. This convention will be continued for all further node specifications in this section.
The GeoCoordinate node will normally be built upon the standard VRML97 Coordinate node, and as such the same implementation issues that apply to the Coordinate node apply here. For example, the minimum limits for the VRML97 Coordinate node is to support 15,000 points and the minimum limits for the VRML97 MFString is to support 30,000 utf8 octets per string and 10 strings [VRML97]. Most browser implementations will exceed these capacities.
The point string array is used to contain the actual
geographic coordinates and should be provided in a format consistent
with that specified for the particular geoSystem (see
above). You can split your coordinates arbitrarily over any number of
strings, e.g. [ "x1 y1 z1 x2 y2 z2" ] or [ "x1 y1 z1", "x2 y2 z2" ] or
even [ "x1" "y1" "z1", "x2" y2" "z2" ].
EXTERNPROTO GeoElevationGrid [ eventIn MFFloat set_height eventIn SFFloat set_yScale exposedField SFNode color # NULL exposedField SFNode normal # NULL exposedField SFNode texCoord # NULL field SFBool ccw # TRUE field SFBool colorPerVertex # TRUE field SFFloat creaseAngle # 0 field SFNode geoOrigin # NULL field MFString geoSystem # [ "GD", "WE" ] field SFString geoGridOrigin # "0 0 0" field MFFloat height #  field SFBool normalPerVertex # TRUE field SFBool solid # TRUE field SFInt32 xDimension # 0 field SFString xSpacing # "1.0" field SFFloat yScale # 1.0 field SFInt32 zDimension # 0 field SFString zSpacing # "1.0" ] [ "urn:web3d.org:vrml97:node:GeoElevationGrid" "file:///C:/Program%20Files/GeoVRML/1.1/protos/GeoElevationGrid.wrl" "http://www.geovrml.org/1.1/protos/GeoElevationGrid.wrl" ]
The GeoElevationGrid node lets you specify a grid of elevations within a spatial reference frame. These are then transparently transformed into a geocentric, curved-earth representation. For example, this would allow a geographer to create a height field where they specify all coordinates in terms of latitude, longitude, and elevation.
This node can be used within the geometry field of a VRML Shape node. The fields color, colorPerVertex, texCoord, normal, normalPerVertex, ccw, creaseAngle, and solid all have the same meaning as they do for a standard VRML ElevationGrid [VRML97].
The fields geoSystem and geoOrigin are described above in Sections 3.2.3 and 3.2.5 above. The geoGridOrigin specifies the geographic coordinate for the south-west corner (bottom-left) of the dataset. This value should be given in the format described in Section 3.2.4.
The height array contains xDimension * zDimension floating point values that represent elevation above the ellipsoid or the geoid, as appropriate. These values are given in row-major order from west to east, south to north. When the geoSystem is GD, xSpacing refers to the number of degrees of longitude between adjacent height values and zSpacing refers to the number of degrees of latitude between vertical height values. When the geoSystem is UTM, xSpacing refers to the number of eastings (meters) between adjacent height values and zSpacing refers to the number of northings (meters) between vertical height values. (Hint: if xDimension = n and the grid spans d units horizontally, then the xSpacing value should be set to d / (n-1) ). An eventIn called set_height is provided to allow the height array to be modified dynamically, for example, to support deformations or morphing of terrain surfaces.
The yScale value can be used to produce a vertical
exaggeration of the data when it is displayed. By default, this value
is 1.0 (no exaggeration). If you set this value to > 1.0, then all
heights will appear larger than they actually are. This can be useful
for emphasizing elevation change, but of course the images produced
will not represent the true elevation unless yScale is 1.0. An eventIn
called set_yScale is provided to allow the vertical
exaggeration factor to be altered dynamically.
EXTERNPROTO GeoLocation [ exposedField SFString geoCoords # "" field MFNode children #  field SFNode geoOrigin # NULL field MFString geoSystem # [ "GD", "WE" ] ] [ "urn:web3d.org:vrml97:node:GeoLocation" "file:///C:/Program%20Files/GeoVRML/1.1/protos/GeoLocation.wrl" "http://www.geovrml.org/1.1/protos/GeoLocation.wrl" ]
The GeoLocation node provides the ability to georeference any standard VRML model. That is, to take an ordinary VRML model, contained within the children field of the node, and to specify its location on the surface of the earth. This node is a grouping node that can be thought of as a Transform node. However, the GeoLocation node specifies an absolute location, not a relative one, so content developers should not nest GeoLocation nodes within each other.
The fields geoSystem and geoOrigin are described above in Sections 3.2.3 and 3.2.5 above.
The geometry of the nodes in children is to be specified in units of meters in VRML coordinates relative to the location specified by the geoCoords field. The set_geoCoords eventIn can be used to dynamically update a model's location, for example, via the output of a GeoPositionInterpolator.
In addition to placing a VRML model at the correct location on the planet, the GeoLocation node will also adjust the model's orientation appropriately. The standard VRML97 coordinate system specifies that the +Y axis = up, +Z = out of the screen, and +X = towards the right. The GeoLocation node will set your orientation so that, wherever you are, the +Y axis is the up direction for that local area (the normal to the tangent plane on the ellipsoid), -Z points towards the north pole, and +X is east.
Note that the children field of GeoLocation is not an
exposedField and therefore the nodes specified cannot be changed at
run-time. In order to support dynamically changing geometry, a Group
node can be added as the top-level node and then the contents of that
Group node can be modified through its children exposedField.
EXTERNPROTO GeoLOD [ field SFString center # "" field MFString child1Url #  field MFString child2Url #  field MFString child3Url #  field MFString child4Url #  field SFNode geoOrigin # NULL field MFString geoSystem # [ "GD", "WE" ] field SFFloat range # 10 field MFNode rootNode #  field MFString rootUrl #  eventOut MFNode children ] [ "urn:web3d.org:vrml97:node:GeoLOD" "file:///C:/Program%20Files/GeoVRML/1.1/protos/GeoLOD.wrl" "http://www.geovrml.org/1.1/protos/GeoLOD.wrl" ]
The GeoLOD node provides a terrain specialized form of the VRML97 LOD node. It is a grouping node that specifies two different levels of detail for an object using a tree structure, where 0 to 4 children can be specified, and also efficiently manages the loading and unloading of these levels of detail.
The level of detail is switched depending upon whether the user is closer or further than range meters from the geographic coordinate that is defined by the field center. The fields geoSystem and geoOrigin are described above in Sections 3.2.3 and 3.2.5 above. The format of the center field is described in Section 3.2.4.
When the user is outside the specified range, only the geometry for rootUrl or rootNode are displayed. When the viewer enters the specified range, this geometry is replaced with the contents of the four children files defined by child1Url through child4Url. The four children files are loaded into memory only when the user is within the specified range. Similarly, these are unloaded from memory when the user leaves this range. Figure 3.1 illustrates this process. Note however that there is no requirement that the child URLs be arranged in the same order as in the figure, i.e. child1Url does not need to represent the bottom-left quadtree child. Note also that it is valid to specify less than 4 child URLs, in which case the GeoLOD should switch to the children nodes when all of the specified URLs have been loaded. This latter feature can support tree structures other than quadtrees, such as binary trees.
|Figure 3.1: Illustrating the GeoLOD level of detail transition.|
The rootUrl and rootNode fields provide two different ways to specify the geometry of the root tile. You may use one or the other. The rootNode field lets you include the geometry for the root tile directly within the VRML file; whereas the rootUrl field lets you specify a URL for a file that contains the geometry. The result of specifying a value for both of these fields is undefined.
The children eventOut is used to expose the scene graph for the currently loaded set of nodes. The value returned is an MFNode with a single Switch node. This Switch node contains the root nodes in the first node of the choice field, and all the currently loaded children nodes in the second node of the choice field. The whichChoice field of the Switch node determines whether the root (0) or the children nodes (1) are being displayed. The GeoLOD node will generate a new children eventOut every time the scene graph is change, e.g. whenever nodes are loaded or unloaded.
The GeoLOD node may be implemented with support for a cache of the
most recent nodes that have been loaded. This cache should be global
across all GeoLOD instances in a scene. This will improve performance
when navigating large terrain models by avoiding excessive loading and
unloading when a user makes small changes in viewpoint.
EXTERNPROTO GeoMetadata [ exposedField MFNode data #  exposedField MFString summary #  exposedField MFString url #  ] [ "urn:web3d.org:vrml97:node:GeoMetadata" "file:///C:/Program%20Files/GeoVRML/1.1/protos/GeoMetadata.wrl" "http://www.geovrml.org/1.1/protos/GeoMetadata.wrl" ]
The GeoMetadata node aims to specify metadata describing any number of GeoVRML nodes. This can be thought of as similar to a WorldInfo node, but specifically for describing geographic information. There are a number of organizations that are already working on standards and representations for geographic metadata, such as the FGDC, ISO TC211, CEN TC287, OpenGIS Consortium, and others. Rather than adopt any particular standard, the purpose of the GeoMetadata node is to provide links to any of these complete metadata descriptions, with the option to also supply a short, human-readable summary.
The url field is used to specify a hypertext link to an external, complete metadata description. Multiple URL strings can be specified in order to provide alternative locations for the same metadata file. An optional hint can be provided in the summary field to specify the format of the metadata in the case where this cannot be deduced easily.
The summary string array contains a set of keyword/value pairs, with each keyword and its subsequent value contained in a separate string, i.e. there should always be an even (or zero) number of strings. This provides a simple, extensible mechanism to include metadata elements that are human-readable and easy to parse. The following list specifies a number of keywords and the format that should be used to describe their values. To support future additions to this list, if an unknown keyword is found then it (and its associated value) should be ignored.
|title||A name to succinctly identify the dataset to user. For example, "San Francisco, CA".|
|description||A brief textual description or summary of the content of the dataset. For example, "LANDSAT 7 satellite imagery taken over northern Scotland".|
|coordinateSystem||The geographic coordinate system used to represent the data, e.g. GD, UTM, LCC, etc. The list of valid codes that can be used in this field are defined in Section 4.1: Coordinate System Definitions. In the case of UTM, you should also specify the zone number in the format "UTM Zx", where 1 <= x <= 60. For example, "UTM Z11".|
|horizontalDatum||The name of the geodetic datum. The list of valid codes that can be used in this field are defined in Section 4.3: Datum Definitions. For example, "W84".|
|verticalDatum||The name of the vertical datum (geoid). The list of valid codes that can be used in this field are defined in Section 4.3: Datum Definitions. For example, "W84".|
|ellipsoid||The name of the geodetic ellipsoid. The list of valid codes that can be used in this field are defined in Section 4.2: Ellipsoid Definitions. For example, "WE".|
|extent||The bounding coordinates for the dataset given in coordinate system specified by the coordinateSystem keyword. These are provided in the order eastmost, southmost, westmost, northmost, followed by the minimum and maximum elevation for the dataset. An example for GD is: "-180.0 -90.0 180.0 90.0 0.0 2000.0".|
|resolution||The resolution, or ground sample distance, given in units of meters. For example, "30".|
|originator||A string defining the originator of the data, for example the author, agency, organization, publisher, etc. For example, "Martin Reddy, SRI International, Menlo Park, CA 94025"|
|copyright||Any appropriate copyright declaration that pertains to the data. For example, "(c) Copyright 2001, SRI International. All rights reserved. Freely distributable."|
|date||A single date/time, or a date/time range, defining the valid time period that the data pertains to. Dates are specified in the format "YYYY MM DD [HH:MM]". Years in the current time period should be specified using four digits, e.g. "1999" or "2001". Years can have other than 4 digits and can be negative. A date range is specified by supplying two values separated by a "-" character. An optional time can be supplied should this level of accuracy be required. Times are to be specified in 24-hour format with respect to GMT. For example, "1999 01 01 00:00 - 1999 12 31 23:59".|
|metadataFormat||A string that specifies the format of the external metadata description pointed to by url field of the GeoMetadata node. For example, "FGDC", "ISO TC211", "CEN TC287", "OGC", etc.|
|dataUrl||A hypertext link to the source data used to create the VRML node(s) these metadata pertain to. Multiple dataUrl keyword/value pairs can be specified in order to provide alternative locations for the same source file. For example, "http://www.foo.bar/data/sf1".|
|dataFormat||A free-text string that describes the format of the source data used to create the VRML node(s) that these metadata pertain to. This refers to the source data pointed to by the dataUrl keyword (if present). For example, "USGS 7.5-min DEM".|
The data field is used to list all of the nodes that
implement the data described in the GeoMetadata node. For example, if
the GeoMetadata node is describing a height field grid, then you could
include the appropriate GeoElevationGrid node inside the data field.
The nodes in the data field are not rendered, so you can DEF/USE them
in order to first describe them and then to use them in the scene
graph This approach lets you associate multiple data nodes with a
single GeoMetadata node, specify multiple GeoMetadata nodes within a
single scene, and it also provides a mechanism to easily locate all of
the data that pertain to any particular metadata entry. If the data
field is not specified, then it is assumed that the GeoMetadata node
pertains to the entire scene.
EXTERNPROTO GeoOrigin [ exposedField SFString geoCoords # "" exposedField MFString geoSystem # [ "GD", "WE" ] field SFBool rotateYUp # FALSE ] [ "urn:web3d.org:vrml97:node:GeoOrigin" "file:///C:/Program%20Files/GeoVRML/1.1/protos/GeoOrigin.wrl" "http://www.geovrml.org/1.1/protos/GeoOrigin.wrl" ]
The GeoOrigin node defines an absolute geographic 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 fields geoSystem and geoCoords are described above in Sections 3.2.3 and 3.2.4.
The rotateYUp field is used to specify whether you wish all coordinates of any nodes that use this GeoOrigin to be rotated such that their up direction is aligned with VRML's Y axis. The default behavior is to not perform this operation, which means that the local up direction will depend upon the location of the GeoOrigin with respect to the planet surface. The principal reason for performing the rotation is to ensure that standard VRML97 navigation modes such as FLY and WALK, which assume that +Y = up, will function correctly. Note that specifying rotateYUp to be TRUE may incur an extra computational overhead in order to perform the rotation for each point.
N.B. you cannot define multiple local coordinate systems in a
single scene. Therefore, it is recommended that only one GeoOrigin
node is defined within a single VRML world, then all subsequent
geoOrigin fields can USE this GeoOrigin node.
EXTERNPROTO GeoPositionInterpolator [ eventIn SFFloat set_fraction field SFNode geoOrigin # NULL field MFString geoSystem # [ "GD", "WE" ] field MFFloat key #  field MFString keyValue #  eventOut SFVec3f value_changed eventOut SFString geovalue_changed ] [ "urn:web3d.org:vrml97:node:GeoPositionInterpolator" "file:///C:/Program%20Files/GeoVRML/1.1/protos/GeoPositionInterpolator.wrl" "http://www.geovrml.org/1.1/protos/GeoPositionInterpolator.wrl" ]
The GeoPositionInterpolator node provides an interpolator capability where key values are specified in geographic coordinates and the interpolation is performed within the specified spatial reference frame.
The fields geoSystem and geoOrigin are described above in Sections 3.2.3 and 3.2.5. The fields key, set_fraction, and value_changed have the same meaning as in the standard VRML PositionInterpolator [VRML97].
The keyValue string array is used to contain the actual coordinates and should be provided in a format consistent with that specified for the particular geoSystem. You must list one coordinate only in each string, e.g. [ "x1 y1 z1", "x2 y2 z2" ].
The geovalue_changed eventOut outputs the string defining
the interpolated coordinate in the spatial reference frame
specified by geoSystem. This can be passed to other
GeoVRML nodes that support an eventIn of this form, e.g. GeoViewpoint
EXTERNPROTO GeoTouchSensor [ exposedField SFBool enabled # TRUE field SFNode geoOrigin # NULL field MFString geoSystem # [ "GD", "WE" ] eventOut SFString hitGeoCoord_changed eventOut SFVec3f hitNormal_changed eventOut SFVec3f hitPoint_changed eventOut SFVec2f hitTexCoord_changed eventOut SFBool isActive eventOut SFBool isOver eventOut SFTime touchTime ] [ "urn:web3d.org:vrml97:node:GeoTouchSensor" "file:///C:/Program%20Files/GeoVRML/1.1/protos/GeoTouchSensor.wrl" "http://www.geovrml.org/1.1/protos/GeoTouchSensor.wrl" ]
A GeoTouchSensor node tracks the location and state of a pointing device and detects when the user points at geometry contained by the GeoTouchSensor's parent group. This node provides the same functionality as a VRML97 TouchSensor but also provides the ability to return the geographic coordinate under the pointing device. A GeoTouchSensor can be enabled or disabled by sending an event of value TRUE or FALSE to the enabled field. A disabled GeoTouchSensor does not track user input or send events.
The fields geoSystem and geoOrigin are described above in Sections 3.2.3 and 3.2.5. The eventOuts hitNormal_changed, hitPoint_changed, hitTexCoord_changed, isActive, isOver, and touchTime all have the same meaning as in the standard VRML TouchSensor [VRML97].
The hitGeoCoord_changed eventOut is generated while the
pointing device is pointing towards the GeoTouchSensor's geometry,
i.e. when isOver is TRUE. It is a string containing the
geographic coordinate for the point of intersection between the
pointing device's location and the underlying geometry. The value of
the geoSystem string defines the spatial reference frame that the
geographic coordinate is output using. For example, given the default
geoSystem value of "GD", the string will be in the format
"<latitude> <longitude> <elevation>" (see Section 3.2.4).
EXTERNPROTO GeoViewpoint [ eventIn SFBool set_bind eventIn SFString set_position eventIn SFString set_orientation exposedField SFFloat fieldOfView # 0.785398 exposedField SFBool headlight # TRUE exposedField SFBool jump # TRUE exposedField MFString navType # ["EXAMINE","ANY"] field SFString description # "" field SFNode geoOrigin # NULL field MFString geoSystem # ["GD","WE"] field SFRotation orientation # 0 0 1 0 field SFString position # "0 0 100000" field SFFloat speedFactor # 1.0 eventOut SFTime bindTime eventOut SFBool isBound ] [ "urn:web3d.org:vrml97:node:GeoViewpoint" "file:///C:/Program%20Files/GeoVRML/1.1/protos/GeoViewpoint.wrl" "http://www.geovrml.org/1.1/protos/GeoViewpoint.wrl" ]
The GeoViewpoint node allows you to specify a viewpoint in terms of a geographic coordinate.
You can use this node wherever you can use a standard Viewpoint node and you can combine GeoViewpoint and Viewpoint nodes in the same file. The fieldOfView, jump, description, set_bind, bindTime, and isBound fields and events have the same behavior as the standard Viewpoint node [VRML97]. Note that when a GeoViewpoint node is bound, it overrides the currently bound Viewpoint and NavigationInfo nodes in the scene.
The fields geoSystem and geoOrigin are described above in Sections 3.2.3 and 3.2.5.
The position string is used to define the actual coordinate that you wish to locate the viewpoint at. It should be provided in a format consistent with that specified for the particular geoSystem (see above). There is also a set_position eventIn which can be routed from the geovalue_changed eventOut of a GeoPositionInterpolator node in order to animate the position of the GeoViewpoint.
The orientation string defines a relative orientation from the local orientation frame that is defined by the position field. By default, the orientation of the viewpoint will always be aligned such that the +Y axis is the up vector for the local area (the normal to the tangent plane on the ellipsoid), -Z points towards the north pole, and +X is east. Therefore, if you wanted to create a GeoViewpoint that always looked straight down, no matter where on the earth you were looking, then you would supply an orientation value of [ 1 0 0 -1.57 ]. The set_orientation eventIn can be wired to the value_changed eventOut of a standard OrientationInterpolator in order to animate the orientation of the GeoViewpoint.
The navType field is used to specify the navigation type that is to be bound when this GeoViewpoint node is bound. The acceptable values for this field are the same as those for the type field of the standard VRML97 NavigationInfo field node, e.g. "EXAMINE", "WALK", "FLY", or "ANY".
The headlight field is used to specify the whether the browser shall turn on a headlight when this viewpoint is bound. A headlight is a directional light that always points in the direction that the user is looking.
The GeoViewpoint node may be implemented with an embedded NavigationInfo node that is bound and unbound with the GeoViewpoint node. If this is the case, then the implementation should internally set the speed, avatarSize, and visibilityLimit fields to an appropriate value for the viewpoint's elevation. Where supported by the browser, the implementation may continually set the speed field as the user moves in order to support elevation scaled velocity. See Section 3.2.2, for further details.
The speedFactor field of the GeoViewpoint node is used as a
multiplier to the elevation-based velocity that the node sets
internally, i.e. this is a relative value and not an absolute speed as
in the case for the standard VRML97 NavigationInfo field of the same
EXTERNPROTO InlineLoadControl [ exposedField SFBool load # TRUE exposedField MFString url #  field SFVec3f bboxCenter # 0 0 0 field SFVec3f bboxSize # -1 -1 -1 eventOut MFNode children ] [ "urn:web3d.org:vrml97:node:InlineLoadControl" "file:///C:/Program%20Files/GeoVRML/1.1/protos/InlineLoadControl.wrl" "http://www.geovrml.org/1.1/protos/InlineLoadControl.wrl" ]
The InlineLoadControl node (formerly called GeoInline) is a grouping node that reads its children data from a location in the World Wide Web. When its children are read and displayed is defined by the value of the load field. If the load field is set to TRUE (the default field value), then the VRML file specified by the url field is loaded immediately. If the load field is set to FALSE, then no action is taken. This node provides improved scalability over the standard VRML97 Inline node because the VRML97 specification (clause 6.25) does not define when the scene for an Inline node should be loaded.
If you specify the load field to be FALSE, then it is possible to explicitly load the URL at a later point by sending a TRUE event to the set_load eventIn of the node, e.g. via a ProximitySensor. Likewise, if you send a FALSE event to set_load, then any currently loaded world will be unloaded from the scene graph.
The set_url eventIn can be used to change the scene that is inlined by the InlineLoadControl node. If this value is set while a scene is already loaded, then that scene will be unloaded and the new scene that is pointed to by the new URL will be inlined.
The children eventOut is used to expose the scene graph hierarchy for the loaded VRML file. This is useful if you wish to inspect the nodes in the new part of the scene using an external interface such as the EAI (External Authoring Interface) [EAI]. This functionality is not available using the standard VRML97 Inline node.
The user is able to specify a bounding box for the InlineLoadControl node using the bboxCenter and bboxSize fields. This is a hint to the browser and could be used for optimization purposes such as culling. These fields are defined using raw VRML coordinates - the use of geographic coordinates are not supported in the bounding box fields (This is because the bboxSize and bboxCenter fields of group nodes in the VRML97 specification are not "exposed" fields and as a result their value cannot be set from within a Script node). As a result of this limitation, these two fields will be of little use to geographic modelers unless they know that the bounding box is to be specified in geocentric coordinates (GC) with no local origin. Otherwise, it is suggested that these fields be ignored.
Questions or comments.
Copyright 2002, SRI International.