25.1 Introduction

25.1.1 Name

The name of this component is "Geospatial". This name shall be used when referring to this component in the COMPONENT statement (see 7.2.5.4 Component statement).

25.1.2 Overview

This clause describes the Geospatial component of this part of  ISO/IEC 19775. This includes how to associate real world locations to elements in the X3D world as well as specifying nodes particularly tuned for geospatial applications. Table 25.1 provides links to the major topics in this clause.

25.2 Concepts

25.2.1 Overview

This section contains discussions of various important concepts that are integral to the Geospatial component, providing support for geographic and geospatial applications. This support includes the ability to embed geospatial coordinates in certain X3D nodes, to support high-precision geospatial modeling, and to handle large multi-resolution terrain databases. These concepts are described below. The Geospatial component incorporates the conventions that are defined by the Spatial Reference Model (see ISO/IEC 18026).

NOTE  The prefix "geo" traditionally refers to the planet Earth. For backwards compatibility with earlier versions of X3D and VRML, the prefix "geo" is retained in node names and for the name of this component. However, when spatial coordinates involved refer to non-Earth objects, the prefix "geo" is defined to be the same as the prefix "celestio" as used in ISO/IEC 18026.

25.2.2 Spatial reference frames

X3D defines an implicit Cartesian, right-handed three-dimensional coordinate system for modeling purposes, as defined in 4.3.6 Standard units and coordinate system. However, geo-referenced data are provided in a coordinate system incorporated in a spatial reference frame (SRF) that is aligned to a celestial object. Since explicitly specifying the characteristics of any celestial object is not practical, an object reference model (ORM) is used to model the celestial object. Two types of ORMs are found, those that model the physical shape of the object (usually an ellipsoid) and those that model the gravitic shape of the object (termed a geoid). For the planet Earth, a common geoid is one that models mean sea level.

EXAMPLE 1  A Geodetic SRF specifies coordinates in a latitude/longitude/elevation system can be aligned to the Earth using the WGS1984 geoid.

Other SRFs may be aligned to other celestial bodies. ISO/IEC 18026 provides models for all of the planets, minor planets, and the sun for the solar system that contains Earth.

EXAMPLE 2  It is possible to specify a Planetodetic SRF that is aligned to Mars.

A projective spatial reference frame employs a projection of the ellipsoid onto some simple surface such as a cone or a cylinder.

EXAMPLE 3  The Lambert Conformal Conic (LCC) and the Universal Transverse Mercator (UTM) projections.

X3D provides support for a number of nodes that can use SRFs for modeling purposes.

25.2.3 Predefined SRFs

For the convenience of authors that do not have intimate experience with specifying SRFs, this part of ISO/IEC 19775 predefines some commonly used SRFs. The predefined SRFs are listed in Table 25.2 and are based on the reference object in question. Other SRFs for the Earth or for non-Earth celestial objects may be specified using the facilities of the Geospatial component as specified in 25.2.4 Explicit SRF definition.

The code GDC shall be synonymous to GD and the code GCC shall be synonymous to GC. However, these two synonyms may be subject to future deprecation.

For use with these predefined SRFs, X3D supports 23 standard ellipsoids that model the shape of the Earth. These are all defined in Table 25.3.

Finally, X3D supports the selection of an Earth geoid representing mean sea level. The list of geoids that can be used in the predefined SRFs is presented in Table 25.4.

25.2.4 Explicit SRF definition

When the predefined SRFs do not adequately support the needs of the author, a more advanced set of nodes is provided that allow the specification of an arbitrary SRF that exactly satisfies those needs. This is done by creating a GeoReferenceSurfaceInfo node as specified in 25.2.6.3 Specifying an explicitly defined SRF. Any 3D SRF supported by ISO/IEC 18026 can be specified in this manner.

25.2.5 Internal SRF processing

Internally, an X3D browser will transform all spatial coordinates into ORM-fixed celestiocentric coordinates (i.e., an (x,y,z) displacement from the center of the ORM in units of metres). This is a 3D Cartesian coordinate system that best integrates with X3D's implicit coordinate system. In addition, an offset may be applied to these celestiocentric coordinates if a GeoOrigin node is supplied (see 25.2.5 Dealing with high-precision coordinates). The resulting coordinates are cast to single-precision and are the final values used for rendering. This process means that support is provided for increased precision around an area of interest, and also enable data specified in multiple spatial reference frames to be fused into a single context.

25.2.6 Specifying a spatial reference frame

25.2.6.1 Overview

All the X3D nodes that allow inclusion of geographic coordinates support a field called geoSystem. This field is used to specify the particular spatial reference frame that will be used for the geospatial coordinates in that node. This is an MFString field that can include a number of arguments to fully designate or identify the spatial reference frame.

Spatial reference frames can be specified either by using the X3D predefined SRFs or by referencing an explicitly defined SRF.

25.2.6.2 Specifying a predefined SRF

When specifying an X3D predefined SRF, each argument appears in a separate string within the MFString array. Argument matching is case sensitive. Optional arguments may appear in any order. The following values are 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 Table 25.3. 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) (see Table 25.4); otherwise, all elevations will be relative to the ellipsoid. An example spatial reference frame definition of this format is [ "GD", "WD" ], for a geodetic spatial reference frame based upon the WGS72 ellipsoid with all elevations being relative to that ellipsoid.

• "UTM" - Universal Transverse Mercator. 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 Table 25.3. 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 (see Table 25.4)); 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 frame definition of this format is ["GC"].

If no geoSystem field is specified, the default value specifies a predefined SRF of ["GD", "WE"].

25.2.6.3 Specifying an explicitly defined SRF

25.2.6.3.1 Overview

An explicitly defined SRF has all parameters specified in the SRF definition. Thus, only one entry is needed in the geoSystem field. Such an entry shall exactly specify a string that is identical to the name field of an explicitly defined SRF.

There are three ways to specify an explicitly defined SRF:

1. SRF templates,
2. SRF sets, and
3. standardized SRFs

Each will be summarized below. Full details of each method are in ISO/IEC 18026.

NOTE  It is possible to explicitly define all of the predefined SRFs by using one of these methods.

25.2.6.3.2 SRF templates

An SRF template is a method in which full details of the SRF parameterization are separately specified. In this part of ISO/IEC 19775, a GeoSRFParametersInfo node is used in which the srfParametersInfo field contains a GeoSRFTemplate node. A separate SRF template is available depending on the type of SRF to be defined. A description of each of the available templates is in 8.5 of ISO/IEC 18026. The template parameters are then coupled with the selection of an ORM as specified by the ormCode field.

25.2.6.3.3 SRF sets

In some cases, SRFs exist as a family. The predefined SRF "UTM" is one such. In this case, an SRF is defined by selecting the particular SRF set along with a selection of a set member. In this part of ISO/IEC 19775, a GeoSRFParametersInfo node is used in which the srfParametersInfo field contains a GeoSRFSet node. The SRF set (specified by the srfsCode field) and member (specified by the srfsMember field) are then coupled with an ORM as specified by the ormCode field. A description of the available SRF sets and the members of each set is in 8.7 of ISO/IEC 18026.

25.2.6.3.4 Standardized SRFs

In some cases, a standard parameterization of an SRF exists. In this case, it is only necessary to select the standard to precisely define the SRF.  In this part of ISO/IEC 19775, a GeoSRFParametersInfo node is used in which the srfParametersInfo field contains a GeoSRFInstance node. The SRF instance is selected by specifying a code in the srfCode field. A description of each fo the available standardized SRFs is available in 8.6 of ISO/IEC 18026.

NOTE  Standard SRFs also specify the ORM to be used.

25.2.7 Specifying spatial coordinates

Once the spatial reference frame has been defined, a single spatial coordinate is specified as an SFVec3D. Lists of spatial coordinates are encoded as an MFVec3D. The meaning of each component of the spatial coordinate value depends upon the particular spatial reference frame that was defined via the geoSystem field in the same node.

For X3D predefined SRFS with the following geoSystem definitions, the meaning of each component is defined as follows.

• 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 metres above the ellipsoid (the default) or above the WGS84 geoid (if you supplied the "WGS84" parameter in the geoSystem field).
  
  EXAMPLE  (37.4506, −122.1834, 0) is the latitude/longitude coordinate for Menlo Park, California, USA.

• 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. Northings, eastings, and elevation are all given in units of metres. 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  the "WGS84" parameter is specified in the geoSystem field).
  
  EXAMPLE  (4145173, 572227, 0) is the zone 10 northern hemisphere UTM coordinate for Menlo Park, California, USA.

• GC: (<x>, <y>, <z>). These values are all given in units of metres. The coordinate represents an 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.
  
  EXAMPLE  (−2700301, −4290762, 3857213) is the geocentric coordinate for Menlo Park, California, USA.

For explicitly defined SRFS, the components have the meanings specified in ISO/IEC 18026 for that type of SRF. There are three types of spatial coordinates specified in ISO/IEC 18026:

1. 3D,
2. surface, and
3. 2D

3D coordinates provide three-dimensional information and exact placement within the X3D world. Surface coordinates have only two components but represent a position on the surface of the ORM that is part of the SRF definition and therefore have an implicit zero value for elevation. 2D coordinates also have two components that represent a position on the XZ-plane of the X3D world coordinate system and thus have an implied zero Y value.  

NOTE  For the various types of celestiodetic, geodetic, or planetodetic coordinates, interchange of the meaning of the first and second coordinate components is not allowed.

25.2.8 Dealing with high-precision coordinates

Most computer graphics systems, including X3D, use single-precision floating point values to model and render all geometry. This is a natural design constraint since computer graphics typically deals with small screens (up to around 1600 x 1280 pixels), and locally bounded regions. As a result, there is no need to use double-precision values because any increases in accuracy that it brings would be lost in sub-pixel noise.

However, single-precision is insufficient to model data over the range of the earth at accurate ground resolutions. With only 23 bits of mantissa, a coordinate can be accurate to only one part in 8 million (2²³-1); or about 6 or 7 decimal digits of precision. Since the equatorial radius of the earth (considered as an example planetary body) is 6,378,137 m (under the WGS84 ellipsoid), it is not possible to achieve resolutions better than around 0.8 metres using single-precision floating point numbers (6,378,137 / 8,388,607 = 0.8). Below this threshold, various floating point rounding artifacts such as vertices coalescing and camera jitter will occur.

This geo-referencing problem is one avoided by establishing a geo-referenced local coordinate system (LCS). An absolute geo-referenced location is defined as the origin of the LCS. This becomes the reference point that correlates to the X3D world's (0,0,0) origin. Any subsequent geospatial locations are translated into X3D's Cartesian coordinate system relative to this LCS origin. Moreover, by allowing the user to define these local frames easily, the creator of the geo-referenced data uses the accuracy of a single-precision floating point representation by creating X3D worlds of only limited local extent. This is the purpose of the GeoOrigin node, as specified via the geoOrigin field of the geospatial X3D nodes.

EXAMPLE  Consider a case where the GeoOrigin is specified as (310385.0 e, 4361550.0 n, 0 m, zone 13) in UTM coordinates. This may be transformed to a double-precision geocentric coordinate of (−1459877.12, −4715646.92, 4025213.19). Then a supplied absolute UTM coordinate of (310400.0 e, 4361600.0 n, 0 m, zone 13) may be transformed internally to a geocentric coordinate of (−1459854.51, −4715620.48, 4025252.11). Finally, this absolute geocentric coordinate can be transformed to a single-precision local Cartesian coordinate system by subtracting the GeoOrigin location to give (22.61, 26.44, 38.92), which is within single-precision range.

25.2.9 Geospatial navigation issues

There are a number of navigation issues that are specific to the task of browsing large geographic areas. One important issue is addressed here, that of elevation scaled velocity.

The velocity at which users can navigate around a world should depend upon their height above the terrain. For example, when flying over the coast at a height of 100 metres above the terrain, a velocity of 100 metres per second could be considered relatively fast. However, when approaching the earth from outer space, a velocity of 100 metres per second would be intolerably slow. Creators of geographic visualization systems have therefore learned to scale the velocity of the user's navigation in an attempt to maintain a constant pixel flow across the screen. A simple linear relationship between velocity and the user's elevation above an ellipsoid such as WGS84 often provides an acceptable and easily computable solution to this problem. This behavior is addressed by the GeoViewpoint node.

25.3 Abstract types

25.3.1 X3DGeoSRFParametersInfoNode

X3DSRFParametersInfoNode : X3DNode {
  SFNode  [in,out] metadata              NULL [X3DMetadataObject]
  SFInt32 []       rtCode                0    [see 11.2.7.6 of ISO/IEC 18026]
}

The X3DSRFParametersInfoNode abstract node type is the base type for the specifications of SRF definitions.

The rtCode field identifies a reference transformation for the SRF. Valid rtCode field values are specified in 11.2.7.6 of ISO/IEC 18026.

25.3.2 X3DGeoSRFParametersNode

X3DSRFParametersNode : X3DNode {
  SFNode   [in,out] metadata  NULL        [X3DMetadataObject]
}

The X3DGeoSRFParametersNode abstract node type is the base type for the specification of the form of SRF being defined an SRF. Three specific forms are provided as follows (see 8 of ISO/IEC 18026:

1. SRF template
2. SRF instances
3. SRF sets

The basic means for defining an SRF is to use an SRF template. Any individual SRF may be specified by using the appropriate SRF template. A complete discussion of SRF templates is available in 8.5 of ISO/IEC 18026.

In some cases, governments or other agencies may predefine specific SRFs. Rather than requiring knowledge of all of the parameters needed to specify one of these SRFs using an SRF template, a table of such standardized SRFs is provided in 8.6 of ISO/IEC 18026 from which the appropriate selection can be made.

EXAMPLE 1  British National Grid

When number of SRFs are inherently related to each other, they can form an SRF set. Such SRFs have a common ORM but have slightly different parameterizations depending on the region of the ORM to which a specific member is to be applied.

EXAMPLE 2  The set of Universal Transverse Mercator (UTM) SRFs in which members are selected by specifying one of sixty zones.

25.3.3 X3DGeoSRFTParametersNode

X3DSRFTParametersNode : X3DNode {
  SFNode   [in,out] metadata  NULL        [X3DMetadataObject]
}

The X3DSRFTParametersNode abstract node type is the base type for the specifications of SRF-specific parameters used when defining an SRF based on an SRF template (see 8.5 of ISO/IEC 18026.

25.4 Node reference

25.4.1 GeoCoordinate

GeoCoordinate : X3DCoordinateNode {
  SFNode   [in,out] metadata  NULL        [X3DMetadataObject]
  MFVec3d  [in,out] point     []
  SFNode   []       geoOrigin NULL        [GeoOrigin]
  MFString []       geoSystem ["GD","WE"] [see 25.2.3]  
}

The GeoCoordinate node specifies a list of coordinates in a spatial reference frame. It is used in the coord field of vertex-based geometry nodes including IndexedFaceSet, IndexedLineSet, and PointSet.

The geoOrigin field is used to specify a local coordinate frame for extended precision as described in 25.2.5 Dealing with high-precision coordinates.

The geoSystem field is used to define the spatial reference frame and is described in 25.2.3 Specifying a spatial reference frame.

The point array is used to contain the actual geospatial coordinates and should be provided in a format consistent with that specified for the particular geoSystem (see above). The geospatial coordinates are transparently transformed into a geocentric, curved-earth representation. For example, this would allow a geographer to create a X3D world where all coordinates are specified in terms of latitude, longitude, and elevation.

25.4.2 GeoECParameters

GeoECParameters : X3DGeoSRFTParametersNode {
  SFString [in,out] description     ""
  SFNode   [in,out] metadata        NULL    [X3DMetadataObject]
  SFDouble []       centralScale    0       (-∞,∞)
  SFDouble []       falseEasting    0       (-∞,∞)
  SFDouble []       falseNorthing   0       (-∞,∞)
  SFDouble []       originLongitude 0       (-∞,∞)
  SFString []       polarAspect     "NORTH" ["North|"South"]
}

A GeoECParameters node specifies the parameters required to define a Equidistant Cylindrical (EC) SRF (see 11.2.9.2.1 in ISO/IEC 18026. EC SRFs are fully described in 8.5.24 of ISO/IEC 18026.

25.4.3 GeoElevationGrid

GeoElevationGrid : X3DGeometryNode {
  MFDouble [in]     set_height
  SFNode   [in,out] color           NULL        [X3DColorNode]
  SFNode   [in,out] metadata        NULL        [X3DMetadataObject]
  SFNode   [in,out] normal          NULL        [X3DNormalNode]
  SFNode   [in,out] texCoord        NULL        [X3DTextureCoordinateNode]
  SFFloat  [in,out] yScale          1.0         [0,∞)
  SFBool   []       ccw             TRUE
  SFBool   []       colorPerVertex  TRUE
  SFDouble []       creaseAngle     0           [0,∞)
  SFVec3d  []       geoGridOrigin   0 0 0       (-∞,∞)
  SFNode   []       geoOrigin       NULL        [GeoOrigin]
  MFString []       geoSystem       ["GD","WE"] [see 25.2.3]
  MFDouble []       height          [0 0]       (0,∞)
  SFBool   []       normalPerVertex TRUE
  SFBool   []       solid           TRUE
  SFInt32  []       xDimension      0           (0,∞)
  SFDouble []       xSpacing        1.0         [0,∞)
  SFInt32  []       zDimension      0           (0,∞)
  SFDouble []       zSpacing        1.0         [0,∞)
}

The GeoElevationGrid node specifies a uniform grid of elevation values within some 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 all coordinates are specified in terms of latitude, longitude, and elevation.

The fields color, colorPerVertex, texCoord, normal, and normalPerVertex all have the same meaning as for ElevationGrid (see 13.3.4 ElevationGrid).

The ccw, solid, and creaseAngle fields are described in 11.2.3 Common geometry fields.

The geoOrigin field is used to specify a local coordinate frame for extended precision as described in 25.2.5 Dealing with high-precision coordinates.

The geoSystem field is used to define the spatial reference frame and is described in 25.2.3 Specifying a spatial reference frame.

The geoGridOrigin field specifies the geographic coordinate for the south-west corner (bottom-left) of the dataset. This value should be specified as described in 25.2.4 Specifying geospatial coordinates.

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 (metres) between adjacent height values and zSpacing refers to the number of northings (metres) between vertical height values.

EXAMPLE  If xDimension = n and the grid spans d units horizontally, the xSpacing value should be set to:

d / (n−1).

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 this value is set greater than 1.0, all heights will appear larger than actual.

25.4.4 GeoLCCParameters

GeoLCCParameters : X3DGeoSRFTParametersNode {
  SFString [in,out] description     ""
  SFNode   [in,out] metadata        NULL [X3DMetadataObject]
  SFDouble []       falseEasting    0    (-∞,∞)
  SFDouble []       falseNorthing   0    (-∞,∞)
  SFDouble []       latitude1       0    (-∞,∞)
  SFDouble []       latitude2       0    (-∞,∞)
  SFDouble []       originLongitude 0    (-∞,∞)
  SFDouble []       originLatitude  0    (-∞,∞)
}

A GeoLCCParameters node specifies the parameters required to define a Lambert Conformal Conic (LCC) SRF (see 11.2.9.2.2 in ISO/IEC 18026. LCC SRFs are fully described in 8.5.22 of ISO/IEC 18026.

25.4.5 GeoLCE3DParameters

GeoLCE3DParameters : X3DGeoSRFTParametersNode {
  SFString [in,out] description   ""
  SFNode   [in,out] metadata      NULL  [X3DMetadataObject]
  SFVec3f  []       lococentre    0 0 0 [-1,1]
  SFVec3f  []       primaryAxis   0 1 0 [-1,1]
  SFVec3f  []       secondaryAxis 0 0 1 [-1,1]
}

A GeoLCE3DParameters node specifies the parameters required to define a Lococentric Euclidean 3D (LCE 3D) SRF (see 11.2.9.2.7 in ISO/IEC 18026. LCE 3D SRFs are fully described in 8.5.9 of ISO/IEC 18026.

25.4.6 GeoLocalTangentParameters

GeoLocalTangentParameters : X3DGeoSRFTParametersNode {
  SFString [in,out] description       ""
  SFNode   [in,out] metadata          NULL [X3DMetadataObject]
  SFDouble []       azimuth           0    (-∞,∞)
  SFDouble []       geodeticLatitude  0    (-∞,∞)
  SFDouble []       geodeticLongitude 0    (-∞,∞)
  SFDouble []       heightOffset      0    (-∞,∞)
  SFDouble []       x_false_origin    0    (-∞,∞)
  SFDouble []       y_false_origin    0    (-∞,∞)
}

A GeoLocalTangentParameters node specifies the parameters required to define Local Tangent Space Azimuthal Spherical (LTSAS) and Local Tangent Space Cylindrical (LTSC) SRFs (see 11.2.9.2.5 in ISO/IEC 18026. LTSAS SRFs are fully described in 8.5.7 of ISO/IEC 18026. LTSC SRFs are fully described in 8.5.8 of ISO/IEC 18026.

25.4.7 GeoLocation

GeoLocation : X3DGroupingNode {
  MFNode   [in]     addChildren                [X3DChildNode]
  MFNode   [in]     removeChildren             [X3DChildNode]
  MFNode   [in,out] children       []          [X3DChildNode]
  SFVec3d  [in,out] geoCoords      0 0 0       (-∞,∞)
  SFNode   [in,out] metadata       NULL        [X3DMetadataObject]
  SFNode   []       geoOrigin      NULL        [GeoOrigin]
  MFString []       geoSystem      ["GD","WE"] [see 25.2.3]
  SFVec3f  []       bboxCenter     0 0 0       (-∞,∞)
  SFVec3f  []       bboxSize       -1 -1 -1    [0,∞) or −1 −1 −1
}

The GeoLocation node provides the ability to geo-reference any standard X3D model. That is, to take an ordinary X3D model, contained within the children field of the node, and to specify its geospatial location. 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 geoOrigin field is used to specify a local coordinate frame for extended precision as described in 25.2.5 Dealing with high-precision coordinates.

The geoSystem field is used to define the spatial reference frame and is described in 25.2.3 Specifying a spatial reference frame.

The geometry of the nodes in children is to be specified in units of metres in X3D coordinates relative to the location specified by the geoCoords field. The geoCoords field should be provided in the format described in 25.2.3 Specifying a spatial reference frame.

The geoCoords field can be used to dynamically update the geospatial location of the model; for example, an event could be sent from a GeoPositionInterpolator node.

In addition to placing a X3D model at the correct geospatial location, the GeoLocation node will also adjust the orientation of the model appropriately. The standard X3D coordinate system specifies that the +Y axis = up, +Z = out of the screen, and +X = towards the right. The GeoLocation node will set the orientation so that 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.

25.4.8 GeoLOD

GeoLOD : X3DChildNode, X3DBoundedObject {
  SFNode   [in,out] metadata       NULL        [X3DMetadataObject]
  MFNode   [out]    children       []          [X3DChildNode]
  SFInt32  [out]    level_changed
  SFVec3d  []       center         0 0 0       (-∞,∞)
  MFString []       child1Url      []          [urn]
  MFString []       child2Url      []          [urn]
  MFString []       child3Url      []          [urn]
  MFString []       child4Url      []          [urn]
  SFNode   []       geoOrigin      NULL        [GeoOrigin]
  MFString []       geoSystem      ["GD","WE"] [see 25.2.3]
  SFFloat  []       range          10          [0,∞)
  MFString []       rootUrl        []          [urn]
  MFNode   []       rootNode       []          [X3DChildNode]
  SFVec3f  []       bboxCenter     0 0 0       (-∞,∞)
  SFVec3f  []       bboxSize       -1 -1 -1    [0,∞) or −1 −1 −1
}

The GeoLOD node provides a terrain-specialized form of the 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 metres from the geospatial coordinate center.  The center field should be specified as described in 25.2.4 Specifying geospatial coordinates.

The geoOrigin field is used to specify a local coordinate frame for extended precision as described in 25.2.5 Dealing with high-precision coordinates.

The geoSystem field is used to define the spatial reference frame and is described in 25.2.3 Specifying a spatial reference frame.

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 25.1 illustrates this process. The child URLs shall be arranged in the same order as in the figure; i.e., child1Url represents the bottom-left quadtree child. It is valid to specify less than four 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 25.1 — Loading of GeoLOD levels

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 X3D 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 field is used to expose a portion of the scene graph for the currently loaded set of nodes. The value returned as an event is an MFNode containing the currently selected tile. This will either be the node specified by the rootNode field or the nodes specified by the child1Url, child2Url, child3Url, and child4Url fields. The GeoLOD node shall generate a new children output event each time the scene graph is changed (EXAMPLE whenever nodes are loaded or unloaded). When the new children event is generated, the GeoLOD node shall also generate a level_changed event with value 0 or 1 indicating the value of the whichChoice field of the Switch node.

The GeoLOD node may optionally 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.

25.4.9 GeoLSR3DParameters

GeoLSR3DParameters : X3DGeoSRFTParametersNode {
  SFString [in,out] description      ""
  SFNode   [in,out] metadata         NULL [X3DMetadataObject]
  SFInt32  []       forwardDirection 2    [see 11.2.6.2 of ISO/IEC 18026]
  SFInt32  []       up_direction     1    [see 11.2.6.2 of ISO/IEC 18026]
}

A GeoLSR3DParameters node specifies the parameters required to define a Local Space Rectangular (LSR) 3D SRF (see 11.2.9.2.4 in ISO/IEC 18026. LSR 3D SRFs are fully described in 8.5.3 of ISO/IEC 18026. All X3D non-spatial coordinate systems are LSR 3D coordinate systems.

The forwardDirection field specifies which axis of the LSR 3D coordinate system represents the forward direction. See Table 25.x for the mapping from the SRM enumerated type to integers to be used in this part of ISO/IEC 19775. The default value for this field corresponds to the Z axis of the world coordinate system of X3D.

The upDirection field specifies which axis of the LSR 3D coordinate system represents the up direction.  See Table 25.x for the mapping from the SRM enumerated type to integers to be used in this part of ISO/IEC 19775. The default value for this field corresponds to the Y axis of the world coordinate system of X3D.

25.4.10 GeoLTSEParameters

GeoLTSEParameters : X3DGeoSRFTParametersNode {
  SFString [in,out] description       ""
  SFNode   [in,out] metadata          NULL [X3DMetadataObject]
  SFDouble []       azimuth           0    (-∞,∞)
  SFDouble []       geodeticLatitude  0    (-∞,∞)
  SFDouble []       geodeticLongitude 0    (-∞,∞)
  SFDouble []       heightOffset      0    (-∞,∞)
  SFDouble []       x_false_origin    0    (-∞,∞)
  SFDouble []       y_false_origin    0    (-∞,∞)
}

A GeoLTSEParameters node specifies the parameters required to define a Local Tangent Space Euclidean (LTSE) SRF (see 11.2.9.2.6 in ISO/IEC 18026. LTSE SRFs are fully described in 8.5.6 of ISO/IEC 18026.

25.4.11 GeoMetadata

GeoMetadata : X3DInfoNode {
  MFNode   [in,out] data     []   [urn]
  SFNode   [in,out] metadata NULL [X3DMetadataObject]
  MFString [in,out] summary  []
  MFString [in,out] url      []   [urn]
}

The GeoMetadata node supports the specification of metadata describing any number of geospatial nodes. This is similar to a WorldInfo node, but specifically for describing geospatial information.

There are a number of standards and representations for geospatial metadata. 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. More specific metadata can be specified using the metadata field available in each node.

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 information. The summary field may be used 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. Table 25.5 specifies a number of keywords and the format that should be used to describe their values. If an unknown keyword is found, it (and its associated value) are ignored.

Table 25.5 — GeoMetadata keywords and values

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, the appropriate GeoElevationGrid node could be included inside the data field. The nodes in the data field are not rendered, so DEF/USE can be used in order to first describe them and then to use them in the scene graph This approach allows associating multiple data nodes with a single GeoMetadata node, specifying multiple GeoMetadata nodes within a single scene, and 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, it is assumed that the GeoMetadata node pertains to the entire scene.

25.4.12 GeoMParameters

GeoMParameters : X3DGeoSRFTParametersNode {
  SFString [in,out] description     ""
  SFNode   [in,out] metadata        NULL [X3DMetadataObject]
  SFDouble []       centralScale    0    (-∞,∞)
  SFDouble []       falseEasting    0    (-∞,∞)
  SFDouble []       falseNorthing   0    (-∞,∞)
  SFDouble []       originLongitude 0    (-∞,∞)
}

A GeoMParameters node specifies the parameters required to define a Mercator SRF (see 11.2.9.2.8 in ISO/IEC 18026. Mercator SRFs are fully described in 8.5.19 of ISO/IEC 18026.

25.4.13 GeoObliqueMercatorParameters

GeoObliqueMercatorParameters : X3DGeoSRFTParametersNode {
  SFString [in,out] description   ""
  SFNode   [in,out] metadata      NULL [X3DMetadataObject]
  SFDouble []       centralScale  0    (-∞,∞)
  SFDouble []       falseEasting  0    (-∞,∞)
  SFDouble []       falseNorthing 0    (-∞,∞)
  SFDouble []       longitude1    0    (-∞,∞)
  SFDouble []       latitude1     0    (-∞,∞)
  SFDouble []       longitude2    0    (-∞,∞)
  SFDouble []       latitude2     0    (-∞,∞)
}

A GeoObliqueMercatorParameters node specifies the parameters required to define an Oblique Mercator Spherical SRF (see 11.2.9.2.9 in ISO/IEC 18026. Oblique Mercator Spherical SRFs are fully described in 8.5.20 of ISO/IEC 18026.

25.4.14 GeoOrigin

GeoOrigin : X3DNode {
  SFVec3d  [in,out] geoCoords 0 0 0       (-∞,∞)
  SFNode   [in,out] metadata  NULL        [X3DMetadataObject]
  MFString []       geoSystem ["GD","WE"] [see 25.2.3]
  SFBool   []       rotateYUp FALSE
}

The GeoOrigin node defines an absolute geospatial 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 X3D browser.

The geoCoords field is used to specify a local coordinate frame for extended precision as described in 25.2.5 Dealing with high-precision coordinates.

The geoSystem field is used to define the spatial reference frame and is described in 25.2.3 Specifying a spatial reference frame.

The rotateYUp field is used to specify whether coordinates of nodes that use this GeoOrigin are to be rotated such that their up direction is aligned with the X3D Y axis. The default behavior is to not perform this operation. This 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 navigation modes such as "FLY" and "WALK", which assume that +Y = up, will function correctly. Specifying rotateYUp to be TRUE may incur an extra computational overhead in order to perform the rotation for each point.

25.4.15 GeoPositionInterpolator

GeoPositionInterpolator : X3DInterpolatorNode {
  SFFloat  [in]     set_fraction                 (-∞,∞)
  MFFloat  [in,out] key              []          (-∞,∞)
  MFVec3d  [in,out] keyValue         []
  SFNode   [in,out] metadata         NULL        [X3DMetadataObject]
  SFVec3d  [out]    geovalue_changed
  SFVec3f  [out]    value_changed
  SFNode   []       geoOrigin        NULL        [GeoOrigin]
  MFString []       geoSystem        ["GD","WE"] [see 25.2.3]
}

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 geoOrigin field is used to specify a local coordinate frame for extended precision as described in 25.2.5 Dealing with high-precision coordinates.

The geoSystem field is used to define the spatial reference frame and is described in 25.2.3 Specifying a spatial reference frame.

The fields key, set_fraction, and value_changed have the same meaning as in the PositionInterpolator node.

The keyValue array is used to contain the actual coordinates and should be provided in a format consistent with that specified for the particular geoSystem.

The geovalue_changed field outputs the the interpolated coordinate in the spatial reference frame specified by geoSystem. This can be passed to other X3D Geospatial component nodes that support a field of this form (e.g., GeoViewpoint and GeoLocation).

25.4.16 GeoProximitySensor

GeoProximitySensor : X3DEnvironmentalSensorNode {
  SFBool     [in,out] enabled                  TRUE
  SFVec3d    [in,out] geoCenter                0 0 0       (-∞,∞)
  SFNode     [in,out] metadata                 NULL        [X3DMetadataObject]
  SFVec3f    [in,out] size                     0 0 0       [0,∞)
  SFVec3f    [out]    centerOfRotation_changed
  SFTime     [out]    enterTime
  SFTime     [out]    exitTime
  SFVec3d    [out]    geoCoord_changed
  SFBool     [out]    isActive
  SFRotation [out]    orientation_changed
  SFVec3f    [out]    position_changed
  SFNode     []       geoOrigin                NULL        [GeoOrigin]
  MFString   []       geoSystem                ["GD","WE"] [see 25.2.3]
}

The GeoProximitySensor node generates events when the viewer enters, exits, and moves within a region in space (defined by a box).

A GeoProximitySensor node generates isActive events as the viewer enters and exits the rectangular box defined by its geoCenter and size fields. This box is oriented tangent to the ellipsoid in a local coordinate system.

The fields geoSystem and geoOrigin are described in 25.2.3 Specifying a spatial reference frame and 25.2.5 Dealing with high-precision coordinates, respectively.

The geoCoord_changed generates an event that returns the geospatial coordinates of the viewer's position in the spatial reference frame specified by geoSystem for the viewer's position whenever a position_changed event is generated. The geoCoord_changed value corresponds to the world position returned by position_changed.

The remaining fields are defined in 22.4.1 ProximitySensor.

25.4.17 GeoPSParameters

GeoPSParameters : X3DGeoSRFTParametersNode {
  SFString [in,out] description     ""
  SFNode   [in,out] metadata        NULL    [X3DMetadataObject]
  SFDouble []       centralScale    0       (-∞,∞)
  SFDouble []       falseEasting    0       (-∞,∞)
  SFDouble []       falseNorthing   0       (-∞,∞)
  SFDouble []       originLongitude 0       (-∞,∞)
  SFString []       polarAspect     "NORTH" ["North|"South"]
}

A GeoPSParameters node specifies the parameters required to define a Polar Stereographic (PS) SRF (see 11.2.9.2.10 in ISO/IEC 18026. PS SRFs are fully described in 8.5.23 of ISO/IEC 18026.

25.4.18 GeoReferenceSurfaceInfo

GeoReferenceSurfaceInfo : X3DNode {
  SFString [in,out] description       ""
  SFNode   [in,out] metadata          NULL [X3DMetadataObject]
  SFInt32  []       dssCode           0    [see 11.2.7.3 of ISO/IEC 18026]
  SFString []       name              ""
  SFNode   []       srfParametersInfo NULL [X3DSRFParametersInfoNode]
}

A GeoReferenceSurfaceInfo node specifies parameters for the SRF in the srfParametersInfo field and associates those parameters with a designated spatial surface (DSS) (see 11.2.7.3 in ISO/IEC 18026) specified by the dssCode field. Designated spatial surfaces are fully described in Clause 9 of ISO/IEC 18026.

The name field assigns a name to this SRF specification for use in the geoSystems field of other Geospatial component nodes. This name shall not be the same as any of the predefined names specified in 25.2.3 Predefined SRFs.

25.4.19 GeoSRFInstance

GeoSRFInstance : X3DGeoSRFParametersNode {
  SFString [in,out] description    ""
  SFNode   [in,out] metadata       NULL [X3DMetadataObject]
  SFInt32  []       srfCode        0    [see 11.2.7.7 of ISO/IEC 18026]
}

A GeoSRFInstance node specifies a specific predefined SRF (see 11.9.3 in ISO/IEC 18026). SRF instances are fully described in 8.6 of ISO/IEC 18026.

25.4.20 GeoSRFParametersInfo

GeoSRFParametersInfo : X3DGeoSRFParametersInfoNode {
  SFString [in,out] description       ""
  SFNode   [in,out] metadata          NULL [X3DMetadataObject]
  SFInt32  []       rtCode            0    [See 11.2.7.6 of ISO/IEC 18026]
  SFNode   []       srfParametersInfo NULL [X3DGeoSRFParametersNode]
}

A GeoSRFParametersInfo node specifies the parameters of an arbitrary SRF. All SRFs specified in ISO/IEC 18026 are supported. The various forms of SRF required depend on the particular node that populates the srfParametersInfo field.

25.4.21 GeoSRFSet

GeoSRFSet : X3DGeoSRFParametersNode {
  SFString [in,out] description    ""
  SFNode   [in,out] metadata       NULL [X3DMetadataObject]
  SFInt32  []       ormCode        250  [see 11.2.7.4 of ISO/IEC 18026]
  SFInt32  []       srfsCode       0    [see 11.2.7.8 of ISO/IEC 18026]
  SFInt32  []       srfsMember     0    [see 11.2.9.2.11 of ISO/IEC 18026]
}

A GeoSRFSet node specifies the definition of an SRF based on an SRF set (see 11.9.3 in ISO/IEC 18026. SRF sets are fully described in 8.7 of ISO/IEC 18026.

SRF sets are a collection of related predefined SRFs.  The srfsCode field selects among the available SRF sets.

The srfsMember field selects a specific SRF within the SRF set specified by the srfsCode field. The number of available members is part of the definition of the SRF set.

The default values specify an unspecified set associated with the WGS_1984 Earth geoid ORM.

25.4.22 GeoSRFTemplate

GeoSRFTemplate : X3DGeoSRFParametersNode {
  SFString [in,out] description    ""
  SFNode   [in,out] metadata       NULL [X3DMetadataObject]
  SFInt32  []       ormCode        250  [see 11.2.7.4 of ISO/IEC 18026]
  SFInt32  []       srftCode       1    [see 11.2.7.10 of ISO/IEC 18026]
  SFNode   []       srftParameters NULL [X3DSRFTParametersNode]
}

A GeoSRFTemplate node specifies the definition of an SRF based on an SRF template (see 11.9.2 in ISO/IEC 18026. SRF templates are fully described in 8.5 of ISO/IEC 18026.

The ormCode field identifies an object reference model (ORM) that forms the basis for the SRF. Valid ormCode field values are specified in 11.2.7.4 of ISO/IEC 18026.

The srftCode field identifies the type of SRF being defined. Valid values for the srftCode field are specified in 11.2.7.10 of ISO/IEC 18026. The srftCode value determines the node to use as the value of the srfParameters field, if any. Some srftCode values do not require additional parameters.

The default values specify a Celestiocentric SRF for the WGS_1984 Earth geoid ORM.

25.4.23 GeoTMParameters

GeoTMParameters : X3DGeoSRFTParametersNode {
  SFString [in,out] description     ""
  SFNode   [in,out] metadata        NULL [X3DMetadataObject]
  SFDouble []       centralScale    0    (-∞,∞)
  SFDouble []       falseEasting    0    (-∞,∞)
  SFDouble []       falseNorthing   0    (-∞,∞)
  SFDouble []       originLongitude 0    (-∞,∞)
  SFDouble []       originLatitude  0    (-∞,∞)
}

A GeoTMParameters node specifies the parameters required to define a Transverse Mercator SRF (see 11.2.9.2.12 in ISO/IEC 18026. Mercator SRFs are fully described in 8.5.21 of ISO/IEC 18026.

25.4.24 GeoTouchSensor

GeoTouchSensor : X3DTouchSensorNode {
  SFString [in,out] description         ""
  SFBool   [in,out] enabled             TRUE
  SFNode   [in,out] metadata            NULL        [X3DMetadataObject]
  SFVec3f  [out]    hitNormal_changed
  SFVec3f  [out]    hitPoint_changed
  SFVec2f  [out]    hitTexCoord_changed
  SFVec3d  [out]    hitGeoCoord_changed
  SFBool   [out]    isActive
  SFBool   [out]    isOver
  SFTime   [out]    touchTime
  SFNode   []       geoOrigin           NULL        [GeoOrigin]
  MFString []       geoSystem           ["GD","WE"] [see 25.2.3]
}

A GeoTouchSensor node tracks the location and state of a pointing device and detects when the user points at geometry contained by the parent group of the GeoTouchSensor. This node provides the same functionality as a TouchSensor but also provides the ability to return the geographic coordinate under the pointing device.

The description field in the GeoTouchSensor node specifies a textual description of the GeoTouchSensor node. This may be used by browser-specific user interfaces that wish to present users with more detailed information about the GeoTouchSensor.

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 geoOrigin field is used to specify a local coordinate frame for extended precision as described in 25.2.5 Dealing with high-precision coordinates.

The geoSystem field is used to define the spatial reference frame and is described in 25.2.3 Specifying a spatial reference frame.

The fields hitNormal_changed, hitPoint_changed, hitTexCoord_changed, isActive, isOver, and touchTime all have the same meaning as in the TouchSensor node.

The hitGeoCoord_changed field is generated while the pointing device is pointing towards the GeoTouchSensor's geometry (i.e., when isOver is TRUE). It is a field containing the geospatial 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 of the geospatial coordinate. For example, given the default geoSystem value of "GD", the hitGeoCoord_changed field will be in the format (<latitude> <longitude> <elevation>) (see 25.2.4 Specifying geospatial coordinates).

25.4.25 GeoTransform

GeoTransform : X3DGroupingNode {
  MFNode     [in]     addChildren               [X3DChildNode]
  MFNode     [in]     removeChildren            [X3DChildNode]
  MFNode     [in,out] children         []       [X3DChildNode]
  SFVec3d    [in,out] geoCenter        0 0 0    (-∞,∞)
  SFNode     [in,out] metadata         NULL     [X3DMetadataObject]
  SFRotation [in,out] rotation         0 0 1 0  [-1,1] or (-∞,∞)
  SFVec3f    [in,out] scale            1 1 1    (0,∞)
  SFRotation [in,out] scaleOrientation 0 0 1 0  [-1,1] or (-∞,∞)
  SFVec3f    [in,out] translation      0 0 0    (-∞,∞)
  SFVec3f    []       bboxCenter       0 0 0    (-∞,∞)
  SFVec3f    []       bboxSize         -1 -1 -1 [0,∞) or −1 −1 −1
  SFNode     []       geoOrigin                 NULL        [GeoOrigin]
  MFString   []       geoSystem                 ["GD","WE"] [see 25.2.3]
}

The GeoTransform node is a grouping node that defines a coordinate system for its children allow for the translation and orientation of geometry built using GeoCoordinate nodes within the local world coordinate system. The X-Z plane of a GeoTransform coordinate system is tangent to the ellipsoid of the spatial reference frame at the location specified by the geoCenter field.

The geoCenter field specifies, in the spatial reference frame specified by the geoSystem field, the location at which the local coordinate system is centered.

The fields geoSystem and geoOrigin are described in 25.2.3 Specifying a spatial reference frame and 25.2.5 Dealing with high-precision coordinates, respectively.

The remaining fields are defined in 10.4.4 Transform.

25.4.26 GeoViewpoint

GeoViewpoint : X3DViewpointNode {
  SFBool     [in]     set_bind
  SFRotation [in]     set_orientation
  SFVec3d    [in]     set_position
  SFString   [in,out] description     ""
  SFFloat    [in,out] fieldOfView     π/4               (0,π)
  SFBool     [in,out] headlight       TRUE
  SFBool     [in,out] jump            TRUE
  SFNode     [in,out] metadata        NULL              [X3DMetadataObject]
  MFString   [in,out] navType         ["EXAMINE","ANY"]
  SFTime     [out]    bindTime
  SFBool     [out]    isBound
  SFNode     []       geoOrigin       NULL              [GeoOrigin]
  MFString   []       geoSystem       ["GD","WE"]       [see 25.2.3]
  SFRotation []       orientation     0 0 1 0           (-∞,∞) or -1 1
  SFVec3d    []       position        0 0 100000        (-∞,∞)
  SFFloat    []       speedFactor     1.0               [0,∞)
}

The GeoViewpoint node allows the specification of a viewpoint in terms of a geospatial coordinate. This node can be used wherever a Viewpoint node can be used and can be combined with Viewpoint nodes in the same scene. The fieldOfView, jump, description, set_bind, bindTime, and isBound fields and events have the same behavior as the standard Viewpoint node. When a GeoViewpoint node is bound, it overrides the currently bound Viewpoint and NavigationInfo nodes in the scene.

The geoOrigin field is used to specify a local coordinate frame for extended precision as described in 25.2.5 Dealing with high-precision coordinates.

The geoSystem field is used to define the spatial reference frame and is described in 25.2.3 Specifying a spatial reference frame.

The position is used to define the actual coordinate at which the viewpoint is to be located. It should be provided in a format consistent with that specified by geoSystem. There is also a set_position field which can be routed from the geovalue_changed field 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 a GeoViewpoint is created that always looked straight down, no matter where on the planetary body is being observed, an orientation value of [ 1 0 0 -1.57 ] is used. The set_orientation field can be routed to the value_changed field of an 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 NavigationInfo 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 as if there is an embedded NavigationInfo node that is bound and unbound with the GeoViewpoint node. As such, a X3D browser should internally set the speed, avatarSize, and visibilityLimit fields to an appropriate value for the viewpoint's elevation. The X3D browser should also continually update the speed field as the user moves in order to support elevation scaled velocity (see 25.2.6 Geospatial Navigation Issues). It is recommended that the speed of user interaction be defined as:

( elevation  / 10.0 ) metres per second

where elevation is the user's elevation above the WGS84 ellipsoid in units of metres. It is also recommended that the same scaling factor be applied to the avatarSize vector.

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 is the case for the NavigationInfo node.

25.4 Support levels

The Geospatial component provides one level of support as specified in Table 25.6.