<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html lang="en">
<HEAD>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<TITLE>Extensible 3D (X3D), ISO/IEC FCD 19775-1r1:200x, 25 Geospatial Component</TITLE>
<link rel="stylesheet" href="../X3D.css" type="text/css">
<style type="text/css">
.style1 {
list-style-type: lower-alpha;
}
</style>
</HEAD>
<BODY>
<div class="CenterDiv">
<IMG class="x3dlogo" SRC="../../Images/x3d.png" ALT="X3D logo" style="width: 176px; height: 88px">
</div>
<div class="CenterDiv">
<p class="HeadingPart">
Extensible 3D (X3D)<br />
Part 1: Architecture and base components</p>
<p class="HeadingClause">25 Geospatial component</p>
</div>
<IMG class="x3dbar" SRC="../../Images/x3dbar.png" ALT="--- X3D separator bar ---" width="430" height="23">
<h1><a name="Introduction"></a>
<img class="cube" src="../../Images/cube.gif" alt="cube" width="20" height="19">
25.1 Introduction</h1>
<h2><a name="Name"></a>25.1.1 Name</h2>
<p>The name of this component is "Geospatial". This name shall be used when referring
to this component in the COMPONENT statement (see
<a href="core.html#COMPONENTStatement">7.2.5.4 Component statement</a>).</p>
<h2><a name="Overview"></a>25.1.2 Overview</h2>
<p>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.
<a href="#t-Topics">Table 25.1</a> provides links to the major topics in
this clause.</p>
<div class="CenterDiv">
<p class="TableCaption">
<a name="t-Topics"></a>
Table 25.1 — Topics</p>
<table class="topics">
<tr>
<td>
<ul>
<li><a href="#Introduction">25.1 Introduction</a>
<ul>
<li><a href="#Name">25.1.1 Name</a></li>
<li><a href="#Overview">25.1.2 Overview</a> </li>
</ul></li>
<li><a href="#Concepts">25.2 Concepts</a>
<ul>
<li><a href="#ConceptsOverview">25.2.1 Overview</a>
<li><a href="#PredefinedSRFs">25.2.2 Spatial reference frames</a></li>
<li><a href="#PredefinedSRFs">25.2.3 Predefined SRFs</a></li>
<li><a href="#ExplicitSRFDefinition">25.2.4 Explicit SRF
definition</a></li>
<li><a href="#InternalSRFProcessing">25.2.5 Internal SRF
processing</a></li>
<li><a href="#Specifyingaspatialreference">25.2.6 Specifying a
spatial reference frame</a><ul>
<li><a href="#SpecifyingASpatialReferenceFrameOverview">25.2.6.1
Overview</a></li>
<li><a href="#SpecifyingAPredefinedSRF">25.2.6.2 Specifying a
predefined SRF</a></li>
<li><a href="#SpecifyingAnExplicitlyDefinedSRF">25.2.6.3
Specifying an explicitly defined SRF</a><ul>
<li><a href="#SpecifyingAnExplictlyDefinedSRFOverview">25.2.6.3.1
Overview</a></li>
<li><a href="#SRFTemplates">25.2.6.3.2 SRF templates</a></li>
<li><a href="#SRFSets">25.2.6.3.3 SRF sets</a></li>
<li><a href="#StandardizedSRFs">25.2.6.3.4 Standardized SRFs</a></li>
</ul></li>
</ul></li>
<li><a href="#SpecifyingSpatialCoordinates">25.2.7 Specifying geospatial coordinates</a></li>
<li><a href="#high-precisioncoords">25.2.8 Dealing with high-precision coordinates</a></li>
<li><a href="#navigationissues">25.2.9 Geospatial navigation issues</a></li>
</ul></li>
<li><a href="#AbstactTypes">25.3 Abstract types</a>
<ul>
<li><a href="#X3DSRFParametersInfoNode">25.3.1 <i>
X3DGeoSRFParametersInfoNode</i></a></li>
<li><a href="#X3DSRFParametersNode">25.3.2 <i>
X3DGeoSRFParametersNode</i></a></li>
<li><a href="#X3DSRFTParametersNode">25.3.3 <i>
X3DGeoSRFTParametersNode</i></a></li>
</ul><a href="#Nodereference">25.4 Node reference</a>
<ul>
<li><a href="#GeoCoordinate">25.4.1 GeoCoordinate</a></li>
<li><a href="#GeoECParameters">25.4.2 GeoECParameters</a></li>
<li><a href="#GeoElevationGrid">25.4.3 GeoElevationGrid</a></li>
<li><a href="#GeoLCCParameters">25.4.4 GeoLCCParameters</a></li>
<li><a href="#GeoLCE3DParameters">25.4.5 GeoLCE3DParameters</a></li>
<li><a href="#GeoLocalTangentParameters">25.4.6
GeoLocalTangentParameters</a></li>
<li><a href="#GeoLocation">25.4.7 GeoLocation</a></li>
<li><a href="#GeoLOD">25.4.8 GeoLOD</a></li>
<li><a href="#GeoLSR3DParameters">25.4.9 GeoLSR3DParameters</a></li>
<li><a href="#GeoLTSEParameters">25.4.10 GeoLTSEParameters</a></li>
<li><a href="#GeoMetadata">25.4.11 GeoMetadata</a></li>
<li><a href="#GeoMParameters">25.4.12 GeoMParameters</a></li>
<li><a href="#GeoObliqueMercatorParameters">25.4.13
GeoObliqueMercatorParameters</a></li>
<li><a href="#GeoOrigin">25.4.14 GeoOrigin</a></li>
<li><a href="#GeoPositionInterpolator">25.4.15 GeoPositionInterpolator</a></li>
<li><a href="#GeoProximitySensor">25.4.16 GeoProximitySensor</a></li>
<li><a href="#GeoPSParameters">25.4.17 GeoPSParameters</a></li>
<li><a href="#GeoReferenceSurfaceInfo">25.4.18
GeoReferenceSurfaceInfo</a></li>
<li><a href="#GeoSRFInstance">25.4.19 GeoSRFInstance</a></li>
<li><a href="#GeoSRFParametersInfo">25.4.20 GeoSRFParametersInfo</a></li>
<li><a href="#GeoSRFSet">25.4.21 GeoSRFSet</a></li>
<li><a href="#GeoSRFTemplate">25.4.22 GeoSRFTemplate</a></li>
<li><a href="#GeoTMParameters">25.4.23 GeoTMParameters</a></li>
<li><a href="#GeoTouchSensor">25.4.24 GeoTouchSensor</a></li>
<li><a href="#GeoTransform">25.4.25 GeoTransform</a></li>
<li><a href="#GeoViewpoint">25.4.26 GeoViewpoint</a></li>
</ul></li>
<li><a href="#SupportLevels">25.4 Support levels</a></li>
</ul>
<ul>
<li><a href="#f-LoadingGeoLODlevels">Figure 25.1 — Loading of GeoLOD levels</a></li>
</ul>
<ul>
<li><a href="#t-Topics">Table 25.1 — Topics</a></li>
<li><a href="#t-X3DPredefinedSRFs">Table 25.2 — Supported spatial reference frames</a></li>
<li><a href="#t-earthellipsoids">Table 25.3 — Supported earth ellipsoids</a></li>
<li><a href="#t-earthgeoids">Table 25.4 — Supported earth geoids</a></li>
<li><a href="#t-keywordsandvalues">Table 25.5 — GeoMetadata keywords and values</a></li>
<li><a href="#t-supportlevels">Table 25.6 — Geospatial component support levels</a></li>
</ul>
</td>
</tr>
</table>
</div>
<h1><img class="cube" src="../../Images/cube.gif" alt="cube" width="20" height="19">
<a name="Concepts"></a>
25.2 Concepts</h1>
<h2><a name="ConceptsOverview"></a>25.2.1 Overview</h2>
<p>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 <a href="../references.html#[I18026]">
ISO/IEC 18026</a>).</p>
<p class="Example">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 <a href="../references.html#[I18026]">
ISO/IEC 18026</a>.</p>
<h2>
<a name="Spatialreferenceframes"></a>
25.2.2 Spatial reference frames</h2>
<p>X3D defines an implicit Cartesian, right-handed three-dimensional
coordinate system for modeling purposes, as defined in
<a href="../concepts.html#Standardunitscoordinates">4.3.6 Standard units and
coordinate system</a>.
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
<em>geoid</em>). For the planet Earth, a common geoid is
one that models mean sea level.</p>
<p class="Example">EXAMPLE 1 A Geodetic SRF specifies coordinates in a latitude/longitude/elevation system
can be aligned to the Earth using the WGS1984 geoid. </p>
<p>Other SRFs may be aligned to other celestial bodies. <a href="../references.html#[I18026]">
ISO/IEC 18026</a> provides models for all of the planets, minor planets, and the
sun for the solar system that contains Earth.</p>
<p class="Example">EXAMPLE 2 It is possible to specify a Planetodetic SRF
that is aligned to Mars.</p>
<p>A
projective spatial reference frame employs a projection of the
ellipsoid onto some simple surface such as a cone or a cylinder.</p>
<p class="Example">EXAMPLE 3 The Lambert Conformal Conic (LCC) and the Universal Transverse
Mercator (UTM) projections. </p>
<p>X3D provides support for a number of nodes that can use SRFs for modeling
purposes. </p>
<h2>
<a name="PredefinedSRFs"></a>25.2.3 Predefined SRFs</h2>
<p>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 <a
href="#t-X3DPredefinedSRFs"> Table 25.2</a> 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
<a href="#ExplicitSRFDefinition">25.2.4 Explicit SRF definition</a>.</p>
<div class="CenterDiv">
<p class="TableCaption">
<a name="t-X3DPredefinedSRFs"></a>Table 25.2 — X3D predefined spatial reference frames</p>
<table>
<tbody>
<tr>
<th>Code</th>
<th>Name</th>
</tr>
<tr>
<td><span style="font-size: 92%; font-weight: 700">GD</span></td>
<td>Geodetic spatial reference frame</td>
</tr>
<tr>
<td><b>GC</b></td>
<td>Geocentric spatial reference frame</td>
</tr>
<tr>
<td><b>UTM</b></td>
<td>Universal Transverse Mercator spatial reference frame</td>
</tr>
</tbody>
</table>
</div>
<p>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.</p>
<p>For use with these predefined SRFs, X3D supports 23 standard
ellipsoids that model the shape of the Earth. These are all
defined in <a href="#t-earthellipsoids">Table 25.3</a>.</p>
<div class="CenterDiv">
<p class="TableCaption">
<a name="t-earthellipsoids"></a>
Table 25.3 — Supported earth ellipsoids</p>
<table>
<tbody>
<tr>
<th>Code</th>
<th>Ellipsoid Name</th>
<th><b>Semi-Major Axis<br>
(metres)</b></th>
<th><b>Inv. Flattening<br>
(F<sup>-1</sup>)</b></th>
</tr>
<tr>
<th><span style="font-size: 92%">AA</span></th>
<td>Airy 1830</td>
<td>6377563.396</td>
<td>299.3249646</td>
</tr>
<tr>
<th><span style="font-size: 92%">AM</span></th>
<td>Modified Airy</td>
<td>6377340.189</td>
<td>299.3249646</td>
</tr>
<tr>
<th><span style="font-size: 92%">AN</span></th>
<td>Australian National</td>
<td>6378160</td>
<td>298.25</td>
</tr>
<tr>
<th><span style="font-size: 92%">BN</span></th>
<td>Bessel 1841 (Namibia)</td>
<td>6377483.865</td>
<td>299.1528128</td>
</tr>
<tr>
<th><span style="font-size: 92%">BR</span></th>
<td>Bessel 1841 (Ethiopia Indonesia...)</td>
<td>6377397.155</td>
<td>299.1528128</td>
</tr>
<tr>
<th><span style="font-size: 92%">CC</span></th>
<td>Clarke 1866</td>
<td>6378206.4</td>
<td>294.9786982</td>
</tr>
<tr>
<th><span style="font-size: 92%">CD</span></th>
<td>Clarke 1880</td>
<td>6378249.145</td>
<td>293.465</td>
</tr>
<tr>
<th><span style="font-size: 92%">EA</span></th>
<td>Everest (India 1830)</td>
<td>6377276.345</td>
<td>300.8017</td>
</tr>
<tr>
<th><span style="font-size: 92%">EB</span></th>
<td>Everest (Sabah & Sarawak)</td>
<td>6377298.556</td>
<td>300.8017</td>
</tr>
<tr>
<th><span style="font-size: 92%">EC</span></th>
<td>Everest (India 1956)</td>
<td>6377301.243</td>
<td>300.8017</td>
</tr>
<tr>
<th><span style="font-size: 92%">ED</span></th>
<td>Everest (W. Malaysia 1969)</td>
<td>6377295.664</td>
<td>300.8017</td>
</tr>
<tr>
<th><span style="font-size: 92%">EE</span></th>
<td>Everest (W. Malaysia & Singapore 1948)</td>
<td>6377304.063</td>
<td>300.8017</td>
</tr>
<tr>
<th><span style="font-size: 92%">EF</span></th>
<td>Everest (Pakistan)</td>
<td>6377309.613</td>
<td>300.8017</td>
</tr>
<tr>
<th><span style="font-size: 92%">FA</span></th>
<td>Modified Fischer 1960</td>
<td>6378155</td>
<td>298.3</td>
</tr>
<tr>
<th><span style="font-size: 92%">HE</span></th>
<td>Helmert 1906</td>
<td>6378200</td>
<td>298.3</td>
</tr>
<tr>
<th><span style="font-size: 92%">HO</span></th>
<td>Hough 1960</td>
<td>6378270</td>
<td>297</td>
</tr>
<tr>
<th><span style="font-size: 92%">ID</span></th>
<td>Indonesian 1974</td>
<td>6378160</td>
<td>298.247</td>
</tr>
<tr>
<th><span style="font-size: 92%">IN</span></th>
<td>International 1924</td>
<td>6378388</td>
<td>297</td>
</tr>
<tr>
<th><span style="font-size: 92%">KA</span></th>
<td>Krassovsky 1940</td>
<td>6378245</td>
<td>298.3</td>
</tr>
<tr>
<th><span style="font-size: 92%">RF</span></th>
<td>Geodetic Reference System 1980 (GRS 80)</td>
<td>6378137</td>
<td>298.257222101</td>
</tr>
<tr>
<th><span style="font-size: 92%">SA</span></th>
<td>South American 1969</td>
<td>6378160</td>
<td>298.25</td>
</tr>
<tr>
<th><span style="font-size: 92%">WD</span></th>
<td>WGS 72</td>
<td>6378135</td>
<td>298.26</td>
</tr>
<tr>
<th><span style="font-size: 92%">WE</span></th>
<td>WGS 84</td>
<td>6378137</td>
<td>298.257223563</td>
</tr>
</tbody>
</table>
</div>
<p>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
<a href="#t-earthgeoids">
Table 25.4</a>.</p>
<div class="CenterDiv">
<p class="TableCaption">
<a name="t-earthgeoids"></a>
Table 25.4 — Supported earth geoids</p>
<table>
<tbody>
<tr>
<th>Code</th>
<th>Name</th>
</tr>
<tr>
<td><b>WGS84</b></td>
<td>WGS84 geoid</td>
</tr>
</tbody>
</table>
</div>
<h2><a name="ExplicitSRFDefinition"></a>25.2.4 Explicit SRF definition</h2>
<p>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
<a href="#SpecifyingAnExplicitlyDefinedSRF">25.2.6.3 Specifying an explicitly
defined SRF</a>. Any 3D SRF supported by <a href="../references.html#[I18026]">
ISO/IEC 18026</a> can be specified in this manner.</p>
<h2><a name="InternalSRFProcessing"></a>25.2.5 Internal SRF processing</h2>
<p>Internally, an X3D browser will transform all spatial coordinates into
ORM-fixed celestiocentric coordinates (<i>i.e.</i>, 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 <a href="#GeoOrigin">
GeoOrigin</a> node is supplied (see <a href="#high-precisioncoords">25.2.5
Dealing with high-precision coordinates</a>). 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.</p>
<h2><a name="Specifyingaspatialreference"></a>
25.2.6 Specifying a spatial reference frame</h2>
<h3><a name="SpecifyingASpatialReferenceFrameOverview"></a>25.2.6.1 Overview</h3>
<p>All the X3D nodes that allow inclusion of geographic coordinates
support a field called <i>geoSystem</i>. 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.</p>
<p>Spatial reference frames can be specified either by using the X3D predefined
SRFs or by referencing an explicitly defined SRF.</p>
<h3><a name="SpecifyingAPredefinedSRF"></a>25.2.6.2 Specifying a predefined SRF</h3>
<p>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. </p>
<ul>
<li>"<b>GD</b>" - 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 <a href="#t-earthellipsoids"> Table 25.3</a>. If no ellipsoid is specified, then "WE"
is assumed (<i>i.e.</i>, the WGS84 ellipsoid). An optional "WGS84"
string can be specified if you wish all elevations to relative
to the WGS84 geoid (<i>i.e.</i>, mean sea level) (see
<a href="#t-earthgeoids">Table 25.4</a>); 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.</li>
</ul>
<ul>
<li>"<b>UTM</b>" - 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 <a
href="#t-earthellipsoids">Table 25.3</a>. If no
ellipsoid is specified, then "WE" is assumed (<i>i.e.</i>, the
WGS84 ellipsoid). An optional "WGS84" string can be
specified if you wish all elevations to relative to the WGS84 geoid (<i>i.e.</i>, mean sea level (see <a
href="#t-earthgeoids">Table 25.4</a>)); 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.</li>
</ul>
<ul>
<li>"<b>GC</b>" - 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"].</li>
</ul>
<p>If no geoSystem field is specified, the default value specifies a predefined
SRF of ["GD", "WE"].</p>
<h3><a name="SpecifyingAnExplicitlyDefinedSRF"></a>25.2.6.3 Specifying an explicitly
defined SRF</h3>
<h4><a name="SpecifyingAnExplictlyDefinedSRFOverview"></a>25.2.6.3.1 Overview</h4>
<p>An explicitly defined SRF has all parameters specified in the SRF definition.
Thus, only one entry is needed in the <i>geoSystem</i> field. Such an entry
shall exactly specify a string that is identical to the <i>name</i> field of an
explicitly defined SRF.</p>
<p>There are three ways to specify an explicitly defined SRF:</p>
<ol>
<li type="a">SRF templates,</li>
<li type="a">SRF sets, and</li>
<li type="a">standardized SRFs</li>
</ol>
<p>Each will be summarized below. Full details of each method are in <a href="../references.html#[I18026]">
ISO/IEC 18026</a>.</p>
<p class="Example">NOTE It is possible to explicitly define all of the
predefined SRFs by using one of these methods.</p>
<h4><a name="SRFTemplates"></a>25.2.6.3.2 SRF templates</h4>
<p>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 <i>srfParametersInfo</i> 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 <a href="../references.html#[I18026]">
ISO/IEC 18026</a>. The template parameters are then coupled with the selection
of an ORM as specified by the <i>ormCode</i> field. </p>
<h4><a name="SRFSets"></a>25.2.6.3.3 SRF sets</h4>
<p>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 <i>srfParametersInfo</i> field contains a GeoSRFSet
node. The SRF set (specified by the <i>srfsCode</i> field) and member (specified
by the <i>srfsMember</i> field) are then coupled with an ORM as specified by the
<i>ormCode</i> field. A description of the available SRF sets and the members of
each set is in 8.7 of <a href="../references.html#[I18026]">
ISO/IEC 18026</a>.</p>
<h4><a name="StandardizedSRFs"></a>25.2.6.3.4 Standardized SRFs</h4>
<p>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 <i>
srfParametersInfo</i> field contains a GeoSRFInstance node. The SRF instance is
selected by specifying a code in the <i>srfCode</i> field. A description of each
fo the available standardized SRFs is available in 8.6 of <a href="../references.html#[I18026]">
ISO/IEC 18026</a>.</p>
<p class="Example">NOTE Standard SRFs also specify the ORM to be used.</p>
<h2><a name="SpecifyingSpatialCoordinates"></a>25.2.7 Specifying spatial coordinates</h2>
<p>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 <i>geoSystem</i> field in the same
node.</p>
<p>For X3D predefined SRFS with the following <i>geoSystem</i> definitions, the meaning of each
component is defined as follows. </p>
<ul>
<li><strong>GD</strong>: (<latitude>, <longitude>,
<elevation>) or (<longitude>, <latitude>,
<elevation>). The order of latitude and longitude is
controlled by the <i>geoSystem</i> 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 <i>geoSystem</i> field).<br>
<br>
<span class="example">EXAMPLE (37.4506,
−122.1834, 0) is the latitude/longitude coordinate for Menlo
Park, California, USA.</span> </li>
</ul>
<ul>
<li><strong>UTM</strong>: (<northing>, <easting>,
<elevation>) or (<easting>, <northing>,
<elevation>). The order of northing and easting is
controlled by the <i>geoSystem</i> 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 <i>geoSystem</i> field).<br>
<br>
<span class="example">EXAMPLE
(4145173, 572227, 0) is the zone 10 northern hemisphere UTM coordinate for
Menlo Park, California, USA.</span></li>
</ul>
<ul>
<li><b>GC</b>: (<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.<br>
<br>
<span class="example">EXAMPLE (−2700301, −4290762, 3857213) is the
geocentric coordinate for Menlo Park, California, USA.</span></li>
</ul>
<p>For explicitly defined SRFS, the components have the meanings specified in <a href="../references.html#[I18026]">
ISO/IEC 18026</a> for that type of SRF. There are three types of spatial
coordinates specified in <a href="../references.html#[I18026]">
ISO/IEC 18026</a>:</p>
<ol>
<li class="style1">3D,</li>
<li class="style1">surface, and</li>
<li class="style1">2D</li>
</ol>
<p>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. </p>
<p class="Example">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.</p>
<h2><a name="high-precisioncoords"></a>
25.2.8 Dealing with high-precision coordinates</h2>
<p>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.</p>
<p>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<sup>23</sup>-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.</p>
<p>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 <i>geoOrigin</i> field of the
geospatial X3D nodes.</p>
<p class="Example">EXAMPLE Consider a case where the <a href="#GeoOrigin">GeoOrigin</a>
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.</p>
<h2><a name="navigationissues"></a>
25.2.9 Geospatial navigation issues</h2>
<p>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.</p>
<p>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 <a href="#GeoViewpoint">GeoViewpoint</a> node.</p>
<h1><img class="cube" src="../../Images/cube.gif" alt="cube" width="20" height="19">
<a name="AbstactTypes"></a>25.3 Abstract types</h1>
<h2><a name="X3DSRFParametersInfoNode"></a>25.3.1 <i>X3DGeoSRFParametersInfoNode</i></h2>
<pre class="node">X3DSRFParametersInfoNode : X3DNode {
SFNode [in,out] metadata NULL [X3DMetadataObject]
SFInt32 [] rtCode 0 [see 11.2.7.6 of <a href="../references.html#[I18026]">ISO/IEC 18026</a>]
}
</pre>
<p>The <i>X3DSRFParametersInfoNode</i> abstract node type is the base type
for the specifications of SRF definitions.</p>
<p>The <i>rtCode</i> field identifies a reference transformation for the SRF.
Valid <i>rtCode</i> field values are specified in 11.2.7.6 of
<a href="../references.html#[I18026]">ISO/IEC 18026</a>.</p>
<h2><a name="X3DSRFParametersNode"></a>25.3.2 <i>X3DGeoSRFParametersNode</i></h2>
<pre class="node">X3DSRFParametersNode : X3DNode {
SFNode [in,out] metadata NULL [X3DMetadataObject]
}
</pre>
<p>The <i>X3DGeoSRFParametersNode</i> 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
<a href="../references.html#[I18026]">ISO/IEC 18026</a>:</p>
<ol class="style1">
<li>SRF template</li>
<li>SRF instances</li>
<li>SRF sets</li>
</ol>
<p>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
<a href="../references.html#[I18026]">ISO/IEC 18026</a>.</p>
<p>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
<a href="../references.html#[I18026]">ISO/IEC 18026</a> from which the
appropriate selection can be made.</p>
<p class="Example">EXAMPLE 1 British National Grid</p>
<p>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.</p>
<p class="Example">EXAMPLE 2 The set of Universal Transverse Mercator
(UTM) SRFs in which members are selected by specifying one of sixty zones.</p>
<h2><a name="X3DSRFTParametersNode"></a>25.3.3 <i>X3DGeoSRFTParametersNode</i></h2>
<pre class="node">X3DSRFTParametersNode : X3DNode {
SFNode [in,out] metadata NULL [X3DMetadataObject]
}
</pre>
<p>The <i>X3DSRFTParametersNode</i> 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
<a href="../references.html#[I18026]">ISO/IEC 18026</a>.</p>
<h1><img class="cube" src="../../Images/cube.gif" alt="cube" width="20" height="19">
<a name="Nodereference"></a>
25.4 Node reference</h1>
<h2><a name="GeoCoordinate"></a>
25.4.1 GeoCoordinate</h2>
<pre class="node">GeoCoordinate : X3DCoordinateNode {
SFNode [in,out] metadata NULL [X3DMetadataObject]
MFVec3d [in,out] point []
SFNode [] geoOrigin NULL [GeoOrigin]
MFString [] geoSystem ["GD","WE"] [see <a href="#ExplicitSRFDefinition">25.2.3</a>]
}
</pre>
<p>The GeoCoordinate node specifies a list of
coordinates in a spatial reference frame. It is used in the
<i>coord</i> field of vertex-based geometry nodes including
<a href="geometry3D.html#IndexedFaceSet">IndexedFaceSet</a>,
<a href="rendering.html#IndexedLineSet">IndexedLineSet</a>, and
<a href="rendering.html#PointSet">PointSet</a>.</p>
<p>The <i>geoOrigin</i> field is used to specify a
local coordinate frame for extended precision as described in <a
href="#high-precisioncoords">25.2.5
Dealing with high-precision coordinates</a>.</p>
<p>The <i>geoSystem</i> field is used to define the
spatial reference frame and is described in
<a
href="#ExplicitSRFDefinition">25.2.3
Specifying a spatial reference frame</a>.</p>
<p>The <i>point</i> array is used to contain the
actual geospatial coordinates and should be provided in a format
consistent with that specified for the particular <i>
geoSystem</i> (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.</p>
<h2><a name="GeoECParameters"></a>25.4.2 GeoECParameters</h2>
<pre class="node">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"]
}
</pre>
<p>A GeoECParameters node specifies the parameters required to define a
Equidistant Cylindrical (EC) SRF (see 11.2.9.2.1 in <a href="../references.html#[I18026]">ISO/IEC
18026</a>. EC SRFs are fully described in 8.5.24 of
<a href="../references.html#[I18026]">ISO/IEC 18026</a>.</p>
<h2><a name="GeoElevationGrid"></a>
25.4.3 GeoElevationGrid</h2>
<pre class="node">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 <a href="#ExplicitSRFDefinition">25.2.3</a>]
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,∞)
}
</pre>
<p>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.</p>
<p>The fields <i>color</i>, <i>colorPerVertex</i>,
<i>texCoord</i>, <i>normal</i>, and <i>normalPerVertex</i> all
have the same meaning as for <a href="geometry3D.html#ElevationGrid">ElevationGrid</a>
(see <a href="geometry3D.html#ElevationGrid">13.3.4 ElevationGrid</a>).</p>
<p>The <i>ccw</i>, <i>solid</i>, and
<i>creaseAngle</i> fields are described in
<a href="rendering.html#Commongeometryfields">11.2.3 Common geometry fields</a>.</p>
<p>The <i>geoOrigin</i> field is used to specify a
local coordinate frame for extended precision as described in <a
href="#high-precisioncoords">25.2.5
Dealing with high-precision coordinates</a>.</p>
<p>The <i>geoSystem</i> field is used to define the
spatial reference frame and is described in
<a
href="#ExplicitSRFDefinition">25.2.3
Specifying a spatial reference frame</a>.</p>
<p>The <i>geoGridOrigin</i> field specifies the
geographic coordinate for the south-west corner (bottom-left) of
the dataset. This value should be specified as described in
<a
href="#SpecifyingSpatialCoordinates">25.2.4
Specifying geospatial coordinates</a>. </p>
<p>The <i>height</i> array contains <i>xDimension</i> × <i>zDimension</i> 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 <i>geoSystem</i> is <span class="code">"GD"</span>,
<i>xSpacing</i> refers to the number of degrees of longitude
between adjacent height values and
<i>zSpacing</i> refers to the number of degrees of latitude
between vertical height values. When the geoSystem is <span class="code">"UTM"</span>,
<i>xSpacing</i> refers to the number of eastings (metres)
between adjacent height values and <i>zSpacing</i> refers to the
number of northings (metres) between vertical height values.</p>
<p class="Example">EXAMPLE If xDimension = <i>n</i> and the grid spans
<i>d</i> units horizontally, the xSpacing value should be set
to:</p>
<blockquote>
<p class="Example"><i>d</i> / (<i>n</i>−1).</p>
</blockquote>
<p>The <i>yScale</i> 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.</p>
<h2><a name="GeoLCCParameters"></a>25.4.4 GeoLCCParameters</h2>
<pre class="node">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 (-∞,∞)
}
</pre>
<p>A GeoLCCParameters node specifies the parameters required to define a
Lambert Conformal Conic (LCC) SRF (see 11.2.9.2.2 in <a href="../references.html#[I18026]">ISO/IEC
18026</a>. LCC SRFs are fully described in 8.5.22 of
<a href="../references.html#[I18026]">ISO/IEC 18026</a>.</p>
<h2><a name="GeoLCE3DParameters"></a>25.4.5 GeoLCE3DParameters</h2>
<pre class="node">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]
}
</pre>
<p>A GeoLCE3DParameters node specifies the parameters required to define a
Lococentric Euclidean 3D (LCE 3D) SRF (see 11.2.9.2.7 in <a href="../references.html#[I18026]">ISO/IEC
18026</a>. LCE 3D SRFs are fully described in 8.5.9 of
<a href="../references.html#[I18026]">ISO/IEC 18026</a>.</p>
<h2><a name="GeoLocalTangentParameters"></a>25.4.6 GeoLocalTangentParameters</h2>
<pre class="node">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 (-∞,∞)
}
</pre>
<p>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 <a href="../references.html#[I18026]">ISO/IEC
18026</a>. LTSAS SRFs are fully described in 8.5.7 of
<a href="../references.html#[I18026]">ISO/IEC 18026</a>. LTSC SRFs are fully
described in 8.5.8 of
<a href="../references.html#[I18026]">ISO/IEC 18026</a>.</p>
<h2><a name="GeoLocation"></a>
25.4.7 GeoLocation</h2>
<pre class="node">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 <a href="#ExplicitSRFDefinition">25.2.3</a>]
SFVec3f [] bboxCenter 0 0 0 (-∞,∞)
SFVec3f [] bboxSize -1 -1 -1 [0,∞) or −1 −1 −1
}
</pre>
<p>The GeoLocation node provides the ability to
geo-reference any standard X3D model. That is, to take an
ordinary X3D model, contained within the <i>children</i> 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.</p>
<p>The <i>geoOrigin</i> field is used to specify a
local coordinate frame for extended precision as described in <a
href="#high-precisioncoords">25.2.5
Dealing with high-precision coordinates</a>.</p>
<p>The <i>geoSystem</i> field is used to define the
spatial reference frame and is described in
<a
href="#ExplicitSRFDefinition">25.2.3
Specifying a spatial reference frame</a>.</p>
<p>The geometry of the nodes in <i>children</i> is to
be specified in units of metres in X3D coordinates relative to
the location specified by the <i>geoCoords</i> field. The
<i>geoCoords</i> field should be provided in the format
described in <a
href="#ExplicitSRFDefinition">25.2.3
Specifying a spatial reference frame</a>.</p>
<p>The <i>geoCoords</i> field can be used to
dynamically update the geospatial location of the model; for
example, an event could be sent from a <a
href="#GeoPositionInterpolator">GeoPositionInterpolator</a> node.</p>
<p>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.</p>
<h2><a name="GeoLOD"></a>
25.4.8 GeoLOD</h2>
<pre class="node">GeoLOD : X3DChildNode, X3DBoundedObject {
SFNode [in,out] metadata NULL [X3DMetadataObject]
MFNode [out] children [] [X3DChildNode]
SFInt32 [out] level_changed
SFVec3d [] center 0 0 0 (-∞,∞)
MFString [] child1Url [] [<i>urn</i>]
MFString [] child2Url [] [<i>urn</i>]
MFString [] child3Url [] [<i>urn</i>]
MFString [] child4Url [] [<i>urn</i>]
SFNode [] geoOrigin NULL [GeoOrigin]
MFString [] geoSystem ["GD","WE"] [see <a href="#ExplicitSRFDefinition">25.2.3</a>]
SFFloat [] range 10 [0,∞)
MFString [] rootUrl [] [<i>urn</i>]
MFNode [] rootNode [] [X3DChildNode]
SFVec3f [] bboxCenter 0 0 0 (-∞,∞)
SFVec3f [] bboxSize -1 -1 -1 [0,∞) or −1 −1 −1
}
</pre>
<p>The GeoLOD node provides a terrain-specialized
form of the <a href="navigation.html#LOD">LOD</a> 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.</p>
<p>The level of detail is switched depending upon
whether the user is closer or further than <i>range</i> metres
from the geospatial coordinate <i>center</i>. The
<i>center</i> field should be specified as described in
<a
href="#SpecifyingSpatialCoordinates">25.2.4
Specifying geospatial coordinates</a>.</p>
<p>The <i>geoOrigin</i> field is used to specify a
local coordinate frame for extended precision as described in <a
href="#high-precisioncoords">25.2.5
Dealing with high-precision coordinates</a>.</p>
<p>The <i>geoSystem</i> field is used to define the
spatial reference frame and is described in
<a
href="#ExplicitSRFDefinition">25.2.3
Specifying a spatial reference frame</a>.</p>
<p>When the user is outside the specified range, only
the geometry for <i>rootUrl</i> or <i>rootNode</i> are
displayed. When the viewer enters the specified range, this
geometry is replaced with the contents of the four children
files defined by <i>child1Url</i> through <i>child4Url</i>. 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.
<a href="#f-LoadingGeoLODlevels">Figure 25.1</a> illustrates this process.
The child URLs shall be arranged in the same order as in the figure; <i>i.e.</i>,
<i>child1Url</i> 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.</p>
<div class="CenterDiv">
<a name="f-LoadingGeoLODlevels"></a>
<img src="../../Images/geolod.gif" alt="GeoLOD Figure" width="381" height="192">
<p class="FigureCaption">
Figure 25.1 — Loading of GeoLOD levels</p>
</div>
<p>The <i>rootUrl</i> and <i>rootNode</i> fields
provide two different ways to specify the geometry of the root
tile. You may use one or the other. The <i>rootNode</i> field
lets you include the geometry for the root tile directly within
the X3D file; whereas the <i>rootUrl</i> 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.</p>
<p>The <i>children</i> 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 <i>rootNode</i> field or the nodes specified by the <i>child1Url</i>, <i>
child2Url</i>, <i>child3Url</i>, and <i>child4Url</i> fields. The GeoLOD node
shall generate a new <i>children</i> output event each time the scene graph is
changed (<span class="example">EXAMPLE whenever nodes are loaded or unloaded</span>). When the new children
event is generated, the GeoLOD node shall also generate a <i>level_changed</i>
event with value
<span class="code">0</span> or <span class="code">1</span> indicating the value
of the <i>whichChoice</i> field of the <a href="group.html#Switch">Switch</a> node.</p>
<p>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.</p>
<h2><a name="GeoLSR3DParameters"></a>25.4.9 GeoLSR3DParameters</h2>
<pre class="node">GeoLSR3DParameters : X3DGeoSRFTParametersNode {
SFString [in,out] description ""
SFNode [in,out] metadata NULL [X3DMetadataObject]
SFInt32 [] forwardDirection 2 [see 11.2.6.2 of <a href="../references.html#[I18026]">ISO/IEC 18026</a>]
SFInt32 [] up_direction 1 [see 11.2.6.2 of <a href="../references.html#[I18026]">ISO/IEC 18026</a>]
}
</pre>
<p>A GeoLSR3DParameters node specifies the parameters required to define a
Local Space Rectangular (LSR) 3D SRF (see 11.2.9.2.4 in <a href="../references.html#[I18026]">ISO/IEC
18026</a>. LSR 3D SRFs are fully described in 8.5.3 of
<a href="../references.html#[I18026]">ISO/IEC 18026</a>. All X3D non-spatial
coordinate systems are LSR 3D coordinate systems.</p>
<p>The <i>forwardDirection</i> 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.</p>
<p>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.</p>
<h2><a name="GeoLTSEParameters"></a>25.4.10 GeoLTSEParameters</h2>
<pre class="node">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 (-∞,∞)
}
</pre>
<p>A GeoLTSEParameters node specifies the parameters required to define a
Local Tangent Space Euclidean (LTSE) SRF (see 11.2.9.2.6 in <a href="../references.html#[I18026]">ISO/IEC
18026</a>. LTSE SRFs are fully described in 8.5.6 of
<a href="../references.html#[I18026]">ISO/IEC 18026</a>.</p>
<h2><a name="GeoMetadata"></a>
25.4.11 GeoMetadata</h2>
<pre class="node">GeoMetadata : X3DInfoNode {
MFNode [in,out] data [] [<i>urn</i>]
SFNode [in,out] metadata NULL [X3DMetadataObject]
MFString [in,out] summary []
MFString [in,out] url [] [<i>urn</i>]
}
</pre>
<p>The GeoMetadata node supports the specification of metadata describing
any number of geospatial nodes. This is similar
to a <a href="core.html#WorldInfo">WorldInfo</a> node, but specifically for describing geospatial
information.</p>
<p> 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 <i>metadata</i> field available
in each node.</p>
<p>The <i>url</i> 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.</p>
<p>The <i>summary</i> string array contains a set of
keyword/value pairs, with each keyword and its subsequent value
contained in a separate string; <i>i.e.</i>, 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. <a
href="#t-keywordsandvalues">Table 25.5</a> 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.</p>
<p class="TableCaption" align="center">
<a name="t-keywordsandvalues"></a>
Table 25.5 — GeoMetadata keywords and values</p>
<div class="CenterDiv">
<p>
<table>
<tbody>
<tr>
<th>Keyword</th>
<th>Value</th>
</tr>
<tr>
<td>title</td>
<td>A name to succinctly identify the dataset to user. For example,
"San Francisco, CA".</td>
</tr>
<tr>
<td>description</td>
<td>A brief textual description or summary of the content of the dataset.
For example, "LANDSAT 7 satellite imagery taken over northern
Scotland".</td>
</tr>
<tr>
<td>coordinateSystem</td>
<td>The spatial reference frame used to represent the data (<i>e.g.</i>, GD, UTM, or LCC). The list of valid codes that can be used in this
field are defined in <a href="../references.html#[I18026]">
2.[I18026]</a>.
In the case of UTM, the zone number should also be specified in the
format "UTM Z<i>x</i>", where the zone number is in the
range [1,60]. For example, "UTM Z11".</td>
</tr>
<tr>
<td>horizontalDatum</td>
<td>The name of the geodetic datum. The list of valid codes that can
be used in this field are defined in
<a href="../references.html#[I18026]">2.[I18026]</a>.
For example, "W84".</td>
</tr>
<tr>
<td>verticalDatum</td>
<td>The name of the vertical datum (geoid). The list of valid codes
that can be used in this field are defined in
<a href="../references.html#[I18026]">2.[I18026]</a>.
For example, "W84".</td>
</tr>
<tr>
<td>ellipsoid</td>
<td>The name of the geodetic ellipsoid. The list of valid codes that
can be used in this field are defined in
<a href="../references.html#[I18026]">2.[I18026]</a>.
For example, "WE".</td>
</tr>
<tr>
<td>extent</td>
<td>The bounding coordinates for the dataset given in spatial reference frame
specified by the <i>coordinateSystem</i> keyword. These are provided
in the order eastmost, southmost, westmost, northmost. An example
for GD is: "-180.0 -90.0 180.0 90.0".</td>
</tr>
<tr>
<td>resolution</td>
<td>The resolution, or ground sample distance, given in units of metres.
For example, "30".</td>
</tr>
<tr>
<td>originator</td>
<td>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"</td>
</tr>
<tr>
<td>copyright</td>
<td>Any appropriate copyright declaration that pertains to the data.
For example, "(c) Copyright 2000, Any Corporation. All rights
reserved. Freely distributable."</td>
</tr>
<tr>
<td>date</td>
<td>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 (<span class="code">EXAMPLE</span> "1999" or "2001").
Years can have other than four digits and can be negative. A date range
is specified by supplying two values separated by a "-"
(hyphen) 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".</td>
</tr>
<tr>
<td>metadataFormat</td>
<td>A string that specifies the format of the external metadata description
specified by the <i>url</i> field of the GeoMetadata node. For example,
"FGDC", "ISO TC211", "CEN TC287", or
"OGS".</td>
</tr>
<tr>
<td>dataUrl</td>
<td>A hypertext link to the source data used to create the X3D node(s)
to which this metadata pertains. Multiple <i>dataUrl</i> 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".</td>
</tr>
<tr>
<td>dataFormat</td>
<td>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 <i>dataUrl</i> keyword
(if present). For example, "USGS 5.5-min DEM".</td>
</tr>
</tbody>
</table>
</div>
<p>The <i>data</i> 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
<a href="#GeoElevationGrid">GeoElevationGrid</a>
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.
<h2><a name="GeoMParameters"></a>25.4.12 GeoMParameters</h2>
<pre class="node">GeoMParameters : X3DGeoSRFTParametersNode {
SFString [in,out] description ""
SFNode [in,out] metadata NULL [X3DMetadataObject]
SFDouble [] centralScale 0 (-∞,∞)
SFDouble [] falseEasting 0 (-∞,∞)
SFDouble [] falseNorthing 0 (-∞,∞)
SFDouble [] originLongitude 0 (-∞,∞)
}
</pre>
<p>A GeoMParameters node specifies the parameters required to define a
Mercator SRF (see 11.2.9.2.8 in <a href="../references.html#[I18026]">ISO/IEC
18026</a>. Mercator SRFs are fully described in 8.5.19 of
<a href="../references.html#[I18026]">ISO/IEC 18026</a>.</p>
<h2><a name="GeoObliqueMercatorParameters"></a>25.4.13 GeoObliqueMercatorParameters</h2>
<pre class="node">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 (-∞,∞)
}
</pre>
<p>A GeoObliqueMercatorParameters node specifies the parameters required to define an
Oblique Mercator Spherical SRF (see 11.2.9.2.9 in <a href="../references.html#[I18026]">ISO/IEC
18026</a>. Oblique Mercator Spherical SRFs are fully described in 8.5.20 of
<a href="../references.html#[I18026]">ISO/IEC 18026</a>.</p>
<h2><a name="GeoOrigin"></a>
25.4.14 GeoOrigin</h2>
<pre class="node">GeoOrigin : X3DNode {
SFVec3d [in,out] geoCoords 0 0 0 (-∞,∞)
SFNode [in,out] metadata NULL [X3DMetadataObject]
MFString [] geoSystem ["GD","WE"] [see <a href="#ExplicitSRFDefinition">25.2.3</a>]
SFBool [] rotateYUp FALSE
}
</pre>
<p>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.</p>
<p>The <i>geoCoords</i> field is used to specify a
local coordinate frame for extended precision as described in <a
href="#high-precisioncoords">25.2.5
Dealing with high-precision coordinates</a>.</p>
<p>The <i>geoSystem</i> field is used to define the
spatial reference frame and is described in
<a
href="#ExplicitSRFDefinition">25.2.3
Specifying a spatial reference frame</a>.</p>
<p>The <i>rotateYUp</i> 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 "<span class="code">FLY</span>" and
"<span class="code">WALK</span>",
which assume that +Y = up, will function correctly. Specifying <i>rotateYUp</i> to be <span class="code">TRUE</span> may incur an extra computational overhead
in order to perform the rotation for each point.</p>
<h2><a name="GeoPositionInterpolator"></a>
25.4.15 GeoPositionInterpolator</h2>
<pre class="node">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 <a href="#ExplicitSRFDefinition">25.2.3</a>]
}
</pre>
<p>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.</p>
<p>The <i>geoOrigin</i> field is used to specify a
local coordinate frame for extended precision as described in <a
href="#high-precisioncoords">25.2.5
Dealing with high-precision coordinates</a>.</p>
<p>The <i>geoSystem</i> field is used to define the
spatial reference frame and is described in
<a
href="#ExplicitSRFDefinition">25.2.3
Specifying a spatial reference frame</a>.</p>
<p> The fields <i>key</i>, <i>set_fraction</i>, and
<i>value_changed</i> have the same meaning as in the
PositionInterpolator node.</p>
<p>The <i>keyValue</i> array is used to contain the
actual coordinates and should be provided in a format consistent
with that specified for the particular <i>geoSystem</i>.</p>
<p>The <i>geovalue_changed</i> field outputs the the
interpolated coordinate in the spatial reference frame specified
by <i>geoSystem</i>. This can be passed to other X3D Geospatial component nodes
that support a field of this form (<i>e.g.</i>, <a href="#GeoViewpoint">GeoViewpoint</a> and
<a href="#GeoLocation">GeoLocation</a>).</p>
<h2><a name="GeoProximitySensor"></a>25.4.16 GeoProximitySensor</h2>
<pre class="node">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 <a href="#ExplicitSRFDefinition">25.2.3</a>]
}</pre>
<p align="left">The GeoProximitySensor node generates events when the viewer
enters, exits, and moves within a region in space (defined by a box).<br>
<br>
A GeoProximitySensor node generates <i>isActive</i> events as the viewer enters
and exits the rectangular box defined by its <i>geoCenter</i> and <i>size</i>
fields. This box is oriented tangent to the ellipsoid in a local coordinate
system.<br>
<br>
The fields <i>geoSystem</i> and <i>geoOrigin</i> are described in
<a href="#ExplicitSRFDefinition">25.2.3 Specifying a spatial reference
frame</a> and <a href="#high-precisioncoords">25.2.5 Dealing with high-precision
coordinates</a>, respectively.<br>
<br>
The <i>geoCoord_changed</i> generates an event that returns the geospatial
coordinates of the viewer's position in the spatial reference frame specified by
<i>geoSystem</i> for the viewer's position whenever a <i>position_changed</i>
event is generated. The <i>geoCoord_changed</i> value corresponds to the world
position returned by <i>position_changed</i>.</p>
<p align="left">The remaining fields are defined in
<a href="envsensor.html#ProximitySensor">22.4.1 ProximitySensor</a>.</p>
<h2><a name="GeoPSParameters"></a>25.4.17 GeoPSParameters</h2>
<pre class="node">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"]
}
</pre>
<p>A GeoPSParameters node specifies the parameters required to define a
Polar Stereographic (PS) SRF (see 11.2.9.2.10 in <a href="../references.html#[I18026]">ISO/IEC
18026</a>. PS SRFs are fully described in 8.5.23 of
<a href="../references.html#[I18026]">ISO/IEC 18026</a>.</p>
<h2><a name="GeoReferenceSurfaceInfo"></a>25.4.18 GeoReferenceSurfaceInfo</h2>
<pre class="node">GeoReferenceSurfaceInfo : X3DNode {
SFString [in,out] description ""
SFNode [in,out] metadata NULL [X3DMetadataObject]
SFInt32 [] dssCode 0 [see 11.2.7.3 of <a href="../references.html#[I18026]">ISO/IEC 18026</a>]
SFString [] name ""
SFNode [] srfParametersInfo NULL [X3DSRFParametersInfoNode]
}
</pre>
<p>A GeoReferenceSurfaceInfo node specifies parameters for the SRF in the <i>
srfParametersInfo</i> field and associates those parameters with a
designated spatial surface (DSS) (see 11.2.7.3 in <a href="../references.html#[I18026]">ISO/IEC
18026</a>) specified by the <i>dssCode</i> field. Designated spatial
surfaces are fully described in Clause 9 of
<a href="../references.html#[I18026]">ISO/IEC 18026</a>.</p>
<p>The <i>name</i> 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 <a href="#PredefinedSRFs">25.2.3 Predefined SRFs</a>.</p>
<h2><a name="GeoSRFInstance"></a>25.4.19 GeoSRFInstance</h2>
<pre class="node">GeoSRFInstance : X3DGeoSRFParametersNode {
SFString [in,out] description ""
SFNode [in,out] metadata NULL [X3DMetadataObject]
SFInt32 [] srfCode 0 [see 11.2.7.7 of <a href="../references.html#[I18026]">ISO/IEC 18026</a>]
}
</pre>
<p>A GeoSRFInstance node specifies a specific predefined SRF (see 11.9.3 in <a href="../references.html#[I18026]">ISO/IEC
18026</a>). SRF instances are fully described in 8.6 of
<a href="../references.html#[I18026]">ISO/IEC 18026</a>.</p>
<h2><a name="GeoSRFParametersInfo"></a>25.4.20 GeoSRFParametersInfo</h2>
<pre class="node">GeoSRFParametersInfo : X3DGeoSRFParametersInfoNode {
SFString [in,out] description ""
SFNode [in,out] metadata NULL [X3DMetadataObject]
SFInt32 [] rtCode 0 [See 11.2.7.6 of <a href="../references.html#[I18026]">ISO/IEC 18026</a>]
SFNode [] srfParametersInfo NULL [X3DGeoSRFParametersNode]
}
</pre>
<p>A GeoSRFParametersInfo node specifies the parameters of an arbitrary SRF.
All SRFs specified in
<a href="../references.html#[I18026]">ISO/IEC 18026</a> are supported. The
various forms of SRF required depend on the particular node that populates
the <em>srfParametersInfo</em> field.</p>
<h2><a name="GeoSRFSet"></a>25.4.21 GeoSRFSet</h2>
<pre class="node">GeoSRFSet : X3DGeoSRFParametersNode {
SFString [in,out] description ""
SFNode [in,out] metadata NULL [X3DMetadataObject]
SFInt32 [] ormCode 250 [see 11.2.7.4 of <a href="../references.html#[I18026]">ISO/IEC 18026</a>]
SFInt32 [] srfsCode 0 [see 11.2.7.8 of <a href="../references.html#[I18026]">ISO/IEC 18026</a>]
SFInt32 [] srfsMember 0 [see 11.2.9.2.11 of <a href="../references.html#[I18026]">ISO/IEC 18026</a>]
}
</pre>
<p>A GeoSRFSet node specifies the definition of an SRF based on an
SRF set (see 11.9.3 in <a href="../references.html#[I18026]">ISO/IEC
18026</a>. SRF sets are fully described in 8.7 of
<a href="../references.html#[I18026]">ISO/IEC 18026</a>.</p>
<p>SRF sets are a collection of related predefined SRFs. The <i>srfsCode</i>
field selects among the available SRF sets.</p>
<p>The <i>srfsMember</i> field selects a specific SRF within the SRF set
specified by the <i>srfsCode</i> field. The number of available members is part
of the definition of the SRF set.</p>
<p>The default values specify an unspecified set associated with the WGS_1984
Earth geoid ORM.</p>
<h2><a name="GeoSRFTemplate"></a>25.4.22 GeoSRFTemplate</h2>
<pre class="node">GeoSRFTemplate : X3DGeoSRFParametersNode {
SFString [in,out] description ""
SFNode [in,out] metadata NULL [X3DMetadataObject]
SFInt32 [] ormCode 250 [see 11.2.7.4 of <a href="../references.html#[I18026]">ISO/IEC 18026</a>]
SFInt32 [] srftCode 1 [see 11.2.7.10 of <a href="../references.html#[I18026]">ISO/IEC 18026</a>]
SFNode [] srftParameters NULL [X3DSRFTParametersNode]
}
</pre>
<p>A GeoSRFTemplate node specifies the definition of an SRF based on an
SRF template (see 11.9.2 in <a href="../references.html#[I18026]">ISO/IEC
18026</a>. SRF templates are fully described in 8.5 of
<a href="../references.html#[I18026]">ISO/IEC 18026</a>.</p>
<p>The <i>ormCode</i> field identifies an object reference model (ORM) that
forms the basis for the SRF. Valid <i>ormCode</i> field values are specified in
11.2.7.4 of <a href="../references.html#[I18026]">ISO/IEC 18026</a>.</p>
<p>The <i>srftCode</i> field identifies the type of SRF being defined. Valid
values for the srftCode field are specified in 11.2.7.10 of
<a href="../references.html#[I18026]">ISO/IEC 18026</a>. The <i>srftCode</i>
value determines the node to use as the value of the <i>srfParameters</i> field,
if any. Some <i>srftCode</i> values do not require additional parameters.</p>
<p>The default values specify a Celestiocentric SRF for the WGS_1984 Earth geoid
ORM.</p>
<h2><a name="GeoTMParameters"></a>25.4.23 GeoTMParameters</h2>
<pre class="node">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 (-∞,∞)
}
</pre>
<p>A GeoTMParameters node specifies the parameters required to define a
Transverse Mercator SRF (see 11.2.9.2.12 in <a href="../references.html#[I18026]">ISO/IEC
18026</a>. Mercator SRFs are fully described in 8.5.21 of
<a href="../references.html#[I18026]">ISO/IEC 18026</a>.</p>
<h2><a name="GeoTouchSensor"></a>
25.4.24 GeoTouchSensor</h2>
<pre class="node">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 <a href="#ExplicitSRFDefinition">25.2.3</a>]
}
</pre>
<p>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
<a href="pointingsensor.html#TouchSensor">TouchSensor</a> but also provides the
ability to return the geographic coordinate under the pointing
device.</p>
<p>The <i>description</i> 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.</p>
<p>A GeoTouchSensor can be enabled or disabled by
sending an event of value <span class="code">TRUE</span> or
<span class="code">FALSE</span> to the <i>enabled</i>
field. A disabled GeoTouchSensor does not track user input or
send events.</p>
<p>The <i>geoOrigin</i> field is used to specify a
local coordinate frame for extended precision as described in <a
href="#high-precisioncoords">25.2.5
Dealing with high-precision coordinates</a>.</p>
<p>The <i>geoSystem</i> field is used to define the
spatial reference frame and is described in
<a
href="#ExplicitSRFDefinition">25.2.3
Specifying a spatial reference frame</a>.</p>
<p>The fields <i>hitNormal_changed</i>, <i>hitPoint_changed</i>,
<i>hitTexCoord_changed</i>, <i>isActive</i>, <i>isOver</i>, and
<i>touchTime</i> all have the same meaning as in the TouchSensor
node.</p>
<p>The <i>hitGeoCoord_changed</i> field is generated
while the pointing device is pointing towards the
GeoTouchSensor's geometry (<i>i.e.</i>, when <i>isOver</i> is <span class="code">TRUE</span>). 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 <i>hitGeoCoord_changed</i> field will be in the format
(<latitude> <longitude> <elevation>) (see
<a
href="#SpecifyingSpatialCoordinates">25.2.4
Specifying geospatial coordinates</a>).</p>
<h2><a name="GeoTransform"></a>25.4.25 GeoTransform</h2>
<pre class="node">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 <a href="../../../../../X3D/Amendment%202%20to%2019775-1/WD2/Part01/components/geodata.html#Specifyingaspatialreference">25.2.3</a>]
}</pre>
<p align="left">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 <i>
geoCenter</i> field.</p>
<p align="left">The <i>geoCenter</i> field specifies, in the spatial reference
frame specified by the <i>geoSystem</i> field, the location at which the local
coordinate system is centered.<br>
<br>
The fields <i>geoSystem</i> and <i>geoOrigin</i> are described in
<a href="../../../../../X3D/Amendment%202%20to%2019775-1/WD2/Part01/components/geodata.html#Specifyingaspatialreference">
25.2.3 Specifying a spatial reference frame</a> and
<a href="../../../../../X3D/Amendment%202%20to%2019775-1/WD2/Part01/components/geodata.html#high-precisioncoords">
25.2.5 Dealing with high-precision coordinates</a>, respectively.<br>
<br>
The remaining fields are defined in
<a href="../../../../../X3D/Amendment%202%20to%2019775-1/WD2/Part01/components/group.html#Transform">
10.4.4 Transform</a>.</p>
<h2>25.4.26 GeoViewpoint</h2>
<pre class="node">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 <a href="#ExplicitSRFDefinition">25.2.3</a>]
SFRotation [] orientation 0 0 1 0 (-∞,∞) or -1 1
SFVec3d [] position 0 0 100000 (-∞,∞)
SFFloat [] speedFactor 1.0 [0,∞)
}
</pre>
<p>The GeoViewpoint node allows the specification of
a viewpoint in terms of a geospatial coordinate. This node can
be used wherever a <a href="navigation.html#Viewpoint">Viewpoint</a> node can be used and can be
combined with Viewpoint nodes in the same scene.
The <i>fieldOfView</i>, <i>jump</i>, <i>description</i>, <i>set_bind</i>,
<i>bindTime</i>, and <i>isBound</i> 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.</p>
<p>The <i>geoOrigin</i> field is used to specify a
local coordinate frame for extended precision as described in <a
href="#high-precisioncoords">25.2.5
Dealing with high-precision coordinates</a>.</p>
<p>The <i>geoSystem</i> field is used to define the
spatial reference frame and is described in
<a
href="#ExplicitSRFDefinition">25.2.3
Specifying a spatial reference frame</a>.</p>
<p>The <i>position</i> 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 <i>
geoSystem</i>. There is also a <i>set_position</i> field which
can be routed from the <i>geovalue_changed</i> field of a <a
href="#GeoPositionInterpolator">GeoPositionInterpolator</a> node
in order to animate the position of the GeoViewpoint.</p>
<p>The <i>orientation</i> 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 <i>orientation</i> value of [ 1 0 0 -1.57 ] is
used. The <i>set_orientation</i> field can be routed to the
<i>value_changed</i> field of an
<a href="interp.html#OrientationInterpolator">OrientationInterpolator</a> in
order to animate the orientation of the GeoViewpoint.</p>
<p>The <i>navType</i> 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 <a href="navigation.html#NavigationInfo">NavigationInfo</a> node (<i>e.g.</i>,
<span class="code">"EXAMINE"</span>, <span class="code">"WALK"</span>,
<span class="code">"FLY"</span>, or
<span class="code">"ANY"</span>).</p>
<p>The <i>headlight</i> 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.</p>
<p>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 <i>speed</i>, <i>avatarSize</i>, and
<i>visibilityLimit</i> 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 <a
href="#navigationissues">25.2.6 Geospatial
Navigation Issues</a>). It is recommended that the speed of user
interaction be defined as:<br />
<blockquote>
<i>( elevation / 10.0 ) metres per second</i>
</blockquote>
<p>where <i>elevation</i> 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
<i>avatarSize</i> vector.</p>
<p>The <i>speedFactor</i> field of the GeoViewpoint
node is used as a multiplier to the elevation-based velocity
that the node sets internally; <i>i.e.</i>, this is a relative value
and not an absolute speed as is the case for the NavigationInfo
node.</p>
<h1><img class="cube" src="../../Images/cube.gif" alt="cube">
<a name="SupportLevels"></a>25.4 Support levels</h1>
<p>The Geospatial component provides one level of support as specified in
<a href="#t-supportlevels">Table 25.6</a>.</p>
<div class="CenterDiv">
<p class="TableCaption">
<a name="t-supportlevels"></a>
Table 25.6 — Geospatial component support levels</p>
<table>
<tr>
<th><b>Level</b></th>
<th>Prerequisites</th>
<th><b>Nodes/Features</b></th>
<th>Support</th>
</tr>
<tr>
<td>
<p align="center"><b>1</b></td>
<td>Core 1<br>
Time 1<br>
Networking 1<br>
Grouping 3<br>
Rendering 1<br>
Shape 1<br>
Geometry3D 1<br>
Interpolator 1<br>
Point device sensor 1<br>
Navigation 1
</td>
<td>
</td>
<td></td>
</tr>
<tr>
<td class="sl1"> </td>
<td> </td>
<td><em>X3DGeoSRFParametersInfoNode</em></td>
<td>n/a</td>
</tr>
<tr>
<td class="sl1"> </td>
<td> </td>
<td><em>X3DGeoSRFParametersNode</em> </td>
<td>n/a</td>
</tr>
<tr>
<td class="sl1"> </td>
<td> </td>
<td><em>X3DGeoSRFTParametersNode</em> </td>
<td>n/a</td>
</tr>
<tr>
<td class="sl1"> </td>
<td></td>
<td>GeoCoordinate</td>
<td>All fields fully supported except only pre-defined SRFs supported by <i>geoSystem </i>
field.</td>
</tr>
<tr>
<td class="sl1"> </td>
<td> </td>
<td>GeoElevationGrid</td>
<td>All fields fully supported except only pre-defined SRFs supported by <i>geoSystem </i>
field.</td>
</tr>
<tr>
<td class="sl1"> </td>
<td> </td>
<td>GeoLocation</td>
<td>All fields fully supported except only pre-defined SRFs supported by <i>geoSystem </i>
field.</td>
</tr>
<tr>
<td class="sl1"> </td>
<td> </td>
<td>GeoLOD</td>
<td>All fields fully supported except only pre-defined SRFs supported by <i>geoSystem </i>
field.</td>
</tr>
<tr>
<td class="sl1"> </td>
<td> </td>
<td>GeoMetadata</td>
<td>All fields fully supported.</td>
</tr>
<tr>
<td class="sl1"> </td>
<td> </td>
<td>GeoOrigin</td>
<td>All fields fully supported except only pre-defined SRFs supported by <i>geoSystem </i>
field.</td>
</tr>
<tr>
<td class="sl1"> </td>
<td> </td>
<td>GeoPositionInterpolator</td>
<td>All fields fully supported except only pre-defined SRFs supported by <i>geoSystem </i>
field.</td>
</tr>
<tr>
<td class="sl1"> </td>
<td> </td>
<td>GeoTouchSensor</td>
<td>All fields fully supported except only pre-defined SRFs supported by <i>geoSystem </i>
field except only pre-defined SRFs supported by <i>geoSystem </i>field.</td>
</tr>
<tr>
<td class="sl1"> </td>
<td> </td>
<td>GeoViewpoint</td>
<td>All fields fully supported except only pre-defined SRFs supported by <i>geoSystem </i>
field.</td>
</tr>
<tr>
<td><b> 2</b></td>
<td>Core 1<br>
Time 1<br>
Networking 1<br>
Grouping 3<br>
Rendering 1<br>
Shape 1<br>
Geometry3D 1<br>
Interpolator 1<br>
Environmental device sensor 1<br>
Navigation 1 </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td> </td>
<td> </td>
<td>All Level 1 Geospatial nodes</td>
<td>All fields fully supported except only pre-defined SRFs supported
by <i>geoSystem </i>field.</td>
</tr>
<tr>
<td> </td>
<td> </td>
<td>GeoProximitySensor</td>
<td>All fields fully supported except only pre-defined SRFs supported
by <i>geoSystem </i>field.</td>
</tr>
<tr>
<td> </td>
<td> </td>
<td>GeoTransform</td>
<td>All fields fully supported except only pre-defined SRFs supported
by <i>geoSystem </i>field.</td>
</tr>
<tr>
<td><b> </b><strong>3</strong></td>
<td>Core 1<br>
Time 1<br>
Networking 1<br>
Grouping 3<br>
Rendering 1<br>
Shape 1<br>
Geometry3D 1<br>
Interpolator 1<br>
Environmental device sensor 1<br>
Navigation 1 </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td> </td>
<td> </td>
<td>All Level 2 Geospatial nodes</td>
<td>All fields fully supported.</td>
</tr>
<tr>
<td> </td>
<td> </td>
<td>GeoECParameters</td>
<td>All fields fully supported.</td>
</tr>
<tr>
<td> </td>
<td> </td>
<td>GeoLCCParameters</td>
<td>All fields fully supported.</td>
</tr>
<tr>
<td> </td>
<td> </td>
<td>GeoLCE3DParameters</td>
<td>All fields fully supported.</td>
</tr>
<tr>
<td> </td>
<td> </td>
<td>GeoLocalTangentParameters</td>
<td>All fields fully supported.</td>
</tr>
<tr>
<td> </td>
<td> </td>
<td>GeoLSR3DParameters</td>
<td>All fields fully supported.</td>
</tr>
<tr>
<td> </td>
<td> </td>
<td>GeoLTSEParameters</td>
<td>All fields fully supported.</td>
</tr>
<tr>
<td> </td>
<td> </td>
<td>GeoMParameters</td>
<td>All fields fully supported.</td>
</tr>
<tr>
<td> </td>
<td> </td>
<td>GeoObliqueMercatorParameters</td>
<td>All fields fully supported.</td>
</tr>
<tr>
<td> </td>
<td> </td>
<td>GeoPSParameters</td>
<td>All fields fully supported.</td>
</tr>
<tr>
<td> </td>
<td> </td>
<td>GeoReferenceSurfaceInfo</td>
<td>All fields fully supported.</td>
</tr>
<tr>
<td> </td>
<td> </td>
<td>GeoSRFInstance</td>
<td>All fields fully supported.</td>
</tr>
<tr>
<td> </td>
<td> </td>
<td>GeoSRFParametersInfo</td>
<td>All fields fully supported.</td>
</tr>
<tr>
<td> </td>
<td> </td>
<td>GeoSRFSet</td>
<td>All fields fully supported.</td>
</tr>
<tr>
<td> </td>
<td> </td>
<td>GeoSRFTemplate</td>
<td>All fields fully supported.</td>
</tr>
<tr>
<td> </td>
<td> </td>
<td>GeoTMParameters</td>
<td>All fields fully supported.</td>
</tr>
</table>
</div>
<img class="x3dbar" src="../../Images/x3dbar.png" alt="--- X3D separator bar ---" width="430" height="23" />
</BODY>
</HTML>