previous   next   contents
GeoVRML 1.0 Recommended Practice

3. Nodes

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.

3.2 General Concepts

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. If future revisions of the VRML specification include support for a double floating-point type, then we could specify geographic coordinates as lists of numbers instead of strings, therefore taking 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 Geographic Coordinate System

All GeoVRML nodes that allow you the inclusion of geographic coordinates support a field called geoSystem. This field is used to specify the particular coordinate system 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.

• "GDC" - Geodetic coordinate system (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 "GD" 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 coordinate system definition of this format is [ "GDC", "WD" ], for a geodetic coordinate system based upon the WGS72 ellipsoid with all elevations being relative to that ellipsoid.

• "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 "GD" 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 coordinate system definition of this format is [ "UTM", "Z10", "S", "GD" ], for a southern hemisphere UTM coordinate system in zone 10 with all elevations being with respect to mean sea level.

• "GCC" - Earth-fixed Geocentric with respect to the WGS84 ellipsoid. No additional arguments are supported. An example coordinate system definition of this format is [ "GCC" ].

If no geoSystem field is specified, then the default value is "GDC".

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 coordinate system 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:

• GDC - "<latitude> <longitude> <elevation>". 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 "GD" 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>". 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 "GD" parameter in the geoSystem field). For example, "4145173 572227 0" is the zone 10 northern hemisphere UTM coordinate for Menlo Park, CA.

• GCC - "<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.0, 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.

3.3 GeoCoordinate

EXTERNPROTO GeoCoordinate [
   field  SFNode    geoOrigin    # NULL
   field  MFString  geoSystem    # [ "GDC" ]
   field  MFString  point        # []
] [ "urn:web3d:geovrml:1.0/protos/GeoCoordinate.wrl"
    "file:///C|/Program%20Files/GeoVRML/1.0/protos/GeoCoordinate.wrl"
    "http://www.geovrml.org/1.0/protos/GeoCoordinate.wrl" ]

The GeoCoordinate node lets you specify a list of coordinates in a geographic coordinate system. 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" ].

3.4 GeoElevationGrid

EXTERNPROTO GeoElevationGrid [
   eventIn       MFFloat   set_height
   eventIn       SFFloat   set_yScale
   exposedField  SFNode    color             # NULL
   exposedField  SFNode    normal            # NULL
   exposedField  SFNode    texCoord          # NULL
   field         SFNode    geoOrigin         # NULL
   field         MFString  geoSystem         # [ "GDC" ]
   field         SFString  geoGridOrigin     # "0 0 0"
   field         MFFloat   height            # []
   field         SFBool    ccw               # TRUE
   field         SFBool    colorPerVertex    # TRUE
   field         SFFloat   creaseAngle       # 0
   field         SFBool    normalPerVertex   # TRUE
   field         SFBool    solid             # TRUE
   field         SFInt32   xDimension        # 0
   field         SFString  xSpacing          # "1.0"
   field         SFInt32   zDimension        # 0
   field         SFString  zSpacing          # "1.0"
   field         SFFloat   yScale            # 1.0
] [ "urn:web3d:geovrml:1.0/protos/GeoElevationGrid.wrl"
    "file:///C|/Program%20Files/GeoVRML/1.0/protos/GeoElevationGrid.wrl"
    "http://www.geovrml.org/1.0/protos/GeoElevationGrid.wrl" ]

The GeoElevationGrid node lets you specify a grid of elevations within a geographic coordinate system. 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 GDC, 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.

3.5 GeoInline

EXTERNPROTO GeoInline [
   field    MFString url           # []
   eventIn  MFString set_url              
   eventOut MFString url_changed
   field    SFBool   load          # TRUE
   eventIn  SFBool   set_load
   eventOut SFBool   load_changed
   field    SFVec3f  bboxCenter    # 0 0 0
   field    SFVec3f  bboxSize      # -1 -1 -1
   eventOut MFNode   children
] [ "urn:web3d:geovrml:1.0/protos/GeoInline.wrl"
    "file:///C|/Program%20Files/GeoVRML/1.0/protos/GeoInline.wrl"
    "http://www.geovrml.org/1.0/protos/GeoInline.wrl" ]

The GeoInline node 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 (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 GeoInline 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 GeoInline 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 (GCC) with no local origin. Otherwise, it is suggested that these fields be ignored.

3.6 GeoLocation

EXTERNPROTO GeoLocation [
   field    SFNode    geoOrigin          # NULL
   field    MFString  geoSystem          # [ "GDC" ]
   field    SFString  geoCoords          # ""
   eventIn  SFString  set_geoCoords
   eventOut SFString  geoCoords_changed
   field    MFNode    children           # []
] [ "urn:web3d:geovrml:1.0/protos/GeoLocation.wrl"
    "file:///C|/Program%20Files/GeoVRML/1.0/protos/GeoLocation.wrl"
    "http://www.geovrml.org/1.0/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.

3.7 GeoLOD

EXTERNPROTO GeoLOD [
  field     SFNode   geoOrigin    # NULL
  field     MFString geoSystem    # [ "GDC" ]
  field     MFString rootUrl 	  # []
  field     MFNode   rootNode     # []
  field     MFString child1Url 	  # []
  field     MFString child2Url 	  # []
  field     MFString child3Url 	  # []
  field     MFString child4Url 	  # []
  field     SFString center       # ""
  field     SFFloat  range        # 10
  eventOut  MFNode   children
] [ "urn:web3d:geovrml:1.0/protos/GeoLOD.wrl"
    "file:///C|/Program%20Files/GeoVRML/1.0/protos/GeoLOD.wrl"
    "http://www.geovrml.org/1.0/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 quadtree like representation 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.

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.

3.8 GeoMetadata

EXTERNPROTO GeoMetadata [
   exposedField MFString url        # []
   exposedField MFString summary    # []
   exposedField MFNode   data       # []
] [ "urn:web3d:geovrml:1.0/protos/GeoMetadata.wrl"
    "file:///C|/Program%20Files/GeoVRML/1.0/protos/GeoMetadata.wrl"
    "http://www.geovrml.org/1.0/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.

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.

3.9 GeoOrigin

EXTERNPROTO GeoOrigin [
  exposedField  MFString  geoSystem    # [ "GDC" ]
  exposedField  SFString  geoCoords    # ""
  field         SFBool    rotateYUp    # FALSE
] [ "urn:web3d:geovrml:1.0/protos/GeoOrigin.wrl"
    "file:///C|/Program%20Files/GeoVRML/1.0/protos/GeoOrigin.wrl"
    "http://www.geovrml.org/1.0/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.

3.10 GeoPositionInterpolator

EXTERNPROTO GeoPositionInterpolator [
  eventIn      SFFloat  set_fraction
  field        SFNode   geoOrigin          # NULL
  field        MFString geoSystem          # [ "GDC" ]
  field        MFFloat  key                # []
  field        MFString keyValue           # []
  eventOut     SFVec3f  value_changed
  eventOut     SFString geovalue_changed
] [ "urn:web3d:geovrml:1.0/protos/GeoPositionInterpolator.wrl"
    "file:///C|/Program%20Files/GeoVRML/1.0/protos/GeoPositionInterpolator.wrl"
    "http://www.geovrml.org/1.0/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 coordinate system.

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 geographic coordinate system specified by geoSystem. This can be passed to other GeoVRML nodes that support an eventIn of this form, e.g. GeoViewpoint and GeoLocation.

3.11 GeoTouchSensor

EXTERNPROTO GeoTouchSensor [
  exposedField SFBool   enabled             # TRUE
  field        SFNode   geoOrigin           # NULL
  field        MFString geoSystem           # [ "GDC" ]
  eventOut     SFVec3f  hitNormal_changed
  eventOut     SFVec3f  hitPoint_changed
  eventOut     SFVec2f  hitTexCoord_changed
  eventOut     SFBool   isActive
  eventOut     SFBool   isOver
  eventOut     SFTime   touchTime
  eventOut     SFString hitGeoCoord_changed
] [ "urn:web3d:geovrml:1.0/protos/GeoTouchSensor.wrl"
    "file:///C|/Program%20Files/GeoVRML/1.0/protos/GeoTouchSensor.wrl"
    "http://www.geovrml.org/1.0/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 coordinate system that the geographic coordinate is output using. For example, given the default geoSystem value of "GDC", the string will be in the format "<latitude> <longitude> <elevation>" (see Section 3.2.4).

3.12 GeoViewpoint

EXTERNPROTO GeoViewpoint [
  eventIn       SFBool      set_bind
  eventIn       SFString    set_position
  eventIn       SFString    set_orientation
  field         SFNode      geoOrigin        # NULL
  field         MFString    geoSystem        # ["GDC"]
  exposedField  SFFloat     fieldOfView      # 0.785398
  exposedField  SFBool      jump             # TRUE
  field         SFRotation  orientation      # 0 0 1 0
  field         SFString    position         # "0 0 100000"
  field         SFString    description      # ""
  exposedField  SFBool      headlight        # TRUE
  field         SFFloat     speed            # 1.0
  exposedField  MFString    navType          # ["EXAMINE","ANY"]
  eventOut      SFTime      bindTime
  eventOut      SFBool      isBound
] [ "urn:web3d:geovrml:1.0/protos/GeoViewpoint.wrl"
    "file:///C|/Program%20Files/GeoVRML/1.0/protos/GeoViewpoint.wrl"
    "http://www.geovrml.org/1.0/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 speed 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 name.

Questions or comments.
Copyright 2000, SRI International.