Extensible 3D (X3D)
Part 1: Architecture and base components

25 Geospatial component

--- X3D separator bar ---

cube 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.3.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.

Table 25.1 — Topics in this clause

cube 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 includes conventions that are defined by the Spatial Reference Model standard 2.[I18026].

In total, nine nodes comprise the Geospatial component. These nodes are defined as follows.

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, most geo-referenced data are provided in a geodetic or projective spatial reference frame. A geodetic (or geographic) spatial reference frame is related to the ellipsoid used to model the earth, for example the latitude/longitude system. A projective spatial reference frame employs a projection of the ellipsoid onto some simple surface such as a cone or a cylinder, for example, the Lambert Conformal Conic (LCC) or the Universal Transverse Mercator (UTM) projections. In order to be useful to the geospatial community, X3D provides support for a number of nodes that can use spatial reference frames for modeling purposes. The spatial reference frames supported by X3D are defined in Table 25.2.

Table 25.2 — Supported spatial reference frames

Code Name
GD Geodetic spatial reference frame
GC Geocentric spatial reference frame
UTM Universal Transverse Mercator

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. In addition to these spatial reference frames, X3D defines 23 standard ellipsoids in order to model the shape of the earth. These are all defined in Table 25.3.

Table 25.3 — Supported earth ellipsoids

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

Finally, X3D supports the specification of a geoid, i.e. mean sea level. The list of geoids supported is presented in Table 25.4.

Table 25.4 — Supported earth geoids

Code Name
WGS84 WGS84 geoid

Internally, a X3D browser will transform all geographic coordinates into earth-fixed geocentric coordinates, i.e. an (x,y,z) displacement from the center of the earth 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 geocentric 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 we provide support 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.3 Specifying a spatial reference frame

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 the spatial reference frame. 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.

If no geoSystem field is specified, then the default value is [ "GD", "WE" ].

25.2.4 Specifying geospatial coordinates

Once the spatial reference frame has been defined, a single geographic coordinate is specified as an SFVec3D. Lists of geographic coordinates are encoded as an MFVec3D. The meaning of each component 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 meaning of each component is defined as follows.

25.2.5 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^23-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 geographic X3D nodes.

To illustrate this concept, imagine an example 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.6 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.

cube 25.3 Node reference

25.3.1 GeoCoordinate

GeoCoordinate : X3DCoordinateNode {
  SFNode   [] geoOrigin NULL        [GeoOrigin]
  MFString [] geoSystem ["GD","WE"] [see table]  
  MFVec3d  [] point     []
}

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.3.2 GeoElevationGrid

GeoElevationGrid : X3DComposedGeometryNode {
   MFDouble [in]     set_height
   SFFloat  [in]     set_yScale      1           [0,∞)
   SFNode   [in,out] color           NULL        [X3DColorNode]
   SFNode   [in,out] normal          NULL        [X3DNormalNode]
   SFNode   [in,out] texCoord        NULL        [X3DTextureCoordinateNode]
   SFBool   []       ccw             TRUE
   SFBool   []       colorPerVertex  TRUE
   SFDouble []       creaseAngle     0           [0,∞]
   SFVec3d  []       geoGridOrigin   0 0 0       (-∞,∞)
   SFNode   []       geoOrigin       NULL        [GeoOrigin]
   MFString []       geoSystem       ["GD","WE"] [see table]
   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.

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. For 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.3.3 GeoLocation

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

The GeoLocation node provides the ability to georeference 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.

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.3.4 GeoLOD

GeoLOD : X3DGroupingNode {
  MFNode   [in]  addChildren                [X3DSwitchNode]
  MFNode   [in]  removeChildren             [X3DSwitchNode]
  MFNode   [out] children       []          [X3DSwitchNode]
  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 table]
  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. 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.

GeoLOD Figure

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 the scene graph for the currently loaded set of nodes. The value returned as an event 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 shall generate a new children eventOut every time the scene graph is change (e.g., whenever nodes are loaded or unloaded).

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.3.5 GeoMetadata

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

The GeoMetadata node supports the specification of metadata describing any number of GeoX3D 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.

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

Keyword Value
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 spatial reference frame used to represent the data, e.g. GD, UTM, or LCC. The list of valid codes that can be used in this field are defined in 2.[I18026]. In the case of UTM, the zone number should also be specified in the format "UTM Zx", where the zone number is in the range [1,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 2.[I18026]. 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 2.[I18026]. 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 2.[I18026]. For example, "WE".
extent The bounding coordinates for the dataset given in spatial reference frame specified by the coordinateSystem keyword. These are provided in the order eastmost, southmost, westmost, northmost. An example for GD is: "-180.0 -90.0 180.0 90.0".
resolution The resolution, or ground sample distance, given in units of metres. For example, "30".
originator A string defining the originator of the data, for example the author, agency, organization, publisher, etc. For example, "John Doe, Any Corporation, Some Town, Some Country"
copyright Any appropriate copyright declaration that pertains to the data. For example, "(c) Copyright 2000, Any Corporation. All rights reserved. Freely distributable."
date A single date/time, or a date/time range, defining the valid time period to which the data pertains. 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 specified by the url field of the GeoMetadata node. For example, "FGDC", "ISO TC211", "CEN TC287", or "OGS".
dataUrl A hypertext link to the source data used to create the X3D node(s) to which this metadata pertains. Multiple dataUrl keyword/value pairs can be specified in order to provide alternative locations for the same source data. 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 X3D node(s) to which this metadata pertains. This refers to the source data specified by the dataUrl keyword (if present). For example, "USGS 5.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, 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.3.6 GeoOrigin

GeoOrigin : X3DInfoNode {
  SFVec3d  [in,out] geoCoords 0 0 0       (-∞,∞)
  MFString [in,out] geoSystem ["GD","WE"] [see table]
  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 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 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.3.7 GeoPositionInterpolator

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

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 GeoX3D nodes that support a field of this form (e.g., GeoViewpoint and GeoLocation).

25.3.8 GeoTouchSensor

GeoTouchSensor : X3DTouchSensorNode {
  SFBool   [in,out] enabled              TRUE
  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 Table]
}

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.

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.3.9 GeoViewpoint

GeoViewpoint : X3DBindableNode {
  SFBool     [in]     set_bind
  SFRotation [in]     set_orientation
  SFVec3d    [in]     set_position
  SFFloat    [in,out] fieldOfView    π/4        (0,π)
  SFBool     [in,out] headlight      TRUE
  SFBool     [in,out] jump           TRUE
  MFString   [in,out] navType        ["EXAMINE","ANY"]
  SFTime     [out]    bindTime
  SFBool     [out]    isBound
  SFString   []       description    ""
  SFNode     []       geoOrigin      NULL            [GeoOrigin]
  MFString   []       geoSystem      ["GD","WE"]     [see table]
  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.

cube 25.4 Support levels

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

Table 25.6 — Geospatial component support levels

Level Prerequisites Nodes/Features Support
1 Core 1
Time 1
Networking 1
Grouping 3
Rendering 1
Shape 1
Geometry3D 1
Interpolator 1
Point device sensor 1
Navigation 1

  The GeoCoordinate, GeoElevationGrid, GeoLocation, GeoLOD, GeoMetadata, GeoOrigin, GeoPositionInterpolator, GeoTouchSensor, and GeoViewpoint instantiable node types. All fields
--- X3D separator bar ---