ISO/IEC 18026:2009

5 Abstract coordinate systems
5.1 Introduction
An abstract coordinate system is a means of identifying positions in position-space by coordinate n-tuples. An
abstract coordinate system is completely defined in terms of the mathematical structure of position-space. In
this International Standard the term “coordinate system”, if not otherwise qualified, is defined to mean
“abstract coordinate system.” Each coordinate system has a coordinate system type (see 5.4). Other
coordinate system related concepts defined in this clause include coordinate-component surfaces and
coordinate-component curves (see 5.5), linearity and other properties (see 5.6), and localization (see 5.7).
Map projections and augmented map projections are defined and treated as special cases of the general
abstract coordinate system concept (see 5.8). Standardized abstract coordinate systems are specified in 5.9.
In Clause 6 a temporal coordinate system is defined as a means of identifying events in the time continuum by
coordinate 1-tuples using an abstract coordinate system of coordinate system type 1D. In Clause 8 a spatial
coordinate system is defined as an abstract coordinate system suitably combined with a normal embedding
(see Clause 7) as a means of identifying points in object-space by coordinate n-tuples.
5.2 Preliminaries
This International Standard takes a functional approach to the construction of coordinate systems. Annex A
provides a concise summary of mathematical concepts and specifies the notational conventions used in this
International Standard. In particular, Annex A defines the terms interior, one-to-one, smooth, smooth surface,
n
smooth curve, orientation-preserving, and connected. The concept of R as a vector space, the point-set
n n
topology of R , and the theory of real-valued functions on R are all assumed. Algebraic and analytic
geometry, including the concepts of point, line, and plane, are also assumed. Together with such common
concepts, a newly introduced concept replete will be used. A set D is replete if all points in D belong to the
closure of the interior of D (see Annex A). A replete set is a generalization of an open set that allows the
inclusion of boundary points. Boundary points are important in the definitions of certain coordinate systems.
5.3 Abstract CS
An abstract Coordinate System (CS) is a means of identifying a set of positions in an abstract Euclidean
space that shall be comprised of:
a) a CS domain,
b) a generating function, and
c) a CS range,
where:
a) The CS domain shall be a connected replete domain in the Euclidean space of n-tuples (1 ≤ n ≤ m),
called the coordinate-space.
b) The generating function shall be a one-to-one, smooth, orientation-preserving function from the CS
domain onto the CS range.
© ISO/IEC 2009 – All rights reserved
c) The CS range shall be a set of positions in a Euclidean space of dimension m (n ≤ m ≤ 3), called the
position-space. When n = 2 and m = 3, the CS range shall be a subset of a smooth surface . When
n = 1 and m = 2 or 3, the CS range shall be a subset of an implicitly specified smooth curve .
th
An element of the CS domain shall be called a coordinate . The k -component of a coordinate n-tuple
th
(1 ≤ k ≤ n) may be called the k coordinate-component. Coordinate-component is the collective term for any
th
k coordinate-component.
An element of the CS range shall be called a position. The coordinate of a position p shall be the unique
coordinate whose generating function value is p.
The generating function may be parameterized. The generating function parameters (if any) shall be called the
CS parameters.
The inverse of the generating function shall be called the inverse generating function. The inverse generating
function is one-to-one and is smooth and orientation-preserving in the interior of its domain, except at points in
the image of the CS domain boundary points where it may be discontinuous. A CS may equivalently be
defined by specifying the inverse generating function when the CS domain is an open set.
NOTE 1 The generating function of a CS is often specified by an algebraic and/or trigonometric description of a
geometric relationship (see 5.3 Example). There are also CSs that do not have geometric derivations. The Mercator map
projection (see Table 5.18) is specified to satisfy a functional requirement of conformality (see 5.8.3.2) rather than by a
geometric construction.
EXAMPLE  Polar CS: Considering the polar geometry depicted in Figure 5.1, define a generating function F as:
F(ρ, θ ) = (x, y)
where:
x = ρ cos(θ ), and y = ρ sin(θ ).
The CS domain of F in coordinate-space is {(ρ,θ ) in R | 0< ρ, 0≤θ < 2π}∪ {(0,0)} .
The CS range of F in position-space is R .
This generating function is illustrated in Figure 5.2. The grey boxes with lighter grey edges in this figure represent the fact
that the range in position-space extends indefinitely, and that the domain in coordinate-space extends indefinitely along
the ρ-axis. The dotted grey edges indicate an open boundary. This CS range, CS domain, and generating function define
an abstract CS representing polar coordinates as defined in mathematics [EDM, “Coordinates”]. The normative definition
of the polar CS may be found in Table 5.33.

The generating function properties and the implicit function theorem together imply that for each point in the interior of
the CS domain, there is an open neighbourhood of the point whose image under the generating function lies in a smooth
surface. This requirement specifies that there exists one smooth surface for all of the points in the CS domain. This
requirement is specified to exclude mathematically pathological cases.
The generating function properties and the implicit function theorem together imply that for each point in the interior of
the CS domain, there is an open neighbourhood of the point whose image under the generating function lies in a smooth
curve. This requirement specifies that there exists one implicitly-defined smooth curve for all the points in the CS domain.
This requirement is specified to exclude mathematically pathological cases.
The ISO 19111 term for this concept is “coordinate tuple”.
The ISO 19111 term for this concept is “coordinate”.
© ISO/IEC 2009 – All rights reserved
y-axis
ρ cosθ
ρ
x-axis
θ
Figure 5.1 — Polar CS geometry
y-axis
θ -axis
F
2π
p
y = ρ sin(θ )
(ρ, θ) x-axis
x = ρ cos(θ )
ρ -axis
coordinate-space
position-space
Figure 5.2 — The polar CS generating function
n
NOTE 2  In the special case where 1) the CS domain and CS range are both R and 2) the function is the identity
function, this approach to defining coordinate systems reduces to the usual definition of the Euclidean coordinate system
n
on R where each point is identified by an n-tuple of real numbers [EDM] (see Table 5.8, Table 5.29 and Table 5.35).
NOTE 3  The CS generating function has an inverse because it is one-to-one, but the inverse may be discontinuous at
points in the image of CS domain boundary points. This is the case for the positive x-axis in the example above.
5.4 CS types
The coordinate-space and position-space dimensions characterize an abstract CS by CS type as defined in
Table 5.1.
Table 5.1 — CS types
Dimension of Dimension of
CS type
coordinate-space position-space
3D 3 3
© ISO/IEC 2009 – All rights reserved
ρ sinθ
Dimension of Dimension of
CS type
coordinate-space position-space
surface 2 3
1 3
curve
2D 2 2
plane curve 1 2
1D 1 1
A CS of CS type 3D may be called a 3D CS, a CS of CS type surface may be called a surface CS, and a CS
of CS type 2D may be called a 2D CS.
5.5 Coordinate surfaces, induced surface CSs, and coordinate curves
5.5.1 Introduction
The generating function of a 3D CS is a function of the three coordinate-components of a coordinate 3-tuple. If
one of the coordinate-components is held fixed (to a constant value), then the generating function thus
restricted to two variables may be viewed as a surface CS generating function (with a surface CS range). If
two of the three coordinate-components are held fixed, the generating function restricted to one variable may
be viewed as a curve CS generating function (with curve CS range). These observations motivate the
definitions of coordinate-component surfaces and curves. The coordinate-component surface and coordinate-
component curve concepts are required to specify induced CS relationships, for the definition of special
coordinate curves parallel and meridian, and the definition of CS handedness (see also 10.5).
5.5.2 Coordinate-component surfaces and induced surface CSs
If F is the generating function of a 3D CS, and u = (u , v , w ) is in the interior of the CS domain D, then three
0 0 0
surface CS generating functions at u are defined by:
S (v,w)= F(u ,v,w) ,
1 0
S (u,w)= F(u,v ,w) , and
2 0
S (u,v)= F(u,v,w ) .
3 0
The CS domain for S is the connected component of (v,w) in R ( u ,v,w) in D which contains (v , w ).
1 { } 0 0
The CS domain for S is the connected component of (u,w) in R ( u,v ,w) in D which contains (u , w ).
2 { } 0 0
The CS domain for S is the connected component of (u,v) in R ( u,v,w ) in D which contains (u , v ).
3 { } 0 0
st nd rd
Each of these surface CSs shall be called, respectively, the 1 , 2 , and 3 surface CS induced by F at u.
st nd rd
The CS ranges of these surface CSs are, respectively, the 1 , 2 , and 3 coordinate-component surface at u.
EXAMPLE 1 Coordinate-component surface: The geodetic 3D CS with generating function F (λ,ϕ,h)= (x,y,z) is
rd
specified in Table 5.14 with CS parameters a and b. The 3 coordinate-component surface at u= λ ,ϕ ,0 is the surface
( )
0 0
of the oblate ellipsoid with major semi-axis a and minor semi-axis b.

The ISO 19111 concept of a linear reference system is a specialization of the curve CS and plane curve CS concepts.
© ISO/IEC 2009 – All rights reserved
EXAMPLE 2 Induced surface CS: The surface geodetic CS is specified in Table 5.24. Its CS domain, CS range and
rd
generating function are identical to the 3 surface CS induced by the geodetic 3D generating function at u = 0,0,0 . If h
( )
is replaced by 0 in the formulae for the generating and inverse generating functions of the geodetic 3D CS, they reduce to
the surface geodetic formulae.
5.5.3 Coordinate-component curves
Coordinate-component curves are defined for CSs of CS type 3D, CS type surface, and CS type 2D.
The CS type 3D case:
If F is the generating function of a CS of CS type 3D, D is the CS domain, and u = (u , v , w ) is in the interior
0 0 0
st nd rd
of D, then the 1 , 2 , and 3 coordinate-component curves at u are parametrically specified, respectively, by
the following smooth functions:
C u =F u,v ,w ,
( ) ( )
1 0 0
C v =F u ,v,w , and
( ) ( )
2 0 0
C w =F u ,v ,w .
( ) ( )
3 0 0
The domain for C is the connected component of u in R (u,v ,w ) in D which contains u .
1 { } 0
0 0
The domain for C is the connected component of v in R (u ,v,w ) in D which contains v .
2 { } 0
0 0
The domain for C is the connected component of w in R (u ,v ,w) in D which contains w .
3 { } 0
0 0
NOTE  The intersection of two coordinate surfaces at u is (the locus of) a coordinate-component curve:
C = S ∩S ,C = S ∩S ,C = S ∩S .
1 2 3 2 1 3 3 1 2
The CS type surface and CS type 2D cases:
If F is the generating function of a CS of CS type surface or CS type 2D, D is the CS domain, and u = (u , v )
0 0
st nd
is in the interior of D, then the 1 and 2 coordinate-component curves at u are parametrically specified,
respectively, by the following smooth functions:
C u =F u,v , and
( ) ( )
1 0
C v =F u ,v .
( ) ( )
2 0
The domain for C is the connected component of u in R (u,v ) in D which contains u .
{ }
1 0
The domain for C is the connected component of v in R (u ,v) in D which contains v .
{ }
2 0
EXAMPLE  If u = ( ρ ,θ ) is in the interior of the CS domain of the polar CS generating function F of the 5.3
0 0
nd
Example, then the first coordinate-component curve is C θ =F ρ ,θ = ρ cosθ, ρ sinθ , and the 2 coordinate-
( ) ( ) ( )
1 0 0 0
component curve is C θ =F ρ,θ = ρcosθ , ρsinθ .
( ) ( ) ( )
2 0 0 0
If F is the generating function for the geodetic 3D CS or the surface geodetic CS, and u= λ ,ϕ ,0 in the 3D
( )
0 0
case or u= λ ,ϕ in the surface case, then (see Figure 5.3):
( )
0 0
st
a) the 1 coordinate-component curve at u shall be called the parallel at u, and
© ISO/IEC 2009 – All rights reserved
nd
b) the 2 coordinate-component curve at u shall be called the meridian at u.
The meridian at u = (0,0,0) or (0,0) shall be called the prime meridian .
The parallel at u = (0,0,0) or (0,0) shall be called the equator.

z-axis
rd
3 coordinate surface
parallel at (λ,ϕ, 0)
h = 0
meridian at (λ,ϕ, 0)
b
(λ,ϕ, h)
h
prime
meridian
(λ,ϕ, 0)
a y
ϕ
y-axis
λ
z
x
equator
(0, 0, 0)
x-axis
Figure 5.3 — Geodetic 3D CS geometry, and coordinate-component surface and curves
5.6 CS properties
5.6.1 Linearity
A CS with generating function F is a linear CS if F is an affine function. The CS domain of a linear coordinate
n
system is all of the coordinate-space R .
A curvilinear CS is a non-linear CS.
EXAMPLE  The polar CS of 5.3 EXAMPLE is a curvilinear CS of CS type 2D.

ISO 19111 defines the term “meridian” as the intersection between an ellipsoid and a plane containing the semi-minor
axis of the ellipsoid.
ISO 19111 defines the term “prime meridian” as the meridian from which the longitudes of other meridians are
quantified. In Clause 7, most, but not all, oblate ellipsoid Earth object reference models associate the Greenwich meridian
with the prime meridian (see 7.4.5).
© ISO/IEC 2009 – All rights reserved
5.6.2 Orthogonality
A CS of CS type 3D, CS type surface, or CS type 2D is orthogonal if the angle between any two coordinate-
component curves at u is a right angle when u is any coordinate in the interior of the CS domain of the
generating function.
EXAMPLE  The polar CS of 5.3 EXAMPLE is a orthogonal CS of CS type 2D.
5.6.3 Linear CS properties: Cartesian, and orthonormal
th th
In a linear CS, the k coordinate-component curve is a line. The k coordinate-component curve at the origin 0
th
of a linear CS is the k -axis.
In a linear CS, if the angles between coordinate-component curves at the origin 0 are (pair-wise) right angles,
then that is the case at all points. In particular, a linear CS is orthogonal if the axes are orthogonal.
In some publications a Cartesian CS is defined the same way as an orthogonal linear CS . This International
Standard, however, defines this concept differently. A linear CS with generating function F is a Cartesian CS if
F e −F 0 = 1, i = 1,.,n (i.e., the axis unit points are all one unit distant from the origin F(0)).
( ) ( )
i
An orthonormal CS is a linear CS that is both orthogonal and Cartesian.
A CS of CS type 3D with generating function F is orientation-preserving if the Jacobian determinant of F is
positive.
EXAMPLE  The Lococentric Euclidean 3D CS specified in Table 5.9 is an orientation-preserving orthonormal CS.
5.6.4 CS right-handedness and coordinate-component ordering
Given a CS of CS type 3D and a coordinate c = u ,v ,w in the interior of the CS domain, the coordinate-
( )
0 0 0
component curves at p determine an ordered set of three tangent vectors:
dC 
t = ,
1  
du
 
u=u
dC
 
t = , and
2  
dv
 
v=v
dC
 
t = .
3  
dw
 
w=w
An orthogonal CS of CS type 3D is a right-handed CS if for some coordinate c in the interior of the CS
domain, the ordered set of tangent vectors t , t , and t form a right-handed coordinate system as defined in
1 2 3
IS0 80000-2. The right-handed CS property is determined, in part, by the order of the coordinate-components
in the coordinate 3-tuple. The order of the coordinate-components in the specification of an orthogonal CS of
CS type 3D shall be restricted to an ordering that ensures a right-handed CS. This restriction is required for
uniform treatment of directions in an SRF (see 10.5).

Some publications use “rectangular” to denote an orthogonal linear CS, and “oblique” to denote a non-orthogonal linear
CS.
ISO 19111 defines “Cartesian coordinate system” as a coordinate system that gives the position of points relative to n
mutually-perpendicular axes.
© ISO/IEC 2009 – All rights reserved
The coordinate-component ordering in the specification of a surface CS that is induced on a coordinate-
component surface of a 3D CS, shall use the coordinate-component order of the inducing 3D CS.
EXAMPLE 1 The geodetic 3D CS (Table 5.14) coordinate-component ordering λ,ϕ,h ensures that the CS is right-
( )
handed. A similar ordering for the planetodetic 3D CS (Table 5.15) is not right-handed because the tangent to planetodetic
longitude points opposite to the direction of the tangent to geodetic longitude. Instead, the coordinate-component ordering
ϕ,λ,h is specified to satisfy the right-handed CS requirement.
( )
EXAMPLE 2 The surface planetodetic geodetic CS (Table 5.25) coordinate-component ordering ϕ,λ is determined
( )
by the coordinate-component ordering ϕ,λ,h of the planetodetic 3D CS (Table 5.15).
( )
5.7 CS localization
In some applications of a CS in the context of a spatial reference frame, it is necessary to consider a modified
version of the CS that has been translated to a local origin and/or has been rotated (see "Lococentric" spatial
reference frame variants in Clause 8). To treat these modifications in a uniform manner, the generating
function of a CS that has been translated to a local origin and/or has been rotated is related to the generating
function of the original CS by means of a localization operator. This uniform method, defined below, of
specifying the variant CS by composing the original CS generating function with a localization operator shall
be called CS localization.
Three parameterized operators, called localization operators, that operate on or between position-spaces are
defined in Table 5.2. The inverses of these operators are defined in Table 5.3.
Table 5.2 — Localization operators
Localization
Domain Range Localization parameters Operator definition
operator
3 3 3
L
R R q, r, s, in R
L x,y,z = q+ xr + ys+ zt,
3D ( )
3D
r and s are orthonormal
where t = r×s.
2 3 3
L
R R q, r, s, in R L x,y = q+ xr+ ys
( )
Surface Surface
r and s are orthonormal
2 2 2
L
R R q, r, s, in R L x,y = q+ xr+ ys
( )
2D
2D
r and s are orthonormal
Table 5.3 — Localization inverse operators
Localization operator Inverse operator definition
−1
L
L p = p-q •r e + p-q •s e + p-q •t e
3D ( ) (( ) ) (( ) ) (( ) )
3D 1 2 3
−1
L
L p = p-q •r e + p-q •s e
Surface ( ) (( ) ) (( ) )
Surface 1 2
−1
L
L p = p-q •r e + p-q •s e
2D ( ) (( ) ) (( ) )
2D 1 2
There are several forms of CS localization depending on CS type and localization operator. A 3D or surface
CS with generating function F is localized by composing F with the L localization operator. The localized CS
3D
© ISO/IEC 2009 – All rights reserved
is of the same CS type (CS type 3D or CS type surface, respectively). Its generating function is F ≡ L
F
L 3D
and has the same CS domain as F.
There are two localization operators for a 2D CS. One uses localization parameters in R and produces a
surface CS. The other uses localization parameters in R and produces a 2D CS.
a) A 2D CS with generating function F is localized by composing F with the L localization operator.
Surface
The localized CS is a surface CS. Its generating function is F ≡ L
F and has the same CS
L Surface
domain as F.
b) A 2D CS with generating function F is localized by composing F with the L localization operator.
2D
The localized CS is a 2D CS. Its generating function is F ≡ L
F and has the same CS domain as
L 2D
F.
The localization operator parameter q shall be called the lococentre. A localized CS may be called a
lococentric CS.
NOTE  CS localization preserves the following CS properties: linear/curvilinear, orthogonal, Cartesian, and
orthonormal.
The relationship between a CS type and its localized version(s) is summarized in Table 5.4.
Table 5.4 — Localized CS type relationships
CS type Localization operator Lococentric CS type
L
3D 3D
3D
L
Surface
3D
Surface
L
Surface
2D
L
2D
2D
5.8 Map projection coordinate systems
5.8.1 Map projections
Map projections are 2D models of a 3D curved surface. In this International Standard, map projections are
limited to the surface of an oblate ellipsoid. A map projection (MP) is comprised of
a) an MP domain in the surface of an oblate ellipsoid,
b) a generating projection, and
c) an MP range in 2D coordinate-space,
where:
a) the MP domain is a connected subset of the surface of the oblate ellipsoid,
b) the MP range is a connected replete set, and
© ISO/IEC 2009 – All rights reserved
c) the generating projection is one-to-one from the MP domain in the oblate ellipsoid onto its MP range
and its inverse function is smooth and orientation-preserving in the MP range interior.
NOTE 1 This definition may be generalized to any ellipsoid including tri-axial ellipsoids, but this International Standard
only addresses map projections for oblate ellipsoids.
NOTE 2 The domain of a map projection is always a proper subset of the oblate ellipsoid surface. In particular, the
domain of the Mercator map projection (see Table 5.18) omits the pole points.
The generating projection P is specified in terms of surface geodetic CS coordinates (see Table 5.24). The
component functions P and P of the generating projection P shall be called the mapping equations:
1 2
P(λ, ϕ) = (u, v)
where:
u = P(λ, ϕ), and
v = P (λ, ϕ).
The MP range coordinate-components u and v shall be called easting and northing, respectively. The positive
direction of the u-axis (the easting axis) shall be called map-east. The positive direction of the v-axis (the
northing axis) shall be called map-north.
The inverse mapping equations are the component functions Q and Q of the inverse generating
1 2
−1
projection Q = P :
λ =Q (u,v)
ϕ =Q (u,v)
5.8.2 Map projection as a surface CS
If the inverse generating projection of a map projection Q is composed with the surface geodetic CS
generating function G , the resulting function G =G
Q is the generating function of a surface CS (see
GD MP GD
Figure 5.4). The CS domain is the MP range. In this International Standard, a map projection CS shall be a
surface CS for which the generating function is implicitly specified in terms of the mapping equations of a map
projection.
In some cases, the surface geodetic coordinates with coordinate-component ϕ = ±π 2 are not in the MP
-1 -1
domain of P nor are they in the range of Q. However, if the composite function G = P
G is continuous at
MP GD
-1
the pole points 0,0,±b , then G and G shall be extended by continuity to include the pole points in the
( )
MP MP
CS range.
NOTE  The CS generating function G =G
Q is not to be confused with the generating projection P.
MP GD
© ISO/IEC 2009 – All rights reserved
map projection geodetic
position-space
coordinate-space coordinate-space

v-axis ϕ -a xis
z-axis
(λ , ϕ)
G
GD
P
(u, v)
y-axis
Q
u-axis
λ -a xis
G = G Q
x-axis
MP GD
generating function
Figure 5.4 — The generating function of a map projection
5.8.3 Map projection geometry
5.8.3.1 Introduction
In general, the Euclidean geometry that a surface CS 2D coordinate-space inherits from R has no direct
significance with respect to the geometry of position-space. In particular, the Euclidean distance between a
pair of surface geodetic coordinates has no obvious meaning in position-space. In contrast, map projections
are specifically designed so that coordinate-space geometry will model one or more geometric aspects of the
corresponding oblate ellipsoid surface in position-space.
The map projection CSs specified in this International Standard are designed so that one or more geometric
aspects of the MP domain in the oblate ellipsoid surface are approximated or modelled by the corresponding
aspect in coordinate-space. The length of the line segment between two map coordinates is related to the
length of the corresponding surface curve. Similarly, one or more of directions, areas, the angles between two
intersecting curves, and shapes may be related approximately or exactly to the corresponding geometric
aspect on the oblate ellipsoid surface.
The extent to which these aspects are or are not closely related is an indication of distortion. Some map
projection CSs are designed to eliminate distortion for one geometric aspect (such as angles or area). Others
are designed to reduce distortion for several geometric aspects. In general, distortion tends to increase with
the size of the oblate ellipsoid MP domain relative to the total oblate ellipsoid surface area. Conversely,
distortion errors may be reduced by restricting the size of the MP domain. Map projections specified in this
International Standard in the context of a spatial reference frame may have areas of definition beyond which
the projection should not be used for some application domains due to unacceptable distortion .
5.8.3.2 Conformal map projections
A conformal map projection preserves angles. For such map projections, when two surface curves on an
oblate ellipsoid meet at the angle α, the image of those curves in the map coordinate-space meet at the same
angle α [THOM].
It is a consequence of the Theorema Egregium of Gauss that no map projection CS can eliminate all distortion.
© ISO/IEC 2009 – All rights reserved
In addition, [THOM] contains a derivation based on the theory of complex variables to obtain conditions that
specify when a projection is conformal. The map projections specified in Table 5.18 through Table 5.22 are
conformal. The equidistant cylindrical MP specified in Table 5.23 is not conformal.
NOTE  The conformal property is local. A conformal map projection preserves angles at a point, but does not
necessarily preserve shape or area. In particular, a large projected triangle may appear distorted under a conformal map
projection.
5.8.3.3 Point distortion
One indicator of map projection length distortion is the ratio of lengths between an infinitesimal line segment in
coordinate-space and the corresponding curve in position-space. Given a point in the interior of the MP range
with surface geodetic coordinate (λ,ϕ) the directional point distortion at (λ,ϕ) with respect to a smooth
surface curve passing through the point is the ratio of the differential distance in coordinate-space to the
differential arc length at (λ,ϕ) along the curve as determined by the mapping equations.
The latitudinal point distortion at (λ,ϕ), denoted j(λ,ϕ), is the directional point distortion with respect to the
meridian at (λ,ϕ). It is computed in the direction of the meridian at the point as:
2 2
∂u ∂ϕ + ∂v ∂ϕ
Δ(arc length in coordinate-space) ( ) ( )
j λ,ϕ = lim =
( )
Δ→0
Δ arc length along a meridian R ϕ
( ) ( )
M
whereR ϕ is the radius of curvature in the meridian as specified in Table 5.6.
( )
M
The longitudinal point distortion at (λ,ϕ), denoted k(λ,ϕ), is the directional point distortion with respect to the
parallel at (λ,ϕ). It is computed in the direction of the parallel at the point as:
2 2
∂u ∂λ + ∂v ∂λ
Δ arc length in coordinate-space ( ) ( )
( )
k λ,ϕ = lim =
( )
Δ→0
Δ(arc length along a parallel) R (ϕ)cos(ϕ)
N
whereR ϕ is the radius of curvature in the prime vertical as specified in Table 5.6.
( )
N
If a map projection is conformal, then the directional point distortion is independent of the direction of the
curve at the point. In particular, j(λ,ϕ) = k(λ,ϕ) for conformal map projections.
It is common practice in cartography to convert map projection coordinate-space to a display coordinate-
space by means of a scaling factor. The scaling factor σ shall be termed a map scale [HTDP] and a point in
the display space shall be termed a display coordinate . The relationship of a display coordinate (u , v ) to a
d d
map coordinate (u, v) is:
u =σu
d
v =σv
d
Map scale is commonly expressed as a ratio 1:n.
EXAMPLE  A map scale printed on a map sheet as 1:50 000 corresponds to σ = 1/50 000.

This concept is found in the literature under a variety of names. The term “point distortion” is introduced to avoid
ambiguity.
The distinction between a map projection coordinate and a display coordinate is not usually made explicit in the
literature. The term “display coordinate” is introduced to avoid ambiguity.
© ISO/IEC 2009 – All rights reserved
For a conformal map projection, the infinitesimal ratio of display distance to arc length along a parallel is the
point scale at (λ,ϕ) and is denoted by k . The relationship between point scale and point distortion is:
scaled
k (λ,ϕ) = σ k(λ,ϕ).
scaled
5.8.3.4 Geodetic azimuth and map azimuth
The geodetic azimuth from a non-polar point p on the surface of an ellipsoid to a second point p on the
1 2
surface is the angle measured clockwise from the meridian curve segment connecting p to the North pole to
the geodesic containing p and p (see Figure 5.5). The range of azimuth values α shall be 0≤α <2π . The
1 2
definition and range constraints apply to points in both hemispheres.
In a map projection CS, the map azimuth from a coordinate c to a coordinate c is defined as the angle from
1 2
the v-axis (map-north) clockwise to the line segment connecting c to c . In general, the map azimuth for a pair
1 2
of coordinates will differ in value from the geodetic azimuth of the corresponding points on the oblate ellipsoid.
North pole
meridians
p
α
12 2
p
geodesic
p p
1 2
equator
p
α
geodesic
p
p p
3 4
Figure 5.5 — Geodetic azimuths α from p to p and α from p to p
12 1 2 34 3 4
More general definitions that allow measurements of azimuth angle clockwise or counter-clockwise and from the north
or south side of the meridian are in use. The generalization to the case for which one or more of the two points is not on
the surface is treated in [RAPP1] and [RAPP2]. The more general definitions are not required for subsequent SRM
concepts.
© ISO/IEC 2009 – All rights reserved
5.8.3.5 Convergence of the meridian
Given a point λ,ϕ in the interior of the MP domain of a map projection, the meridian through that point is
( )
projected to a curve in coordinate-space that passes through the corresponding coordinate. The angle γ at the
coordinate in the clockwise direction from the curve to the v-axis (map-north) direction shall be called the
convergence of the meridian (COM) (see Figure 5.6).
 ∂u ∂v 
The relationship γ (λ,ϕ) = arctan2 − , is used to derive the formulae for COM from the mapping
 
∂ϕ ∂ϕ
 
equations of each of the map projections . The COM angle is adjusted to the range −π <γ ≤ π .
 ∂v ∂u 
NOTE  If the map projection is conformal, then an equivalent relationship is given by: .
γ λ,ϕ = arctan2 ,
( )
 
∂λ ∂λ
 
A typical geometry illustrating the COM at a point p is shown for the transverse Mercator map projection in
Figure 5.6.
true
map-
north
north
γ
v-axis
p
u-axis
Figure 5.6 — Convergence of the meridian
EXAMPLE  If p is directly map-north of p (it has a larger v coordinate-component), then the map azimuth is zero, but
2 1
the geodetic azimuth may not be zero. The geodetic azimuth is approximately the sum of the map azimuth and the COM if
the points are sufficiently close together.
5.8.4 Relationship to projection functions
5.8.4.1 Projection functions
Projection functions are defined in A.9. In some cases, the generating projection of a map projection CS is
derived from a projection function. The derivation involves two steps. The first step is to restrict the domain of

The function arctan2 is defined in A.8.2.
© ISO/IEC 2009 – All rights reserved
the projection function to a specified region of a given oblate ellipsoid so that the restricted function is one-to-
one. The range of a projection function is a surface in 3D position-space. The second step is to associate that
surface to 2D coordinate-space without introducing additional distortions.
In the case of planar projection functions, including the orthographic, perspective, and stereographic
projection functions, the range is in a plane that can be identified with 2D coordinate-space by selecting an
origin and unit axis points.
In the case of the cylindrical and conic projection functions, the range surface is a cylinder or a cone,
respectively. These surfaces are developable surfaces and, except for a line of discontinuity, are
homeomorphic to a subset of 2D coordinate-space with a homeomorphism that has a Jacobian determinant
equal to one. Conceptually, these surfaces can be unwrapped to a flat plane without stretching the surface.
The polar stereographic MP (Table 5.22) is derived from the stereographic projection function, and in the
spherical case, it is a conformal map projection. The same derivation may be applied to an oblate ellipsoid.
However, the resulting map projection will not have the conformal property. For this reason, the generalization
of the polar stereographic map projection mapping equations from the spherical case to the non-spherical
oblate ellipsoid case is not derived from the polar stereographic projection function. Instead it is derived
analytically to preserve the conformal property. Similarly, the Mercator map projection (Table 5.18) is designed
to have the conformal property and is not derived from the cylindrical projection function even in the case of a
sphere.
EXAMPLE  Polar stereographic: Given a sphere with a polar point p, the tangent plane to the sphere at p and the
opposite polar point v specify a stereographic planar projection function F (see A.9.2.3). The restriction of F to a
subsurface of the sphere that excludes v, is the generating projection for the sphere case of a polar stereographic map
projection. In Figure 5.7 the position s on the sphere is projected to point t on a plane.
v
s
t = F(s)
t
p
Figure 5.7 — Polar stereographic map projection
5.8.4.2 Map projection classification
The use of projection functions to derive map projections with desirable properties is limited, but does
motivate some classifications of map projections. These classifications include tangent and secant map
projections as well as conic and cylindrical map projections [SNYD, p. 5].
© ISO/IEC 2009 – All rights reserved
5.8.4.3 Cylindrical map projections
A map projection is classified as cylindrical if:
a) all meridians of the oblate ellipsoid project to parallel straight lines that are equally-spaced with
respect to the longitude of the meridians, and
b) all parallels of the oblate ellipsoid project to parallel straight lines that are perpendicular to the
meridian images.
As a consequence, γ λ,ϕ = 0 for a cylindrical map projection.
( )
EXAMPLE  The Mercator map projection (Table 5.18) and the equidistant cylindrical map projection (Table 5.23) are
both classified as cylindrical map projections.
A cylindrical map projection is tangent if the longitudinal point distortion is equal to one along the equator. It is
secant if the longitudinal point distortion is equal to one along two parallels equally-spaced from the equator in
latitude. In that case, the parallel with positive latitude shall be called the standard parallel. Tangent and
secant cylindrical map projections are illustrated in Figure 5.8.

Figure 5.8 — Tangent and secant cylindrical map projections
5.8.4.4 Conic map projections
A map projection is classified as conic if:
a) all meridians of the oblate ellipsoid project to radial straight lines that are equally-spaced in radial
angle with respect to the longitude of the meridians, and
© ISO/IEC 2009 – All rights reserved
b) all parallels of the oblate ellipsoid project to concentric arcs that are perpendicular to the meridian
images.
As a consequence, γ depends only on λ for conic map projections because the projections of meridians are straight line
segments with an angle depending only on the longitude.
EXAMPLE  Lambert conformal conic (see Table 5.21) is classified as a conic projection.
A conic map projection is tangent if along one parallel the longitudinal point distortion is equal to one. It is
secant if the longitudinal point distortion is equal to one along two parallels that are not symmetric about the
equator. In that case, the two parallels shall be called the standard parallels (see Figure 5.9).

Figure 5.9 — Tangent and secant conical map projections
5.8.5 Map projection CS common parameters
To avoid negative coordinate-component values or to reduce the magnitude of the values in a region of
interest in the coordinate-space of a map projection, two mapping equation parameters shall be provided to
control the position of the coordinate-space origin 0,0 . One, denoted as u , shall be called the false easting
( )
F
and shall offset easting values. The second, denoted as v , shall be called the false northing and shall offset
F
northing values.
A map projection CS specification may specify additional mapping equation parameters. The mapping
equation parameters, including false easting and false northing shall be also be called the CS parameters.
The CS parameters longitude of origin, denoted by λ , and latitude of origin, denoted by ϕ , are
origin origin
historically associated with some map projection CSs. Typically, the position with map coordinate u ,v has
( )
F F
geodetic longitude equal to λ and/or geodetic latitude equal to ϕ .
origin origin
If λ is present as a CS parameter in a map projection CS specification, it is used as the longitudinal
origin
centring function parameter (see Λ in Table 5.6.)
C
The CS parameter central scale, denoted by k , when present, is intended to control the tangent/secant
characteristics of the map projection CS and is therefore close to, but does not generally exceed, 1,0. In the
© ISO/IEC 2009 – All rights reserved
case of a sphere, k =1 corresponds to a tangent projection, and k <1 corresponds to a secant projection.
0 0
Typically, some point in the MP domain with geodetic longitude equal to λ and/or geodetic latitude equal to
origin
ϕ will have a longitudinal point distortion equal to k .
origin 0
For some MP cases, if k <1, there will exist a parallel with longitudinal point distortion equal to 1 at each
point on the parallel. The latitude of such a parallel is termed a secant latitude, or a latitude of true scale.
NOTE  Central scale should not be confused with Map scale. Map scales (see 5.8.3.3) are typically much smaller in
magnitude and are applied directly to the coordinate-space. In particular, if a transverse Mercator map projection with
central scale value k = 0,9996 is to be scaled 1:50 000 on a map sheet display, then the mapping equations
P(λ, ϕ), andP (λ, ϕ) are evaluated with k = 0,9996 and the display coordinates σP(λ, ϕ),σP (λ, ϕ) , are plotted
0 ( )
1 2 1 2
on the map sheet with σ = (1/50 000).
5.8.6 Augmented map projections
5.8.6.1 Augmentation with ellipsoidal height
A 3D CS can be specified from a map projection CS. The canonical embedding of a point (u, v) in R to the
point (u, v, 0) in the uv-plane of R allows map points in 2D coordinate-space to be augmented with a third
coordinate axis, the w-axis of R . To be considered as a 3D CS, an augmented 3-tuple (u, v, w) of coordinates
in the augmented map projection coordinate-space shall be associated to a unique position in position-space.
The association is to ellipsoidal height h = w . Given an augmented coordinate-tuple (u, v, w) for which (u, v)
belongs to the coordinate range of the underlying generating projection, the associated position is given in 3D
geodetic coordinates (λ, ϕ, h) where (λ, ϕ) is projected to (u, v) by the map projection mapping equations. The
third coordinate-space coordinate w is the vertical coordinate and the 3D geodetic coordinate constraints on
negative values of h impose corresponding constraints on allowed values for w. In some application domains,
other vertical coordinate measures are used (see Clause 9). Augmentation is restricted to ellipsoidal height in
this International Standard.
5.8.6.2 Distortion in augmented map projections
In addition to map projection distortion (see 5.8.3.1), augmentation causes additional distortion. Consider the
two straight-line segments between the pairs of coordinate-space points {(u , v , 0), (u , v , 0)} and {(u , v , w),
1 1 2 2 1 1
(u , v , w)} with w > 0 (see Figure 5.10). In augmented map projection geometry, the two line segments have
2 2
the same length. The corresponding curve in position-space of the first line segment is a surface curve of the
oblate ellipsoid (or sphere). The corresponding second curve is outside of the oblate ellipsoid (or sphere) and
has longer arc length than the first, and the length difference increases with w.
In general, vertical angles are not preserved and the angular error will vary with the point distortion value.
These and other distortions have profound implications for dynamic equations that are beyond the scope of
this International Standard.
© ISO/IEC 2009 – All rights reserved
(u , v , w) (u , v , w)
1 1 2 2
(u , v , 0) (u , v , 0)
1 1 2 2
coordinate-space
p’
q’
p
q
position-space
Figure 5.10 — Vertical distortion
5.9 CS specifications
5.9.1 Specification table elements and common functions and parameters
The CSs specified in this International Standard are presented in Table 5.8 through Table 5.35. Each CS
specification specifies the values of all elements presented in Table 5.5.
Table 5.5 — Coordinate system specification elements
Element Definition
Description A description of the CS including a common name, if any.
CS label The label of the CS (see 13.2.2).
CS code The code of the CS (see 13.2.3). Code 0 (UNSPECIFIED) is reserved.
Function type Either “generating function” or “map projection”.
One of: 3D linear, 3D curvilinear, surface linear, surface curvilinear, map
CS descriptor projection, 2D linear, 2D curvilinear, 1D linear, 1D curvilinear, or surface (map
projection) and 3D (augmented map projection).
Either “none” or a list of one or more properties of the CS chosen from the
Properties
following: orthogonal, not orthogonal, orthonormal, not orthonormal, conformal, or
not conformal. Conformal and not conformal only apply to map projections.
CS parameters and The CS
...

Annex A
(normative)
Mathematical foundations
A.1 Introduction
This annex identifies the concepts from mathematics used in this International Standard and specifies the
notation used for those concepts. No proofs are presented. A reader of this International Standard is assumed
to be familiar with mathematics including set theory, linear algebra, and the calculus of several real variables
as presented in reference works such as the Encyclopedic Dictionary of Mathematics [EDM].
n
A.2 R as a real vector space
An ordered set of n real numbers a where n is a natural number is called an n-tuple of real numbers and shall
n n
be denoted by a = a,a ,a ,⋅⋅⋅,a The set of all n-tuples of real numbers is denoted by R . R is an n-
( )
1 2 3 n
dimensional vector space.
n
The canonical basis for R is defined as:

e = 1,0,⋅⋅⋅,0 , e = 0,1,⋅⋅⋅,0 ,⋅⋅⋅, e = 0,0,⋅⋅⋅,1 .
( ) ( ) ( )
1 2 n
n
The elements of R may be called points or vectors. The latter term is used in the context of directions or
vector space operations.
The zero vector (0,0,⋅ ⋅ ⋅,0) is denoted by 0.
n
Definitions A.2(a) through A.2(j) apply to any vectorsx = (x,x ,⋅⋅⋅,x ) and y = (y,y ,⋅⋅⋅,y ) in R :
1 2 n 1 2 n
a) The inner product or dot-product of two vectors x and y is defined as:
x• y = x y + x y +⋅⋅⋅+ x y .
1 1 2 2 n n
b) Two vectors x and y are called orthogonal if x• y = 0.
c) If n ≥ 2, two vectors x and y are called perpendicular if and only if they are orthogonal.
NOTE 1 If n ≥ 2, x• y = x y cosα where α is the angle between x and y.
( )
d) x is called orthogonal to a set of vectors if x is orthogonal to each vector that is a member of the set.
e) The norm of x is defined as

x = x• x .
NOTE 2 The norm of x represents the length of the vector x. Only the zero vector 0 has norm zero.
f) x is called a unit vector if x =1.
g) A set of two or more orthogonal unit vectors is called an orthonormal set of vectors.
EXAMPLE  The canonical basis is an example of an orthonormal set of vectors.
© ISO/IEC 2009 – All rights reserved
h) The Euclidean metric d is defined by
d(x, y) = ||x – y||.
i) The value of d(x, y) is called the Euclidean distance between x and y.
j) The cross product of two vectors x and y in R is defined as the vector:

x× y = (x y − x y , x y − x y , x y − x y ) .
2 3 3 2 3 1 1 3 1 2 2 1
NOTE 3 The vector x × y is orthogonal to both x and y, and

,
x× y = x y sin(α )
where α is the angle between vectors x and y.
n
A.3 The point set topology of R
n n
Given a point p in R and a real value ε > 0, the set {q in R | d(p, q) < ε } is called the ε-neighbourhood of p.
n
Given a set D ⊂ R and a point p, the following terms are defined:
a) p is an interior point of D if at least one ε-neighbourhood of p is a subset of D.
b) The interior of a set D is the set of all points that are interior points of D.
NOTE 1 The interior of a set may be empty.
c) D is open if each point of D is an interior point of D. Consequently, D is open if it is equal to its interior.
d) p is a closure point of D if every ε-neighbourhood of p has a non-empty intersection with D.
NOTE 2 Every member of D is a closure point of D.
e) The closure of a set D is the set of all points that are closure points of D.
f) D is a closed set if it is equal to the closure set of D.
g) A set D is replete if all points in D belong to the closure of the interior of D.
NOTE 3 Every open set is replete. The union of an open set with any or all of its closure points forms a replete set. In
particular, the closure of an open set is replete.
EXAMPLE 1 In R {(x, y) | −π < x < π, −π/2 < y < π/2} is open and therefore replete.
EXAMPLE 2 {(x, y) | −π < x ≤ π, −π/2 < y < π/2} is replete.
EXAMPLE 3 {(x, y) | −π ≤ x ≤ π, −π/2 ≤ y ≤ π/2} is closed and replete.
n
A.4 Smooth functions on R
n
A real-valued function f defined on a replete domain in R is called smooth if its first derivative exists and is
continuous at each point in its domain.
The gradient of f is the vector of first order partial derivatives

 
∂f ∂f ∂f
grad f = , ,⋅⋅⋅, .
( )
 
∂v ∂v ∂v
 1 2 n 
© ISO/IEC 2009 – All rights reserved
n
Definitions A.4(a) through A.4(g) apply to any vector-valued function F defined on a replete domain D in R
m
with range in R .
th
a) The j -component function of a vector-valued function F is the real-valued function f defined by
j
th
f = e •F where e is the j canonical basis vector, j =1,2,⋅⋅⋅,m .
j j j
In this case:
F(v) = (f (v), f (v), f (v), …, f (v)) for v = (v , v , v , …,v ) in D.
1 2 3 m 1 2 3 n
b) F is called smooth if each component function fj is smooth.

c) The first derivative of a smooth vector-valued function F, denoted dF, evaluated at a point in the
domain is the n × m matrix of partial derivatives evaluated at the point:

∂f
 
j
i = 1, 2,⋅⋅⋅,n and j = 1,2,⋅⋅⋅,m .

 
∂v
 i 
d) The Jacobian matrix of F at the point v is the matrix of the first derivative of F.
NOTE 1 The rows of the Jacobian matrix are the gradients of the component functions of F.
e) In the case m = n, the Jacobian matrix is square and its determinant is called the Jacobian
determinant.
f) In the case m = n, F is called orientation preserving if its Jacobian determinant is strictly positive for all
points in D.
n
g) A vector-valued function F defined on R is linear if:
n
F(ax + y) = aF(x) + F(y) for all real scalars a and vectors x and y in R .
NOTE 2 All linear functions are smooth.
n
A vector-valued function E defined on R is affine if F, defined byF x = E x -E0 , is a linear function. All
( ) ( ) ( )
n
affine functions on R are smooth.
A function may be alternatively called an operator especially when attention is focused on how the function
maps a set of points in its domain onto a corresponding set of points in its range.
EXAMPLE  The localization operators (see 5.7).
A.5 Functional composition
If F and G are two vector valued functions and the range of G is contained in the domain of F, then F
G , the
composition of F with G, is the function defined by F
G (x)≡F G (x) . F
G has the same domain as G,
( )
and the range of F
G is contained in the range of F.
Functional composition also applies to scalar-valued functions f and g, If the range of g is contained in the
domain of f, then f
g (x), the composition of f with g, is the function defined by f
g (x)≡ f g (x) .
( )
© ISO/IEC 2009 – All rights reserved
A.6 Smooth surfaces in R
A.6.1 Implicit definition
3 3
A smooth surface in R is implicitly specified by a real-valued smooth function f defined on R as the set S of
all points (x, y, z) in R satisfying:
a) f(x, y, z) = 0 and
b) grad( f )(x, y, z) ≠ 0.
In this case, f is called a surface generating function for the surface S.
EXAMPLE 1 If n ≠ 0 and p are vectors in R and f(v) = n • (v - p), then f is smooth and grad( f ) = n ≠ 0. The plane
which is perpendicular to n and contains p is the smooth surface implicitly defined by the surface generating function f.
Special cases:
When n = (1, 0, 0) and p = 0, the yz-plane is implicitly defined.
When n = (0, 1, 0) and p = 0, the xz-plane is implicitly defined.
When n = (0, 0, 1) and p = 0, the xy-plane is implicitly defined.
The surface normal n at a point p = (x, y, z) on the surface implicitly specified by a surface generating function f
is defined as:
n≡ grad f p .
( )( )
grad f p
( )( )
NOTE  -n is also a surface normal to S at p. The surface generating function f determines the surface normal direction: n
or -n.
The tangent plane to a surface at a point p = (x, y, z) on the surface S implicitly defined by a surface generating
function f is the plane which is the smooth surface implicitly defined by h(v) = n • (v - p) where n is the surface
normal to S at p.
EXAMPLE 2 If a and b are positive non-zero scalars, define
2 2 2
x y z
f (x,y,z) = + + −1.
2 2 2
a a b
Then f is smooth and
2x 2y 2z
 
grad f x,y,z = , ,
( )( )
 
2 2 2
a a b
 
is never (0, 0, 0) on the surface implicitly specified by the set satisfying f = 0.
A.6.2 Ellipsoid surfaces
If a and b are positive non-zero scalars, the smooth function:
2 2 2
x y z
f (x,y,z) = + + −1
2 2 2
a a b
is a surface generating function for an ellipsoid of revolution smooth surface S.
© ISO/IEC 2009 – All rights reserved
When b ≤ a, the surface is called an oblate ellipsoid. In this case a is called the major semi-axis of the oblate
ellipsoid and b is called the minor semi-axis of the oblate ellipsoid.
The flattening of an oblate ellipsoid is defined as f = (a - b)/a.
The eccentricity of an oblate ellipsoid is defined as ε = 1− ba .
( )
The second eccentricity of an oblate ellipsoid is defined as ε′ = ab −1.
( )
When b = a, the oblate ellipsoid may be called a sphere of radius r = b = a.
When a < b, the surface is called a prolate ellipsoid. In this case, a is called the minor semi-axis of the prolate
ellipsoid and b is called the major semi-axis of the prolate ellipsoid.
2 2 2 2
NOTE 1 A sphere of radius r is also implicitly defined by the surface generating function f (x,y,z) = x + y + z −r .
NOTE 2 The term spheroid is often used to denote an oblate ellipsoid with an eccentricity close to zero (“almost
spherical”).
n
A.7 Smooth curves in R
A.7.1 Parametric definition
A.7.1.1 Smooth curve
n n
A smooth curve in R is parametrically specified by a smooth one-to-one R valued function F(t) defined on a
replete interval I in R such that ||dF(t)|| ≠ 0 for any t in I.
n
EXAMPLE 1 If p and n are vectors in R such that n ≠ 0 and L(t) = p + t n, -∞ < t < +∞, then L is smooth and
||dL(t)|| = ||n|| > 0. The line which is parallel to n and which contains p is a smooth curve parametrically specified by L.
EXAMPLE 2 If a and b are positive non-zero scalars and b ≤ a, define
F(t) = (a cos(t), b sin(t)) for all t in the interval -π < t ≤ π.

Then F is smooth and ||dF(t)|| ≥ b > 0 for all t in the interval and therefore parametrically specifies a smooth curve in R .
An ellipse in R with major semi-axis a and minor semi-axis b, 0 < b ≤ a, is parametrically specified by:

F(t) = (a cos(t), b sin(t)), for all t in the interval -π < t ≤ π.

A.7.1.2 Tangent to a smooth curve
If C(t) parametrically specifies a smooth curve C passing through a point p = C(t ), the tangent vector to C at p
p
shall be defined as:
t = dC t
( )
p
dC t
( )
p
where dC(t ) = (dC /dt, dC /dt, …, dC /dt) is the first derivative of C evaluated at t .
p 1 2 n p
NOTE  -t is also a tangent vector to C at p. The parameterization function C(t) determines the
...

Annex B
(informative)
Implementation notes
B.1 Introduction
This informative annex provides advisories relative to the implementation of the spatial operations contained
in this International Standard. It also contains illustrations of two time-dependent embedding transformations.
B.2 General observations
B.2.1 Finite precision
It is generally not possible to exactly implement theoretical formulations on a digital computer due to
limitations in representing real numbers on a finite word length computer. If x is a real number, its
representation on a digital computer can be viewed as x . The difference between x and x is called digitization
c c
error. There are some real numbers that can be exactly represented but generally the digital representation is
only good to a prescribed number of bits depending on the precision of the floating-point representation of the
computer system used. Implementation of spatial operations can involve relatively large numbers. Differences
of numbers with large absolute values can occur along with products of relatively small numbers with large
numbers. Loss of significance can occur due to these conditions.
EXAMPLE  Using single precision arithmetic for SRFs associated with the Earth may lead to a loss of precision on
the order of half a metre even when the application is for the near Earth region.
NOTE  To mitigate loss of precision it is advisable to employ double precision [IEC 60559] arithmetic for floating-point
operations.
B.2.2 Computational efficiency
In many application domains computational efficiency is very important. Some examples of such applications
include: embedded systems with real time control feed-back, the processing of large numbers of very large
environmental data files, real time graphics display of geographic data and large scale simulations involving
hundreds of thousands of interacting objects. Historically, computational assets were much less capable than
those currently available. As a result, much research over the last century has been devoted to reducing the
computational complexity for the type of spatial operations contained in this International Standard. Many of
the techniques currently used were developed for hand computation or in the context of more rudimentary
computational systems. Implementers have been slow to adapt to the capabilities provided by computational
systems that currently exist. Concomitant with the increased computational capabilities there have been
significant technical advances in the field of computational mathematics. New methods have emerged along
with better strategies for exploiting the current computational capabilities. These advances in computational
mathematics have generally not been exploited for the types of spatial operations within the scope of this
International Standard.
The strategy for selecting algorithms for implementation is dependent on the intended application. For a
general service system, where an interactive user needs a few spatial operations computed, efficiency is
becoming much less important. Current machines are so fast that humans cannot perceive the difference
between very fast machines and very slow ones. For such application domains the choice of algorithm is not
critical as long as it is accurate, reliable and covers the domain of interest.
© ISO/IEC 2009 – All rights reserved
For computationally intense applications most of the mathematical formulations contained in this International
Standard are not appropriate for implementation. Some of the closed-form solutions may be unacceptably
inefficient and may be replaced by various approximate methods.
EXAMPLE  Most implementations of the inverses for map projections are implemented with finite series methods in
order to avoid using potentially inefficient iterative methods.
B.2.3 Approximation
The replacement of theoretical formulations with approximations made to increase computational efficiency
introduces an error. The difference between the true value x and the approximation value x is the
a
approximation error. The implementation of an approximation using a double precision representation includes
both the digitization and approximation errors. The combination of these errors is called the computational
error. However, the magnitude of the approximation error usually dominates that of the digitization error and
therefore the digitization error may generally be ignored.
The acceptable computational error is application dependent. Increased capabilities of real measurement
systems and improved SRF models have led to increased requirements for more stringent error tolerances. In
high-resolution simulation applications the requirement is to keep the computational error in position as small
as 1 millimetre. Increased system accuracy requirements coupled with efficiency requirements place a
considerable premium on development and use of efficient algorithms. Given the variability in computer
system characteristics and application domain accuracy requirements there is no single solution that fits all
cases.
Subsequent clauses provide a set of general guidelines for algorithm designers and software developers that
are intended to broaden their conceptual approach to implementations. These guidelines are specific to Earth-
related spatial operations but most of them are applicable to the more general case.
B.3 Guidelines for algorithm development for spatial operations
B.3.1 Introduction
Many computational algorithms have been developed for spatial operations processing for a wide range of
applications. Many of these are not appropriate for efficient processing using current computer system
environments. If an application domain does not require efficient processing, any accurate algorithm for
computing spatial operations may be employed. In such cases, it is recommended that closed-form solutions
be employed when available, and iterative procedures otherwise.
This clause includes a set of guidelines or advisories for use in designing efficient algorithms. While the target
environment is generally a computer system with a super-scalar architecture, many of these advisories are
applicable to legacy computer systems and specialized systems used for embedded processing. Most of the
advisories are applicable to spatial operations processing for celestial bodies other than the Earth.
B.3.2 The computational environment
The properties of the computational environment should be taken into account. In recent decades a significant
improvement in computational capabilities has occurred. Yet, in some application domains, algorithms that
were developed for hand calculation are still being implemented. In addition, many traditional computational
methods developed for legacy computers are inappropriate for the new environment but continue to be used.
The principal characteristics of the new computational environments include:
a) readily-available low-cost Dynamic Random Access Memory (DRAM),
© ISO/IEC 2009 – All rights reserved
b) development of very high-speed cache memory that permits the dynamic allocation of blocks of critical
data to the processor cache memory,
c) super-scalar architectures that permit pipelined (parallel) processing,
d) integrated processors that permit very high-speed processing for some critical mathematical functions
(e. g. some transcendental functions and square root),
e) development of compilers that exploit the advantages of super-scalar architectures,
f) development of optimizing operating systems that re-order computations and memory accesses in
real time to increase efficiency, and
g) integrated support for Institute of Electrical and Electronics Engineers (IEEE) double precision
floating-point representation in which the mantissa is 52 bits (this is equivalent to 15 plus decimal
digits of accuracy, (see also [IEC 60559])).
An example of the impact of these changes is in the computation of trigonometric functions. In the legacy
computational environment, trigonometric functions were evaluated as system-level subroutines written in
software. Such routines were very slow sometimes taking between 30 and 45 floating-point operations to
complete. To meet system timeline specifications, software developers often replaced trigonometric
subroutine calls by in-line procedures that used piecewise linear or quadratic trigonometric calculations
(colloquially called “table lookup”). This required a considerable portion of the relatively small memory
available on legacy computers. Because memory was scarce at the time, this technique could only be used
sparingly. Accuracy was often degraded so that the array of fitting coefficients did not get too large.
In the current computational environment the trigonometric functions are computed in special processors
using high-speed memory and parallel processing. As a result, these functions produce double precision
results very quickly relative to the basic central processor cycle time of the computer. In particular, a sine
function call executes in a processing time equivalent to 8 to 10 floating-point operations. Square root calls are
even faster. On some computers, implementing a general in-line sine sub-routine (by table lookup) may
actually be slower than calling the system sine function. This can happen because the access time required to
fetch the appropriate fitting coefficients from dynamic random access memory may take longer than the entire
system routine computation. On the other hand, for modern machines where memory is virtually unlimited, it
is possible to develop in-line algorithms for the standard transcendental functions with accuracies approaching
that of double precision. Carefully designed procedures based on piecewise continuous approximations can
be developed for this purpose.
The development of in-line code for general-purpose calculation of standard mathematical routines is also
useful for reducing the execution time of compound functions or mathematical functions that are not in the
system library. In particular, it may be more efficient to evaluate sin(f(x)) in-line rather than computing f(x) and
then calling the sine function. The efficacy of the in-line approach in such a case depends on the nature of f(x).
B.3.3 Domain of application
The domain of applicability should be defined before developing or selecting an algorithm. Algorithm
designers and software developers may expend valuable development and computational time forcing their
methods to work in non-practical regions such as near the centre of an ERM or at ellipsoidal heights of 100
million kilometres from the surface. The number of applications for such regions is small (or zero) and the
interest in these regions is primarily academic. For an Earth referenced application there are several regions
of practical interest
EXAMPLE 1 For aircraft, an appropriate region in terms of ellipsoidal height is –200 metres to 35 000 metres for all
latitudes and longitudes. This covers the region where air-breathing vehicles can operate.
EXAMPLE 2 For sub-surface operations an appropriate region is –12 000 metres to +200 metres for all latitudes and
longitudes. This region covers the lowest bathymetric point of the Earth (Marianas Trench) to slightly above the ocean’s
© ISO/IEC 2009 – All rights reserved
surface. It is convenient to combine the two regions of these examples and to call the composite region, the near Earth
region.
EXAMPLE 3 Space operations may require a region extending above 35 kilometres to beyond the orbit of the moon.
This region will be called the space operations region.
All regions may be further divided into sub-regions for particular applications in order to simplify formulations
or for computational efficiency. Usually the latitude domain in this application is [-π/2, π/2] and the longitude
domain is (-π, π]. On occasion, a particular application may be restricted to a smaller latitude/longitude region
in order to simplify formulations and in the case of map projections to reduce distortions.
B.3.4 Define a meaningful error measure
In many situations involving spatial operations computation, the resulting variables are not exact due to
approximations made in the computational formulations. An error measure is needed to determine the
approximation error. If the target variables are in terms of distance in a Euclidean coordinate system, a
Euclidean metric can be used to measure the approximation error. Such an error measure is called position
error. Often the maximum error in the absolute value of the difference between the true values and the
approximate values of each component is used.
The average value of the magnitude of the differences of each component of position error has also been
used as an error measure. This practice makes the approximation errors appear to be much smaller than the
maximum errors, and depends on where the samples for the average are collected. This approach is
misleading and should not be used.
Sometimes the target variables contain angular errors along with distance errors. In this case the angular error
should be converted to distance so that a Euclidean error measure can be applied. Some variables, such as
point distortion are unit-less and the resulting computational error is unit-less.
B.3.5 Avoid excessive computational accuracy
The literature on methods for spatial operations processing contains many algorithms that are excessively
accurate. One paper on geocentric to geodetic coordinate conversion develops a procedure where the
-20
approximation error is 10 metres, an accuracy far exceeding any practical use. Many iterative procedures
can achieve such accuracies provided that a computational environment is available with sufficiently high
precision arithmetic. However, it is important not to waste computer cycles to attain superfluous accuracy.
-8
EXAMPLE  A method, A, with maximum error 10 m is sometimes declared superior to a method, B, which has a
-6
maximal error of 10 m. If method A takes more processing time than method B, it is not superior. In fact it is quite likely
-4
that both methods are too accurate. Suppose there is a method C with maximum error less than 10 metres but takes less
computer time than A or B. Then method C would likely be preferable for most (if not all) applications.
B.3.6 Determine the acceptable error before starting
The maximum allowable position error should be determined before starting an algorithm development. Note
that, when position error is small, its component errors are also very small. When a position error criterion is
used, the nominal position error is usually much smaller than the maximum error. In some applications, such
as in simulations, it is important to keep the computational error very small, as small as 1mm. It is difficult to
conceive of an application domain that requires, or would find useful, errors smaller than this for spatial
operations. This is particularly the case if scarce computational resources are used in order to achieve
superfluous accuracy.
B.3.7 Mathematical approaches
Mathematical formulations for spatial operations processing can be relatively complex. This complexity is
driven by the fact that many SRFs of interest are based on oblate ellipsoid ORMs. This results in formulations
© ISO/IEC 2009 – All rights reserved
in which the principal equations involved are non-linear and sometimes not solvable in closed form (e.g.,
geodesic distance). For most spatial operation formulations it is also necessary to have an inverse spatial
operation. Many spatial operation formulations have closed-form solutions in one direction but do not have
closed-form solutions for the inverse. This situation leads to a requirement to solve multivariate non-linear
equations where no closed solution is readily available.
Traditionally, either truncated power series, or iterative solutions have been used for solving spatial operation
computation problems. Power series solutions are almost always inferior to well-designed iterative solutions
from an efficiency point of view. Both of these methods have an interesting property that is often not
recognized. Almost all existing implementations of truncated power series solutions use all the terms in the
series no matter how close the independent variables are to the expansion point. In fact, when the
independent variables are close to the expansion point only a few terms are needed and the effect of higher-
order terms is vanishingly small. It is often easy to develop simple tests on the independent variables to
determine how many terms to use in a particular formulation. A similar situation exists in determining how
many iterations to perform in an iterative approach. The maximal number of iterations required to achieve a
required accuracy over some domain can be determined when testing an implementation. The implementation
of the iterative procedure can then use a fixed number of iterations. This avoids excessive iteration and avoids
the need for a termination test (which is usually computationally expensive). Legacy software designs often
use the maximum number of terms or iterations, regardless. This is often a significant waste in computation
time.
Another approach for solving multivariate non-linear equations is much more appropriate in the new
computational environment. This is the use of curve fitting or approximation of a function or the inverse of a
function. In its simplest form, this amounts to piecewise approximation or “table lookup”. Historically, the
perceived penalty associated with this approach is that it takes too much memory to store the coefficients of
the piecewise-defined functions to achieve usable accuracy. This penalty has been virtually eliminated by the
availability of large capacity low-cost dynamic random access memory. The trend in computational
mathematics is to use low-order local approximations for efficiency.
B.3.8 Good programming and formulation practices
Experienced programmers usually employ good programming practices. They move the computation of global
constants out of embedded loops to start up procedures, move locally computed constants to the highest
possible level, nest polynomials, avoid using power functions and leverage many other good practices.
Unfortunately, some universities now teach that these practices are not impo
...

Annex C
(informative)
Hierarchical diagrams for SRM concepts
C.1 Introduction
This annex presents diagrams that illustrate SRM concepts and their relationships. Figure C.1 illustrates the
relationships among many of the key SRM concepts as a UML class diagram. Hierarchical diagrams Figure
C.2, Figure C.3, and Figure C.4 illustrate the relationships between RDs, RD categories, ORMs and ORM
templates. These concepts are applicable to spatial objects of 2 and 3 dimensions. For simplicity of
presentation, this informative annex only presents the 3D case. Figure C.2 illustrates the relationship between
reference datum categories and (a subset of) the standardized RDs. Figure C.3 shows the relationship
between ORM templates and RD components. Three examples of ORMs based on an ORM template are
shown in Figure C.4.
C.2 Hierarchical diagrams
uses
Spatial
Reference
Frame Set
Spatial
Reference
Frame
Template
1.*
1.*
operation instantiates
Spatial
Reference
Frame
Object
Reference
Model
Template
specifies
1.*
instantiates
Object
Reference
Model
Spatial
Coordinate
System
specifies
maps into embeds into
Abstract
Normal
Coordinate-Space Coordinate Position-Space Object-Space
Embedding
System
1.*
*
* *
*
*
*
defines
Reference Spatial Object Constructed
Coordinate Position
(of Interest) Spatial Entity
Datum
bound to
Figure C.1 — SRM concepts and their relationships
© ISO/IEC 2009 – All rights reserved
In Figure C.1 shaded concepts are those that appear in the SRM API (Clause 11), and that can be registered
(Clause 13). The aggregation relationships involving Coordinate-Space, Position-Space, and Object-Space
are intended only to show that the component objects (Coordinate, Position, etc.) are defined within the
respective spaces. A multiplicity of “*” is intended to indicate that there are poten
...

Annex D
(normative)
RDs associated with physical objects
D.1 Introduction
This annex presents the specification of RDs whose parameters are determined as a result of measurements
of a physical object. Parameter values are specified by value or by reference. Parameters specified by
reference use the terminology of the cited references. Those terms are enclosed in brackets ( { } ).
Referenced values in length units other than metres are converted to metres to specify the corresponding RD
parameter. The zero value of flattening for a sphere RD is a precise value.
D.2 RDs
The elements of an ORM specification are defined in Table 7.9. Table D.1 is a directory of these RDs
organized by the type of RD surface. The RD entries in each table are grouped by physical object type and
then ordered alphabetically by their label. Table D.1 includes RDs specified in this annex and deprecated RDs
specified in Annex J.
Table D.1 — RD specification directory
RD specification table Tables
non-sphere Oblate ellipsoid RD specifications Table D.2 and Table J.2
Sphere RD specifications Table D.3 and Table J.3
Prolate ellipsoid RD specifications Table D.4 and Table J.4
Tri-axial ellipsoid RD specifications Table D.5 and Table J.5

© ISO/IEC 2009 – All rights reserved 349

Table D.2 — Oblate ellipsoid RD specifications
Parameters
RD
RD label Description Date References
code
Major semi-axis, a Flattening, f Error estimate
Object type: Earth
[83502T, App.
AIRY_1830 17 Airy 6 377 563,396 1/299,324 964 6 Assumed precise 1830
A-1, "AA"]
[DIGEST,
APL_4r5_1968 20 APL 4.5 6 378 144 1/298,23 Unknown 1968
Table 6.1,
"AP"]
AUSTRALIAN_NATIONAL- [83502T, App.
23 Australian national 6 378 160 1/298,25 Assumed precise 1966
_1966 A-1, "AN"]
[DIGEST,
AVERAGE_TERRESTRIAL-
24 Average terrestrial system 6 378 135 1/298,257 Unknown 1977 Table 6.1,
_1977
"AT"]
Bessel (Ethiopia,
[83502T, App.
BESSEL_1841_ETHIOPIA 26 Indonesia, Japan, and 6 377 397,155 1/299,152 812 8 Assumed precise 1841
A-1, "BR"]
Korea)
[83502T, App.
BESSEL_1841_NAMIBIA 27 Bessel (Namibia) 6 377 483,865 1/299,152 812 8 Assumed precise 1841
A-1, "BN"]
[DIGEST,
CLARKE_1858 33 Clarke 6 378 235,6 1/294,260 676 8 Unknown 1858 Table 6.1,
"CA"]
[DIGEST,
CLARKE_1858_MODIFIED 34 Clarke - modified 6 378 293,645 1/294,26 Unknown 1858
Table 6.1,
"CB"]
[83502T, App.
CLARKE_1866 35 Clarke 6 378 206,4 1/294,978 698 2 Assumed precise 1866
A-1, "CC"]
[83502T, App.
CLARKE_1880 36 Clarke 6 378 249,145 1/293,465 Assumed precise 1880
A-1, "CD"]
350 © ISO/IEC 2009 – All rights reserved

Parameters
RD
RD label Description Date References
code
Major semi-axis, a Flattening, f Error estimate
[DIGEST,
CLARKE_1880_CAPE 37 Clarke - Cape 6 378 249,145 1/293,466 307 7 Unknown 1880 Table 6.1,
"CE"]
[DIGEST,
CLARKE_1880_FIJI 38 Clarke - Fiji 6 378 301 1/293,465 Unknown 1880 Table 6.1,
"CJ"]
[DIGEST,
CLARKE_1880_IGN 39 Clarke - IGN 6 378 249,2 1/293,466 020 8 Unknown 1880
Table 6.1,
"CG"]
[DIGEST,
CLARKE_1880_PALESTINE 40 Clarke - Palestine 6 378 300,782 1/293,466 307 7 Unknown 1880 Table 6.1,
"CF"]
[DIGEST,
CLARKE_1880_SYRIA 41 Clarke - Syria 6 378 247,842 1/293,466 351 7 Unknown 1880
Table 6.1, "CI"]
[DIGEST,
DANISH_1876 45 Danish - Andrae 6 377 104,430 1/300 Unknown 1876 Table 6.1,
"DA"]
[DIGEST,
DELAMBRE_1810 47 Delambre 6 376 985,228 1/308,64 Unknown 1810 Table 6.1,
"DB"]
[83502T, App.
EVEREST_1948 57 Everest 6 377 304,063 1/300,801 7 Assumed precise 1948
A-1, "EE"]
[83502T, App.
EVEREST_1956 58 Everest 6 377 301,243 1/300,801 7 Assumed precise 1956
A-1, "EC"]
[83502T, App.
EVEREST_1969 60 Everest 6 377 295,664 1/300,801 7 Assumed precise 1969
A-1, "ED"]
[83502T, App.
EVEREST_ADJ_1937 56 Everest 1830 - adjusted 6 377 276,345 1/300,801 7 Assumed precise 1937
A-1, "EA"]
© ISO/IEC 2009 – All rights reserved 351

Parameters
RD
RD label Description Date References
code
Major semi-axis, a Flattening, f Error estimate
Everest 1830 - 1967
definition (Brunei and East [83502T, App.
EVEREST_BRUNEI_1967 61 6 377 298,556 1/300,801 7 Assumed precise 1967
Malaysia - Sabah and A-1, "EB"]
Sarawak)
Everest 1830 - revised [83502T, App.
EVEREST_REVISED_1962 59 6 377 309,613 1/300,801 7 Assumed precise 1962
definition A-1, "EF"]
[DIGEST,
FISCHER_1960 62 Fischer - Mercury 6 378 166 1/298,3 Unknown 1960
Table 6.1,
"FM"]
[DIGEST,
FISCHER_1968 63 Fischer 6 378 150 1/298,3 Unknown 1968 Table 6.1,
"FC"]
[DIGEST,
Geodetic Reference
GRS_1967 67 6 378 160 1/298,247 167 4 Unknown 1967
Table 6.1,
System (GRS)
"RE"]
Geodetic Reference
[83502T, App.
GRS_1980 68 6 378 137 1/298,257 222 101 Assumed precise 1980
A-1, "RF"]
System (GRS)
[83502T, App.
HELMERT_1906 70 Helmert 6 378 200 1/298,3 Assumed precise 1906
A-1, "HE"]
[83502T, App.
HOUGH_1960 72 Hough 6 378 270 1/297 Assumed precise 1960
A-1, "HO"]
International Association of
[DIGEST,
IAG_1975 74 Geodesy (IAG) best 6 378 140 1/298,257 Unknown 1975
Table 6.1, "IA"]
estimate
[83502T, App.
INDONESIAN_1974 77 Indonesian 6 378 160 1/298,247 Assumed precise 1974
A-1, "ID"]
[83502T, App.
INTERNATIONAL_1924 78 International 6 378 388 1/297 Assumed precise 1924
A-1, "IN"]
352 © ISO/IEC 2009 – All rights reserved

Parameters
RD
RD label Description Date References
code
Major semi-axis, a Flattening, f Error estimate
[83502T, App.
KRASSOVSKY_1940 84 Krassovsky 6 378 245 1/298,3 Assumed precise 1940
A-1, "KA"]
[DIGEST,
KRAYENHOFF_1827 85 Krayenhoff 6 376 950,4 1/309,65 Unknown 1827
Table 6.1,
"KB"]
[83502T, App.
MODIFIED_AIRY_1849 97 Modified Airy 6 377 340,189 1/299,324 964 6 Assumed precise 1849
A-1, "AM"]
[83502T, App.
MODIFIED_FISCHER_1960 98 Modified Fischer 6 378 155 1/298,3 Assumed precise 1960
A-1, "FA"]
[DIGEST,
PLESSIS_MODIFIED_1817 115 Plessis - Modified 6 376 523 1/308,64 Unknown 1817 Table 6.1,
"PM"]
[83502T, App.
SOUTH_AMERICAN_1969 125 South American 6 378 160 1/298,25 Assumed precise 1969
A-1, "SA"]
[DIGEST,
SOVIET_GEODETIC_1985 126 Soviet geodetic system 6 378 136 1/298,257 Unknown 1985
Table 6.1,
"SG"]
[DIGEST,
SOVIET_GEODETIC_1990 127 Soviet geodetic system 6 378 136 1/298,257 839 3 Unknown 1990 Table 6.1,
"SN"]
[DIGEST,
STRUVE_1860 128 Struve 6 378 298,3 1/294,73 Unknown 1860 Table 6.1,
"ST"]
[DIGEST,
WALBECK_AMS_1963 140 Walbeck 1819 - AMS 6 376 896 1/302,78 Unknown 1963 Table 6.1,
"WB"]
[DIGEST,
WALBECK_PLANHEFT_1942 141 Walbeck 1819 - Planheft 6 376 895 1/302,782 156 5 Unknown 1942
Table 6.1,
© ISO/IEC 2009 – All rights reserved 353

Parameters
RD
RD label Description Date References
code
Major semi-axis, a Flattening, f Error estimate
"WA"]
[DIGEST,
WAR_OFFICE_1924 142 War office - McCaw 6 378 300 1/296 Unknown 1924 Table 6.1,
"WO"]
[83502T, App.
WGS_1972 146 World geodetic system 6 378 135 1/298,26 Assumed precise 1972
A-1, "WD"]
[83502T, App.
WGS_1984 145 World geodetic system 6 378 137 1/298,257 223 563 Assumed precise 1984
A-1, "WE"]
Object type: Planet (non-Earth)
{Equatorial radius (km)} / ( As specified
{Equatorial radius [RIIC, Table IV,
JUPITER_1988 82 Jupiter {Equatorial radius (km)} - {Polar accompanying the 1988
(km)} "Jupiter"]
radius (km)} ) parameter value
{Equatorial radius (km)} / ( As specified
{Equatorial radius [RIIC, Table IV,
MARS_2000 89 Mars 2000
{Equatorial radius (km)} - {Polar accompanying the
(km)} "Mars"]
radius (km), AVG} ) parameter value
{Equatorial radius (km)} / ( As specified
{Equatorial radius [RIIC, Table IV,
NEPTUNE_1991 105 Neptune {Equatorial radius (km)} - {Polar accompanying the 1991
(km)} "Neptune"]
radius (km)} ) parameter value
{Equatorial radius (km)} / ( As specified
{Equatorial radius [RIIC, Table IV,
SATURN_1988 123 Saturn {Equatorial radius (km)} - {Polar accompanying the 1988
(km)} "Saturn"]
radius (km)} ) parameter value
{Equatorial radius (km)} / ( As specified
{Equatorial radius [RIIC, Table IV,
URANUS_1988 138 Uranus {Equatorial radius (km)} - {Polar accompanying the 1988
(km)} "Uranus"]
radius (km)} ) parameter value
Object type: Satellite
{Subplanetary {Subplanetary equatorial radius} As specified
Larissa (satellite of [RIIC, Table V,
LARISSA_1991 86 equatorial radius / ( {Subplanetary equatorial accompanying the 1991
Neptune) "Larissa"]
(km)} radius} - {Polar radius} ) parameter value
354 © ISO/IEC 2009 – All rights reserved

Parameters
RD
RD label Description Date References
code
Major semi-axis, a Flattening, f Error estimate
{Subplanetary {Subplanetary equatorial radius} As specified
[RIIC, Table V,
METIS_2000 93 Metis (satellite of Jupiter) equatorial radius / ( {Subplanetary equatorial accompanying the 2000
"Metis"]
(km)} radius} - {Polar radius} ) parameter value
Object type: Sun
Table D.3 — Sphere RD specifications
Parameters
RD
RD label Description Date References
code
Major semi-axis, a Flattening, f Error estimate
Object type: Earth
Coupled
[ERNWM,
Ocean/Atmospheric
COAMPS_1998 42 {Radius (metres)} 0 a:{ Error estimate} 1998 Table 1,
Mesoscale Prediction
"COAMPS"]
TM
System (COAMPS )
[ERNWM,
MASS_1999 91 MASS {Radius (metres)} 0 a:{ Error estimate} 1999 Table 1,
"MASS"]
Mesoscale (weather) Model
[ERNWM,
5 (MM5), Air Force
MM5_1997 96 {Radius (metres)} 0 a:{ Error estimate} 1997 Table 1, "MM5
Weather Agency (AFWA),
(AFWA)"]
US
[ERNWM,
MODTRAN_MIDLATITUDE- MODTRAN (midlatitude Table 1,
a:{ Error estimate}
99 {Radius (metres)} 0 1989
_1989 regions) "MODTRAN,
Midlatitude"]
© ISO/IEC 2009 – All rights reserved 355

Parameters
RD
RD label Description Date References
code
Major semi-axis, a Flattening, f Error estimate
[ERNWM,
MODTRAN (subarctic Table 1,
MODTRAN_SUBARCTIC_1989 100 {Radius (metres)} 0 a:{ Error estimate} 1989
regions) "MODTRAN,
Subarctic"]
[ERNWM,
MODTRAN (tropical Table 1,
MODTRAN_TROPICAL_1989 101 {Radius (metres)} 0 a:{ Error estimate} 1989
regions) "MODTRAN,
Tropical"]
MULTIGEN_FLAT_EARTH-
103 Multigen flat Earth 6 366 707,02 0 Precise 1989 [MFCG]
_1989
Navy Operational Global
[ERNWM,
Atmospheric Prediction
NOGAPS_1988 107 {Radius (metres)} 0 a:{ Error estimate} 1988 Table 1,
"NOGAPS"]
System (NOGAPS), US
Object type: Planet (non-Earth)
As specified
Eros (asteroid 433, a minor [RIIC, Table VI,
EROS_2000 54 {Mean radius (km)} 0 accompanying the 2000
planet) "Eros"]
parameter value
As specified
[RIIC, Table IV,
MARS_SPHERE_2000 90 Mars {Mean radius (km)} 0 accompanying the 2000
"Mars"]
parameter value
As specified
[RIIC, Table IV,
MERCURY_1988 92 Mercury {Mean radius (km)} 0 accompanying the 1988
"Mercury"]
parameter value
As specified
[RIIC, Table IV,
PLUTO_1994 116 Pluto {Mean radius (km)} 0 accompanying the 1994
"Pluto"]
parameter value
356 © ISO/IEC 2009 – All rights reserved

Parameters
RD
RD label Description Date References
code
Major semi-axis, a Flattening, f Error estimate
As specified
[RIIC, Table IV,
VENUS_1991 139 Venus {Mean radius (km)} 0 accompanying the 1991
"Venus"]
parameter value
Object type: Satellite
As specified
[RIIC, Table V,
ANANKE_1988 19 Ananke (satellite of Jupiter) {Mean radius (km)} 0 accompanying the 1988
"Ananke"]
parameter value
As specified
[RIIC, Table V,
BELINDA_1988 25 Belinda (satellite of Uranus) {Mean radius (km)} 0 accompanying the 1988
"Belinda"]
parameter value
As specified
[RIIC, Table V,
BIANCA_1988 28 Bianca (satellite of Uranus) {Mean radius (km)} 0 1988
accompanying the
"Bianca"]
parameter value
As specified
[RIIC, Table V,
CARME_1988 31 Carme (satellite of Jupiter) {Mean radius (km)} 0 accompanying the 1988
"Carme"]
parameter value
As specified
[RIIC, Table V,
CHARON_1991 32 Charon (satellite of Pluto) {Mean radius (km)} 0 1991
accompanying the
"Charon"]
parameter value
As specified
Cordelia (satellite of [RIIC, Table V,
CORDELIA_1988 43 {Mean radius (km)} 0 accompanying the 1988
Uranus) "Cordelia"]
parameter value
As specified
Cressida (satellite of [RIIC, Table V,
CRESSIDA_1988 44 {Mean radius (km)} 0 accompanying the 1988
Uranus) "Cressida"]
parameter value
As specified
Desdemona (satellite of [RIIC, Table V,
DESDEMONA_1988 48 {Mean radius (km)} 0 accompanying the 1988
Uranus) "Desdemona"]
parameter value
© ISO/IEC 2009 – All rights reserved 357

Parameters
RD
RD label Description Date References
code
Ma
...

Annex E
(normative)
ORM specifications
E.1 Introduction
This annex presents the specification of the standardized ORMs and associated RTs. If two or more object-
fixed ORMs for the same object are specified then one of the ORMs is designated as the reference ORM for
that object. Table E.1 in E.2.1 lists the reference ORMs specified in this International Standard, ordered
alphabetically by their label. ORM specifications are listed in tables in E.2.2 according to object categories
(abstract, Earth, other planet, satellites, and Sun) and binding type (object-fixed or dynamic). Table E.2
provides a directory of these tables. Parameter values in the tables are specified by value or by reference.
Parameters specified by reference use the terminology in the cited references. Those terms are enclosed in
brackets ( { } ). Referenced values in length units other than metres are converted to metres to specify the
corresponding RT parameter. Angular values are generally expressed in the units of radian. However, to avoid
a loss of precision, some angular values are expressed in the units of arc second (″) or arc degree (°), as
indicated.
E.2 ORMs
E.2.1 Reference ORMs
Table E.1 — Reference ORM directory
Object name Type Reference ORM label
2D modelling space Abstract ABSTRACT_2D
3D modelling space Abstract ABSTRACT_3D
Adrastea Satellite ADRASTEA_2000
Amalthea Satellite AMALTHEA_2000
Ariel Satellite ARIEL_1988
Atlas Satellite ATLAS_1988
Belinda Satellite BELINDA_1988
Bianca Satellite BIANCA_1988
Callisto Satellite CALLISTO_2000
Calypso Satellite CALYPSO_1988
Charon Satellite CHARON_1991
Cordelia Satellite CORDELIA_1988
© ISO/IEC 2009 – All rights reserved
Object name Type Reference ORM label
Cressida Satellite CRESSIDA_1988
Deimos Satellite DEIMOS_1988
Desdemona Satellite DESDEMONA_1988
Despina Satellite DESPINA_1991
Dione Satellite DIONE_1982
Earth Earth WGS_1984
Enceladus Satellite ENCELADUS_1994
Epimetheus Satellite EPIMETHEUS_1988
Eros (asteroid 433) Planet EROS_2000
Europa Satellite EUROPA_2000
Galatea Satellite GALATEA_1991
Ganymede Satellite GANYMEDE_2000
Gaspra (asteroid 951) Planet GASPRA_1991
Helene Satellite HELENE_1992
Iapetus Satellite IAPETUS_1988
Ida (asteroid 243) Planet IDA_1991
Io Satellite IO_2000
Janus Satellite JANUS_1988
Juliet Satellite JULIET_1988
Jupiter Planet JUPITER_1988
Larissa Satellite LARISSA_1991
Mars Planet MARS_2000
Mercury Planet MERCURY_1988
Metis Satellite METIS_2000
Mimas Satellite MIMAS_1994
Miranda Satellite MIRANDA_1988
Moon Satellite MOON_1991
© ISO/IEC 2009 – All rights reserved
Object name Type Reference ORM label
Naiad Satellite NAIAD_1991
Neptune Planet NEPTUNE_1991
Oberon Satellite OBERON_1988
Ophelia Satellite OPHELIA_1988
Pan Satellite PAN_1991
Pandora Satellite PANDORA_1988
Phobos Satellite PHOBOS_1988
Phoebe Satellite PHOEBE_1988
Pluto Planet PLUTO_1994
Portia Satellite PORTIA_1988
Prometheus Satellite PROMETHEUS_1988
Proteus Satellite PROTEUS_1991
Puck Satellite PUCK_1988
Rhea Satellite RHEA_1988
Rosalind Satellite ROSALIND_1988
Saturn Planet SATURN_1988
Sun Sun SUN_1992
Telesto Satellite TELESTO_1988
Tethys Satellite TETHYS_1991
Thalassa Satellite THALASSA_1991
Thebe Satellite THEBE_2000
Titan Satellite TITAN_1982
Titania Satellite TITANIA_1988
Triton Satellite TRITON_1991
Umbriel Satellite UMBRIEL_1988
Uranus Planet URANUS_1988
Venus Planet VENUS_1991
© ISO/IEC 2009 – All rights reserved
This Page Intentionally Left Blank

© ISO/IEC 2009 – All rights reserved
E.2.2 Standardized ORMs
The elements of an ORM specification are defined in Table 7.10. Table E.2 is a directory of standardized ORMs organized by category of ORM and type of object. The
ORM entries in each table are ordered alphabetically by their label. The deprecated ORMs are specified in Annex J. ORM specifications may include one or more RT
specifications. The RT specifications associated with an ORM are specified in a corresponding table as shown in Table E.2.
Table E.2 — ORM specification directory
ORM and RT specification tables ORM table RT table
Abstract ORM specifications Table E.3 Table E.4
Object-fixed ERM specifications Table E.5 Table E.6
Dynamic ERM specifications Table E.7 n/a
Time-fixed instances of dynamic ERM specifications Table E.8 Table E.9
Object-fixed planet (non-Earth) ORM specifications Table E.10 Table E.11
Dynamic planet (non-Earth) ORM specifications Table E.12 n/a
Time-fixed instances of dynamic planet (non-Earth) ORM specifications Table E.13 Table E.14
Object-fixed satellite ORM specifications Table E.15 Table E.16
Time-fixed instances of dynamic satellite ORM specifications Table E.17 Table E.18
Stellar ORM specifications Table E.19 Table E.20
Dynamic stellar ORM specifications Table E.21 n/a
Time-fixed instances of dynamic stellar ORM specifications Table E.22 Table E.23

© ISO/IEC 2009 – All rights reserved 369

Table E.3 — Abstract ORM specifications
Binding
ORM Published RD
ORM label Reference ORM informa Region ORMT label References
code name parameterization
tion
This is the reference ORM
2D modelling
ABSTRACT_2D 1 for abstract 2D object- none Universal BI_AXIS_ORIGIN_2D n/a none
space
space.
This is the reference ORM
3D modelling
for abstract 3D object-
ABSTRACT_3D 2 none Universal TRI_PLANE n/a none
space
space.
Table E.4 — Abstract ORM reference transformation specifications
RT Date
ORM label RT label RT region RT parameters References
code published
ABSTRACT_2D ABSTRACT_2D_IDENTITY 1 Universal n/a (reference ORM) n/a none
ABSTRACT_3D ABSTRACT_3D_IDENTITY 2 Universal n/a (reference ORM) n/a none

370 © ISO/IEC 2009 – All rights reserved

Table E.5 — Object-fixed ERM specifications
ORM Published Reference Binding RD
ORM label Region ORMT label References
code name ORM information parameterization
Burkina Faso,
Cameroon, [83502T,
ADINDAN_1991 3 Adindan WGS_1984 1991 Ethiopia, Mali, OBLATE_ELLIPSOID CLARKE_1880 App. B.2,
Senegal, and "ADI"]
Sudan
[83502T,
Afgooye KRASSOVSKY-
AFGOOYE_1987 5 WGS_1984 1987 Somalia OBLATE_ELLIPSOID App. B.2,
(Somalia) _1940
"AFG"]
[83502T,
Bahrain and INTERNATIONAL-
AIN_EL_ABD_1970 6 Ain el Abd WGS_1984 1970 OBLATE_ELLIPSOID App. B.3,
Saudi Arabia _1924
"AIN"]
American [83502T,
AMERICAN_SAMOA- American
8 WGS_1984 1962 Samoa OBLATE_ELLIPSOID CLARKE_1866 App. B.10,
_1962 Samoa
Islands "AMA"]
[83502T,
Anna 1 AUSTRALIAN-
ANNA_1_1965 9 WGS_1984 1965 Cocos Islands OBLATE_ELLIPSOID App. B.9,
(astronomic) _NATIONAL_1966
"ANO"]
Antigua and [83502T,
Antigua
ANTIGUA_1943 10 WGS_1984 1943 Leeward OBLATE_ELLIPSOID CLARKE_1880 App. B.8,
(astronomic)
Islands "AIA"]
© ISO/IEC 2009 – All rights reserved 371

ORM Published Reference Binding RD
ORM label Region ORMT label References
code name ORM information parameterization
Botswana,
Burundi,
Lesotho,
[83502T,
Malawi,
App. B.2,
ARC_1950 11 Arc WGS_1984 1950 OBLATE_ELLIPSOID CLARKE_1880
Swaziland,
"ARF"]
Zaire,
Zambia, and
Zimbabwe
[83502T,
Kenya and
ARC_1960 12 Arc WGS_1984 1960 OBLATE_ELLIPSOID CLARKE_1880 App. B.2,
Tanzania
"ARS"]
[83502T,
Ascension INTERNATIONAL-
ASCENSION_1958 14 Ascension WGS_1984 1958 OBLATE_ELLIPSOID App. B.8,
Island _1924
"ASC"]
[83502T,
AUSTRALIAN_GEOD- Australian Australia and AUSTRALIAN-
16 WGS_1984 1966 OBLATE_ELLIPSOID App. B.4,
_1966 Geodetic Tasmania _NATIONAL_1966
"AUA"]
[83502T,
AUSTRALIAN_GEOD- Australian Australia and AUSTRALIAN-
17 WGS_1984 1984 OBLATE_ELLIPSOID App. B.4,
_1984 Geodetic Tasmania _NATIONAL_1966
"AUG"]
Ayabelle [83502T,
AYABELLE-
18 Lighthouse WGS_1984 1991 Djibouti OBLATE_ELLIPSOID CLARKE_1880 App. B.2,
_LIGHTHOUSE_1991
(Djibouti) "PHA"]
372 © ISO/IEC 2009 – All rights reserved

ORM Published Reference Binding RD
ORM label Region ORMT label References
code name ORM information parameterization
Beacon E [83502T,
Iwo Jima INTERNATIONAL-
BEACON_E_1945 19 (Iwo-jima; WGS_1984 1945 OBLATE_ELLIPSOID App. B.10,
Island _1924
astronomic) "ATF"]
Efate and
[83502T,
Bellevue Erromango INTERNATIONAL-
BELLEVUE_IGN_1987 21 WGS_1984 1987 OBLATE_ELLIPSOID App. B.10,
(IGN) Islands _1924
"IBE"]
(Vanuatu)
[83502T,
BERMUDA_1957 22 Bermuda WGS_1984 1957 Bermuda OBLATE_ELLIPSOID CLARKE_1866 App. B.8,
"BER"]
[83502T,
Guinea- INTERNATIONAL-
App. B.2,
BISSAU_1991 24 Bissau WGS_1984 1991 OBLATE_ELLIPSOID
Bissau _1924
"BID"]
[83502T,
Bogota INTERNATIONAL-
BOGOTA_OBS_1987 25 WGS_1984 1987 Colombia OBLATE_ELLIPSOID App. B.7,
Observatory _1924
"BOO"]
© ISO/IEC 2009 – All rights reserved 373

ORM Published Reference Binding RD
ORM label Region ORMT label References
code name ORM information parameterization
The x-
positive xz-
half-plane
Bogota contains
Observatory Bogota,
[83502T,
BOGOTA_OBS_1987_PM- (with the Colombia INTERNATIONAL-
26 WGS_1984 Colombia OBLATE_ELLIPSOID App. B.7,
_BOGOTA Prime (Instituto _1924
"BOO"]
Meridian at Geografico
Bogota) Augustin
Cadazzi
(IGAC)
determina-
tion).
Bangka and
[83502T,
Belitung BESSEL_1841-
BUKIT_RIMPAH_1987 27 Bukit Rimpah WGS_1984 1987 OBLATE_ELLIPSOID App. C.2,
_ETHIOPIA
Islands
"BUR"]
(Indonesia)
McMurdo [83502T,
Camp Area INTERNATIONAL-
CAMP_AREA_1987 30 WGS_1984 1987 Camp Area OBLATE_ELLIPSOID App. C.2,
(astronomic) _1924
(Antarctica) "CAZ"]
[83502T,
CAMPO_INCHAUSPE- Campo INTERNATIONAL-
31 WGS_1984 1969 Argentina OBLATE_ELLIPSOID App. B.7,
_1969 Inchauspe _1924
"CAI"]
[83502T,
Canton Phoenix INTERNATIONAL-
CANTON_1966 32 WGS_1984 1966 OBLATE_ELLIPSOID App. B.10,
(astronomic) Islands _1924
"CAO"]
374 © ISO/IEC 2009 – All rights reserved

ORM Published Reference Binding RD
ORM label Region ORMT label References
code name ORM information parameterization
[83502T,
CAPE_1987 33 Cape WGS_1984 1987 South Africa OBLATE_ELLIPSOID CLARKE_1880 App. B.2,
"CAP"]
[83502T,
Cape Bahamas and
App. B.6,
CAPE_CANAVERAL_1991 34 WGS_1984 1991 OBLATE_ELLIPSOID CLARKE_1866
Canaveral Florida
"CAC"]
[83502T,
CARTHAGE_1987 35 Carthage WGS_1984 1987 Tunisia OBLATE_ELLIPSOID CLARKE_1880 App. B.2,
"CGE"]
Chatham [83502T,
Chatam INTERNATIONAL-
CHATHAM_1971 37 WGS_1984 1971 Islands (New OBLATE_ELLIPSOID App. B.10,
(astronomic) _1924
Zealand) "CHI"]
[83502T,
Chua INTERNATIONAL-
CHUA_1987 38 WGS_1984 1987 Paraguay OBLATE_ELLIPSOID App. B.7,
(astronomic) _1924
"CHU"]
Coupled
Ocean/
[ERNWM,
Atmospheric
Table 1,
COAMPS_1998 39 Mesoscale WGS_1984 1998 Earth, Global SPHERE_ORIGIN COAMPS_1998
"COAMPS"
Prediction
]
System
TM
(COAMPS )
[83502T,
CORREGO_ALEGRE- Corrego INTERNATIONAL-
41 WGS_1984 1987 Brazil OBLATE_ELLIPSOID App. B.7,
_1987 Alegre _1924
"COA"]
© ISO/IEC 2009 – All rights reserved 375

ORM Published Reference Binding RD
ORM label Region ORMT label References
code name ORM information parameterization
[83502T,
DABOLA_1991 43 Dabola WGS_1984 1991 Guinea OBLATE_ELLIPSOID CLARKE_1880 App. B.2,
"DAL"]
Deception [83502T,
Island App. B.8,
DECEPTION_1993 44 Deception WGS_1984 1993 OBLATE_ELLIPSOID CLARKE_1880
(Antarctica) "DID"]
Djakarta [83502T,
Sumatra BESSEL_1841-
DJAKARTA_1987 49 (also known WGS_1984 1987 OBLATE_ELLIPSOID App. B.3,
(Indonesia) _ETHIOPIA
as Batavia) "BAT"]
Djakarta 1987
(also known The x-
as Batavia; positive xz-
[83502T,
DJAKARTA_1987_PM- Sumatra BESSEL_1841-
50 with the WGS_1984 half-plane OBLATE_ELLIPSOID App. B.3,
_DJAKARTA (Indonesia) _ETHIOPIA
Prime "BAT"]
contains
Meridian at Djarkata,
Djakarta) Indonesia.
Gizo Island [83502T,
INTERNATIONAL-
DOS_1968 51 DOS WGS_1984 1968 (New Georgia OBLATE_ELLIPSOID App. B.10,
_1924
Islands) "GIZ"]
DOS 71/4
[83502T,
St. Helena INTERNATIONAL-
(St. Helena
DOS_71_4_1987 52 WGS_1984 1987 OBLATE_ELLIPSOID App. B.8,
Island; Island _1924
"SHB"]
astronomic)
376 © ISO/IEC 2009 – All rights reserved

ORM Published Reference Binding RD
ORM label Region ORMT label References
code name ORM information parameterization
[83502T,
INTERNATIONAL-
EASTER_1967 60 Easter WGS_1984 1967 Easter Island OBLATE_ELLIPSOID App. B.10,
_1924
"EAS"]
[83502T,
BESSEL_1841-
App. B.5,
ESTONIA_1937 64 Estonia WGS_1984 1937 Estonia OBLATE_ELLIPSOID
_ETHIOPIA
"EST"]
European
Terrestrial OBLATE-
[HELM,
ETRS_1989 65 Reference WGS_1984 1989 Europe _ELLIPSOID- GRS_1980
"EUT"]
System _ORIGIN
(ETRS)
[83502T,
INTERNATIONAL-
EUROPE_1950 67 European WGS_1984 1950 Europe OBLATE_ELLIPSOID App. B.5,
_1924
"EUR"]
[83502T,
INTERNATIONAL-
EUROPE_1979 68 European WGS_1984 1979 Europe OBLATE_ELLIPSOID App. B.5,
_1924
"EUS"]
[83502T,
App. B.3,
FAHUD_1987 69 Fahud WGS_1984 1987 Oman OBLATE_ELLIPSOID CLARKE_1880
"FAH"]
St. Kitts,
[83502T,
Nevis and
FORT_THOMAS_1955 70 Fort Thomas WGS_1984 1955 OBLATE_ELLIPSOID CLARKE_1880 App. B.8,
Leeward
"FOT"]
Islands
© ISO/IEC 2009 – All rights reserved 377

ORM Published Reference Binding RD
ORM label Region ORMT label References
code name ORM information parameterization
[83502T,
Republic of INTERNATIONAL-
GAN_1970 72 Gan WGS_1984 1970 OBLATE_ELLIPSOID App. B.9,
Maldives _1924
"GAA"]
Geocentric
OBLATE-
Datum of [HELM,
GDA_1994 75 WGS_1984 1994 Australia _ELLIPSOID- GRS_1980
Australia "GDS"]
_ORIGIN
(GDA)
[83502T,
Geodetic INTERNATIONAL-
GEODETIC_DATUM_1949 76 WGS_1984 1949 New Zealand OBLATE_ELLIPSOID App. B.10,
Datum _1924
"GEO"]
Central
Azores (Faial,
Graciosa, [83502T,
GRACIOSA_BASE_SW- Graciosa INTERNATIONAL-
89 WGS_1984 1948 Pico, Sao OBLATE_ELLIPSOID App. B.8,
_1948 Base SW _1924
Jorge and "GRA"]
Terceira
Islands)
[83502T,
GUAM_1963 90 Guam WGS_1984 1963 Guam OBLATE_ELLIPSOID CLARKE_1866 App. B.10,
"GUA"]
Kalimantan [83502T,
Gunung BESSEL_1841-
GUNONG_SEGARA_1987 91 WGS_1984 1987 Island OBLATE_ELLIPSOID App. C.2,
Segara _ETHIOPIA
(Indonesia) "GSE"]
378 © ISO/IEC 2009 – All rights reserved

ORM Published Reference Binding RD
ORM label Region ORMT label References
code name ORM information parameterization
[83502T,
GUX1 Guadalcanal INTERNATIONAL-
GUX_1_1987 92 WGS_1984 1987 OBLATE_ELLIPSOID App. B.10,
(astronomic) Island _1924
"DOB"]
[83502T,
INTERNATIONAL-
App. C.2,
HERAT_NORTH_1987 98 Herat North WGS_1984 1987 Afghanistan OBLATE_ELLIPSOID
_1924
"HEN"]
Austria,
Yugoslavia
(prior to
1990), [83502T,
Hermann- BESSEL_1841-
HERMANNSKOGEL_1871 99 WGS_1984 1871 Slovenia, OBLATE_ELLIPSOID App. C.2,
skogel _ETHIOPIA
Croatia, "HER"]
Bosnia and
Herzegovina,
and Serbia
[83502T,
INTERNATIONAL-
HJORSEY_1955 100 Hjorsey WGS_1984 1955 Iceland OBLATE_ELLIPSOID App. B.5,
_1924
"HJO"]
[83502T,
INTERNATIONAL-
HONG_KONG_1963 101 Hong Kong WGS_1984 1963 Hong Kong OBLATE_ELLIPSOID App. B.3,
_1924
"HKD"]
[83502T,
INTERNATIONAL-
HU_TZU_SHAN_1991 102 Hu-Tzu-Shan WGS_1984 1991 Taiwan OBLATE_ELLIPSOID App. B.3,
_1924
"HTN"]
© ISO/IEC 2009 – All rights reserved 379

ORM Published Reference Binding RD
ORM label Region ORMT label References
code name ORM information parameterization
[83502T,
EVEREST_ADJ-
INDIAN_1916 105 Indian WGS_1984 1991 Bangladesh OBLATE_ELLIPSOID App. B.3,
_1937
"IND-B"]
[83502T,
EVEREST_ADJ-
App. B.3,
INDIAN_1954 106 Indian WGS_1984 1954 Thailand OBLATE_ELLIPSOID
_1937
"INF"]
[83502T,
India and
INDIAN_1956 107 Indian WGS_1984 1991 OBLATE_ELLIPSOID EVEREST_1956 App. B.3,
Nepal
"IND-I"]
[83502T,
EVEREST_ADJ-
INDIAN_1960 108 Indian WGS_1984 1960 Vietnam OBLATE_ELLIPSOID App. B.3,
_1937
"ING"]
[83502T,
EVEREST-
INDIAN_1962 109 Indian WGS_1984 1962 Pakistan OBLATE_ELLIPSOID App. C.2,
_REVISED_1962
"IND-P"]
[83502T,
EVEREST_ADJ-
INDIAN_1975 110 Indian WGS_1984 1975 Thailand OBLATE_ELLIPSOID App. B.3,
_1937
"INH"]
[83502T,
INDONESIAN-
INDONESIAN_1974 111 Indonesian WGS_1984 1974 Indonesia OBLATE_ELLIPSOID App. B.3,
_1974
"IDN"]
[83502T,
MODIFIED_AIRY-
IRELAND_1965 113 Ireland 1965 WGS_1984 1965 Ireland OBLATE_ELLIPSOID App. B.5,
_1849
"IRL"]
380 © ISO/IEC 2009 – All rights reserved

ORM Published Reference Binding RD
ORM label Region ORMT label References
code name ORM information parameterization
International
Satellite
South [83502T,
Triangulation INTERNATIONAL-
ISTS_061_1968 114 WGS_1984 1968 Georgia OBLATE_ELLIPSOID App. B.8,
Station _1924
Island "ISG"]
(ISTS) 061
(astronomic)
International
Satellite
[83502T,
Triangulation INTERNATIONAL-
ISTS_073_1969 115 WGS_1984 1969 Diego Garcia OBLATE_ELLIPSOID App. B.9,
Station _1924
"IST"]
(ISTS) 073
(astronomic)
Japanese
OBLATE-
Geodetic
JGD_2000 117 WGS_1984 2000 Japan _ELLIPSOID- GRS_1980 [GRFJ]
Datum 2000
_ORIGIN
(JGD2000)
[83502T,
Johnston INTERNATIONAL-
App. B.10,
JOHNSTON_1961 118 Johnston WGS_1984 1961 OBLATE_ELLIPSOID
Island _1924
"JOH"]
[83502T,
EVEREST_ADJ-
KANDAWALA_1987 127 Kandawala WGS_1984 1987 Sri Lanka OBLATE_ELLIPSOID App. B.3,
_1937
"KAN"]
[83502T,
Kerguelen INTERNATIONAL-
KERGUELEN_1949 128 Kerguelen WGS_1984 1949 OBLATE_ELLIPSOID App. B.9,
Island _1924
"KEG"]
© ISO/IEC 2009 – All rights reserved 381

ORM Published Reference Binding RD
ORM label Region ORMT label References
code name ORM information parameterization
West [83502T,
KERTAU_1948 129 Kertau WGS_1984 1948 Malaysia and OBLATE_ELLIPSOID EVEREST_1948 App. B.3,
Singapore "KEA"]
Korean [83502T,
KOREAN_GEODETIC-
Geodetic App. B.3,
130 WGS_1984 1995 South Korea OBLATE_ELLIPSOID WGS_1984
_1995
System "KGS"]
Caroline
Islands [83502T,
Kusaie 1951 INTERNATIONAL-
KUSAIE_1951 131 WGS_1984 1951 (Federated OBLATE_ELLIPSOID App. B.10,
(astronomic) _1924
States of "KUS"]
Micronesia)
[83502T,
LC5 Cayman Brac
LC5_1961 133 WGS_1984 1961 OBLATE_ELLIPSOID CLARKE_1866 App. B.8,
(astronomic) Island
"LCF"]
[83502T,
LEIGON_1991 134 Leigon WGS_1984 1991 Ghana OBLATE_ELLIPSOID CLARKE_1880 App. B.2,
"LEH"]
[83502T,
App. B.2,
LIBERIA_1964 135 Liberia WGS_1984 1964 Liberia OBLATE_ELLIPSOID CLARKE_1880
"LIB"]
[83502T,
LUZON_1987 136 Luzon WGS_1984 1987 Philippines OBLATE_ELLIPSOID CLARKE_1866 App. B.10,
"LUZ"]
382 © ISO/IEC 2009 – All rights reserved

ORM Published Reference Binding RD
ORM label Region ORMT label References
code name ORM information parameterization
[83502T,
M_PORALOKO_1991 137 M'Poraloko WGS_1984 1991 Gabon OBLATE_ELLIPSOID CLARKE_1880 App. B.2,
"MPO"]
[83502T,
Mahe Island
App. B.9,
MAHE_1971 138 Mahe WGS_1984 1971 OBLATE_ELLIPSOID CLARKE_1880
(Seychelles)
"MIK"]
Marcus [83502T,
Marcus INTERNATIONAL-
MARCUS_STATION_1952 139 Station WGS_1984 1952 OBLATE_ELLIPSOID App. B.10,
Islands _1924
(astronomic) "ASQ"]
[ERNWM,
MASS_1999 143 MASS WGS_1984 1999 Earth, Global SPHERE_ORIGIN MASS_1999 Table 1,
"MASS"]
[83502T,
Eritrea and BESSEL_1841-
MASSAWA_1987 144 Massawa WGS_1984 1987 OBLATE_ELLIPSOID App. B.2,
Ethiopia _ETHIOPIA
"MAS"]
[83502T,
MERCHICH_1987 145 Merchich WGS_1984 1987 Morocco OBLATE_ELLIPSOID CLARKE_1880 App. B.2,
"MER"]
[83502T,
Midway 1961 Midway INTERNATIONAL-
MIDWAY_1961 149 WGS_1984 1961 OBLATE_ELLIPSOID App. B.10,
(astronomic) Islands _1924
"MID"]
[83502T,
Cameroon
MINNA_1991 151 Minna WGS_1984 1991 OBLATE_ELLIPSOID CLARKE_1880 App. B.2,
and Nigeria
"MIN"]
© ISO/IEC 2009 – All rights reserved 383

ORM Published Reference Binding RD
ORM label Region ORMT label References
code name ORM information parameterization
Mesoscale
(weather)
Model [ERNWM,
5(MM5) Table 1,
MM5_1997 153 WGS_1984 1997 Earth, Global SPHERE_ORIGIN MM5_1997
Air Force "MM5
Weather (AFWA)"]
Agency
(AFWA) US
[ERNWM,
Table 1,
Earth northern MODTRAN-
MODTRAN- "MODTRA
154 MODTRAN WGS_1984 1989 midlatitude SPHERE_ORIGIN _MIDLATITUDE-
_MIDLATITUDE_N_1989 N,
regions _1989
Midlatitude
"]
[ERNWM,
Earth Table 1,
MODTRAN-
MODTRAN- southern "MODTRA
155 MODTRAN WGS_1984 1989 SPHERE_ORIGIN _MIDLATITUDE-
_MIDLATITUDE_S_1989 midlatitude N,
_1989
regions Midlatitude
"]
[ERNWM,
Earth northern MODTRAN- Table 1,
MODTRAN_SUBARCTIC-
156 MODTRAN WGS_1984 1989 subarctic SPHERE_ORIGIN _SUBARCTIC- "MODTRA
_N_1989
regions _1989 N,
Subarctic"]
384 © ISO/IEC 2009 – All rights reserved

ORM Published Reference Binding RD
ORM label Region ORMT label References
code name ORM information parameterization
[ERNWM,
Earth
MODTRAN- Table 1,
MODTRAN_SUBARCTIC- southern
157 MODTRAN WGS_1984 1989 SPHERE_ORIGIN _SUBARCTIC- "MODTRA
_S_1989 subarctic
_1989 N,
regions
Subarctic"]
[ERNWM,
Table 1,
MODTRAN_TROPICAL- Earth tropical MODTRAN-
158 MODTRAN WGS_1984 1989 SPHERE_ORIGIN "MODTRA
_1989 regions _TROPICAL_1989
N,
Tropical"]
Montserrat [83502T,
Montserrat
MONTSERRAT_1958 159 WGS_1984 1958 and Leeward OBLATE_ELLIPSOID CLARKE_1880 App. B.8,
(astronomic)
Islands "ASM"]
MULTIGEN_FLAT- Multigen flat MULTIGEN_FLAT-
161 WGS_1984 1989 Earth, Global SPHERE_ORIGIN [MFCG]
_EARTH_1989 Earth _EARTH_1989
[83502T,
North
N_AM_1927 162 WGS_1984 1927 North America OBLATE_ELLIPSOID CLARKE_1866 App. B.6,
American
"NAS"]
[83502T,
North App. B.6,
N_AM_1983 163 WGS_1984 1983 North America OBLATE_ELLIPSOID GRS_1980
American "NAR"],
[NAD83]
[83502T,
N_SAHARA_1959 164 North Sahara WGS_1984 1959 Algeria OBLATE_ELLIPSOID CLARKE_1880 App. B.2,
"NSD"]
© ISO/IEC 2009 – All rights reserved 385

ORM Published Reference Binding RD
ORM label Region ORMT label References
code name ORM information parameterization
Oman, Saudi
[83502T,
Arabia, and
NAHRWAN_1987 165 Nahrwan WGS_1984 1987 OBLATE_ELLIPSOID CLARKE_1880 App. B.3,
the United
"NAH"]
Arab Emirates
Trinidad and
[83502T,
Naparima Tobago INTERNATIONAL-
NAPARIMA_1991 167 WGS_1984 1991 OBLATE_ELLIPSOID App. B.8,
BWI (British West _1924
"NAP"]
Indies)
Navy
Operational
Global [ERNWM,
Atmospheric Table 1,
NOGAPS_1988 171 WGS_1984 1988 Earth, Global SPHERE_ORIGIN NOGAPS_1988
Prediction "NOGAPS"
System ]
(NOGAPS),
US
CLARKE_1880- [HELM,
NTF_1896 172 NTF WGS_1984 1896 France OBLATE_ELLIPSOID
_IGN "NFR"]
The x-
positive xz-
NTF (with the half-plane
Prime contains CLARKE_1880- [HELM,
NTF_1896_PM_PARIS 173 WGS_1984 France OBLATE_ELLIPSOID
Meridian at Paris, _IGN "NFR"]
Paris) France (IGN
determina-
tion).
386 © ISO/IEC 2009 – All rights reserved

ORM Published Reference Binding RD
ORM label Region ORMT label References
code name ORM information parameterization
Observatorio Corvo Flores [83502T,
OBSERV_METEORO- INTERNATIONAL-
175 Meteoro- WGS_1984 1939 Islands OBLATE_ELLIPSOID App. B.8,
_1939 _1924
logico (Azores) "FLO"]
[83502T,
App. B.2,
OLD_EGYPTIAN_1907 176 Old Egyptian WGS_1984 1907 Egypt OBLATE_ELLIPSOID HELMERT_1906
"OEG"]
[83502T,
OLD_HAWAIIAN- Old Hawaiian Hawaiian
177 WGS_1984 1987 OBLATE_ELLIPSOID CLARKE_1866 App. B.10,
_CLARKE_1987 (Clarke) Islands
"OHA"]
Old Hawaiian [83502T,
OLD_HAWAIIAN_INT- Hawaiian INTERNATIONAL-
178 (International WGS_1984 1987 OBLATE_ELLIPSOID App. B.10,
_1987 Islands _1924
) "OHI"]
Ordnance [83502T,
OSGB_1936 180 Survey of WGS_1984 1936 Great Britain OBLATE_ELLIPSOID AIRY_1830 App. B.5,
Great Britain "OGB"]
Canary [83502T,
PICO_DE_LAS_NIEVES- Pico de las INTERNATIONAL-
185 WGS_1984 1987 Islands OBLATE_ELLIPSOID App. B.8,
_1987 Nieves _1924
(Spain) "PLN"]
[83502T,
Pitcairn INTERNATIONAL-
PITCAIRN_1967 186 WGS_1984 1967 Pitcairn Island OBLATE_ELLIPSOID App. B.10,
(astronomic) _1924
"PIT"]
[83502T,
Burkina Faso
POINT_58_1991 189 Point 58 WGS_1984 1991 OBLATE_ELLIPSOID CLARKE_1880 App. B.2,
and Niger
"PTB"]
© ISO/IEC 2009 – All rights reserved 387

ORM Published Reference Binding RD
ORM label Region ORMT label References
code name ORM information parameterization
[83502T,
POINTE_NOIRE_1948 190 Pointe Noire WGS_1984 1948 Congo OBLATE_ELLIPSOID CLARKE_1880 App. B.2,
"PTN"]
Porto Santo [83502T,
INTERNATIONAL-
and Madeira App. B.8,
PORTO_SANTO_1936 192 Porto Santo WGS_1984 1936 OBLATE_ELLIPSOID
_1924
Islands "POS"]
Provisional [83502T,
South INTERNATIONAL-
PROV_S_AM_1956 195 South WGS_1984 1956 OBLATE_ELLIPSOID App. B.7,
America _1924
American "PRP"]
Provisional
[83502T,
South INTERNATIONAL-
PROV_S_CHILEAN_1963 196 WGS_1984 1963 South Chile OBLATE_ELLIPSOID App. B.7,
Chilean (Hito _1924
"HIT"]
XVIII)
Puerto Rico [83502T,
PUERTO_RICO_1987 198 Puerto Rico WGS_1984 1987 and Virgin OBLATE_ELLIPSOID CLARKE_1866 App. B.8,
Islands "PUR"]
Eastern [83502T,
KRASSOVSKY-
PULKOVO_1942 199 Pulkovo WGS_1984 1942 Europe and OBLATE_ELLIPSOID App. C.2,
_1940
Russia "PUK"]
[83502T,
Qatar INTERNATIONAL-
QATAR_NATIONAL_1974 200 WGS_1984 1974 Qatar OBLATE_ELLIPSOID App. B.3,
National _1924
"QAT"]
388 © ISO/IEC 2009 – All rights reserved

ORM Published Reference Binding RD
ORM label Region ORMT label References
code name ORM information parameterization
[83502T,
South INTERNATIONAL-
QORNOQ_1987 201 Qornoq WGS_1984 1987 OBLATE_ELLIPSOID App. B.8,
Greenland _1924
"QUO"]
[83502T,
Mascarene INTERNATIONAL-
App. B.9,
REUNION_1947 202 Reunion WGS_1984 1947 OBLATE_ELLIPSOID
Islands _1924
"REU"]
Reseau
RGF_1993 203 Geodesique WGS_1984 1993 France OBLATE_ELLIPSOID GRS_1980 [RGF]
Francais
Rome (also [83502T,
INTERNATIONAL-
ROME_1940 205 known as WGS_1984 1940 Sardinia OBLATE_ELLIPSOID App. B.5,
_1924
Monte Mario) "MOD"]
Rome (also
known as
The x-
Monte Mario) [83502T,
positive xz- INTERNATIONAL-
ROME_1940_PM_ROME 206 (with the WGS_1984 Sardinia OBLATE_ELLIPSOID App. B.5,
half-plane _1924
Prime "MOD"]
contains
Meridian at
Rome, Italy.
Rome)
SOUTH- [83502T,
South South
S_AM_1969 208 WGS_1984 1969 OBLATE_ELLIPSOID _AMERICAN- App. B.7,
American America
_1969 "SAN"]
[83502T,
MODIFIED-
S_ASIA_1987 209 South Asia WGS_1984 1987 Singapore OBLATE_ELLIPSOID App. B.3,
_FISCHER_1960
"SOA"]
© ISO/IEC 2009 – All rights reserved 389

ORM Published Reference Binding RD
ORM label Region ORMT label References
code name ORM information parameterization
System -
Jednotne
Trigonometric
Czech [83502T,
ke Siti BESSEL_1841-
Republic and App. B.5,
S_JTSK_1993 210 WGS_1984 1993 OBLATE_ELLIPSOID
Katastralni _ETHIOPIA
Slovakia "CCD"]
(S-JTSK)
(Czechoslova
kia)
[HELM,
S-42 Eastern KRASSOVSKY- "SPK",
S42_PULKOVO 211 WGS_1984 1942 OBLATE_ELLIPSOID
(Pulkovo) Europe _1940 "Afghanista
n"]
Espirito Santo [83502T,
INTERNATIONAL-
SANTO_DOS_1965 212 Santo (DOS) WGS_1984 1965 Island OBLATE_ELLIPSOID App. B.10,
_1924
(Vanuatu) "SAE"]
Sao Miguel
[83502T,
and Santa INTERNATIONAL-
SAO_BRAZ_1987 213 Sao Braz WGS_1984 1987 OBLATE_ELLIPSOID App. B.8,
Maria Islands _1924
"SAO"]
(Azores)
[83502T,
East Falkland INTERNATIONAL-
SAPPER_HILL_1943 214 Sapper Hill WGS_1984 1943 OBLATE_ELLIPSOID App. B.8,
Islands _1924
"SAP"]
[83502T,
BESSEL_1841-
SCHWARZECK_1991 218 Schwarzeck WGS_1984 1991 Namibia OBLATE_ELLIPSOID App. B.2,
_NAMIBIA
"SCK"]
390 © ISO/IEC 2009 – All rights reserved

ORM Published Reference Binding RD
ORM label Region ORMT label References
code name ORM information parameterization
Salvage
Islands (Ilhas [83502T,
SELVAGEM_GRANDE- Selvagem INTERNATIONAL-
219 WGS_1984 1938 Selvagens; OBLATE_ELLIPSOID App. B.8,
_1938 Grande _1924
Savage "SGM"]
Islands)
[83502T,
SIERRA_LEONE_1960 220 Sierra Leone WGS_1984 1960 Sierra Leone OBLATE_ELLIPSOID CLARKE_1880 App. B.2,
"SRL"]
Sistema de
Referencia
OBLATE- [83502T,
Geocentrico South
SIRGAS_2000 221 WGS_1984 2000 _ELLIPSOID- GRS_1980 App. B.7,
para America America
_ORIGIN "SIR"]
del Sur
(SIRGAS)
[83502T,
Tananarive INTERNATIONAL-
TANANARIVE_OBS_1925 223 WGS_1984 1925 Madagascar OBLATE_ELLIPSOID App. C.2,
Observatory _1924
"TAN"]
The x-
Tananarive positive xz-
Observatory half-plane
[83502T,
TANANARIVE_OBS- (with the contains INTERNATIONAL-
224 WGS_1984 Madagascar OBLATE_ELLIPSOID App. C.2,
_1925_PM_PARIS Prime Paris, _1924
"TAN"]
Meridian at France
Paris) (IGN 1936
determina-
tion).
© ISO/IEC 2009 – All rights reserved 391

ORM Published Reference Binding RD
ORM label Region ORMT label References
code name ORM information parameterization
Tern Island
(French
[83502T,
Tern Frigate INTERNATIONAL-
TERN_1961 226 WGS_1984 1961 OBLATE_ELLIPSOID App. B.10,
(astronomic) Shoals, _1924
"TRN"]
Hawaiian
Islands)
Brunei and
[83502T,
TIMBALAI_EVEREST- Timbali East Malaysia EVEREST-
230 WGS_1984 1948 OBLATE_ELLIPSOID App. B.3,
_1948 (Everest) (Sabah and _BRUNEI_1967
"TIL"]
Sarawak)
Japan, South [83502T,
BESSEL_1841-
TOKYO_1991 233 Tokyo WGS_1984 1991 Korea, and OBLATE_ELLIPSOID App. B.3,
_ETHIOPIA
Okinawa "TOY"]
[83502T,
Tristan Tristan da INTERNATIONAL-
TRISTAN_1968 234 WGS_1984 1968 OBLATE_ELLIPSOID App. B.8,
(astronomic) Cunha _1924
"TDC"]
Viti Levu [83502T,
VITI_LEVU_1916 242 Viti Levu WGS_1984 1916 Island (Fiji OBLATE_ELLIPSOID CLARKE_1880 App. B.10,
Islands) "MVS"]
[83502T,
VOIROL_1874 243 Voirol WGS_1984 1874 Algeria OBLATE_ELLIPSOID CLARKE_1880 App. C.2,
"VOI"]
392 © ISO/IEC 2009 – All rights reserved

ORM Published Reference Binding RD
ORM label Region ORMT label References
code name ORM information parameterization
The x-
positive xz-
Voirol (with half-plane
[83502T,
VOIROL_1874_PM- the Prime contains
244 WGS_1984 Algeria OBLATE_ELLIPSOID CLARKE_1880 App. C.2,
_PARIS Meridian at Paris,
"VOI"]
Paris) France
(IGN 1936
determina-
tion).
[83502T,
Voirol -
VOIROL_1960 245 WGS_1984 1960 Algeria OBLATE_ELLIPSOID CLARKE_1880 App. B.2,
Revised
"VOR"]
The x-
positive xz-
Voirol -
half-plane
Revised (with [83502T,
VOIROL_1960_PM- contains
246 the Prime WGS_1984 Algeria OBLATE_ELLIPSOID CLARKE_1880 App. B.2,
_PARIS Paris,
"VOR"]
Meridian at
France
Paris)
(IGN 1936
determina-
tion).
[83502T,
Wake INTERNATIONAL-
WAKE_1952 247 WGS_1984 1952 Wake Atoll OBLATE_ELLIPSOID App. B.10,
(astronomic) _1924
"WAK"]
© ISO/IEC 2009 – All rights reserved 393

ORM Published Reference Binding RD
ORM label Region ORMT label References
code name ORM information parameterization
[83502T,
Wake- Marshall
WAKE_ENIWETOK_1960 248 WGS_1984 1960 OBLATE_ELLIPSOID HOUGH_1960 App. B.10,
Eniwetok Islands
"ENW"]
World OBLATE-
Geodetic _ELLIPSOID-
WGS_1972 249 WGS_1984 1972 Earth, Global WGS_1972 [WGS72]
System _ORIGIN
Note: The
This is the x-positive
World OBLATE-
reference xz-half-
WGS_1984 250 Geodetic Earth, Global _ELLIPSOID- WGS_1984 [83502T]
ORM for plane
System _ORIGIN
Earth. contains
Greenwich,
UK.
[83502T,
Yacare INTERNATIONAL-
App. C.2,
YACARE_1987 251 WGS_1984 1987 Uruguay OBLATE_ELLIPSOID
(Uruguay) _1924
"YAC"]
[83502T,
Zanderij INTERNATIONAL-
ZANDERIJ_1987 252 WGS_1984 1987 Suriname OBLATE_ELLIPSOID App. B.7,
(Suriname) _1924
"ZAN"]
NOTE 1:   In Table E.6, when [83502T] and [GEOTRAN] both appear in the References element of an RT specification, [GEOTRAN] is the reference for the latitude and longitude values
in the RT region element. The reference for all other elements of such an RT specification, including the region name(s) in the RT region element, is [83502T].  For non-Greenwich prime
meridian RT specifications, the RT region longitude values are offset by ω , when applicable.
NOTE 2:   For non-Greenwich prime meridian RT specifications in Table E.6, the RT parameters value, ω , is specified by this International Standard.
394 © ISO/IEC 2009 – All rights reserved

Table E.6 — Object-fixed ERM reference transformation specifications
Date
RT
ORM label RT label RT region RT parameters publish- References
code
ed
ADINDAN_1991 [83502T,
Burkina Faso; Δx = {ΔX(m)}, Δy = {ΔY(m)}, Δz = App. B.2,
ADINDAN_1991_BURKINA_FASO 3 +4º ≤ φ ≤ +22º; {ΔZ(m)}, ω = ω = ω = 0″ : precise, Δs 1991 "ADI-E"],
1 2 3
-12º ≤ λ ≤ +8º = 0 : precise [GEOTRAN
, "ADI-E"]
[83502T,
Cameroon; Δx = {ΔX(m)}, Δy = {ΔY(m)}, Δz = App. B.2,
ADINDAN_1991_CAMEROON 4 -4º ≤ φ ≤ +19º; {ΔZ(m)}, ω = ω = ω = 0″ : precise, Δs 1991 "ADI-F"],
1 2 3
+3º ≤ λ ≤ +23º = 0 : precise [GEOTRAN
, "ADI-F"]
[83502T,
Ethiopia; App. B.2,
Δx = -165, Δy = -11, Δz = 206, ω = ω =
1 2
ADINDAN_1991_ETHIOPIA 5 -3º ≤ φ ≤ +25º; 1991 "ADI-A"],
ω = 0″, Δs = 0.
+26º ≤ λ ≤ +50º [GEOTRAN
, "ADI-A"]
[83502T,
Δx = {ΔX(m)}, Δy = {ΔY(m)}, Δz =
Mali; App. B.2,
ADINDAN_1991_MALI 6 +3º ≤ φ ≤ +31º; {ΔZ(m)}, ω = ω = ω = 0″ : precise, Δs 1991 "ADI-C"],
1 2 3
-20º ≤ λ ≤ +11º = 0 : precise [GEOTRAN
, "ADI-C"]
© ISO/IEC 2009 – All rights reserved 395

Date
RT
ORM label RT label RT region RT parameters publish- References
code
ed
Mean Solution [83502T,
(Ethiopia and App. B.2,
Δx = -166, Δy = -15, Δz = 204, ω = ω =
1 2
ADINDAN_1991_MEAN_SOLUTION 7 Sudan); 1991 "ADI-M"],
ω = 0″, Δs = 0.
-5º ≤ φ ≤ +31º; [GEOTRAN
+15º ≤ λ ≤ +55º , "ADI-M"]
[83502T,
Senegal; Δx = {ΔX(m)}, Δy = {ΔY(m)}, Δz = App. B.2,
ADINDAN_1991_SENEGAL 8 +5º ≤ φ ≤ +23º; {ΔZ(m)}, ω = ω = ω = 0″ : precise, Δs 1991
"ADI-D"],
1 2 3
-24º ≤ λ ≤ -5º = 0 : precise [GEOTRAN
, "ADI-D"]
[83502T,
Sudan; App. B.2,
Δx = -161, Δy = -14, Δz = 205, ω = ω =
1 2
ADINDAN_1991_SUDAN 9 -3º ≤ φ ≤ +31º; 1991 "ADI-B"],
ω = 0″, Δs = 0.
+15º ≤ λ ≤ +45º [GEOTRAN
, "ADI-B"]
AFGOOYE_1987 [83502T,
Somalia; Δx = {ΔX(m)}, Δy = {ΔY(m)}, Δz =
App. B.2,
AFGOOYE_1987_SOMALIA 11 -8º ≤ φ ≤ +19º; {ΔZ(m)}, ω = ω = ω = 0″ : precise, Δs 1987 "AFG"],
1 2 3
+35º ≤ λ ≤ +60º
= 0 : precise [GEOTRAN
, "AFG"]
396 © ISO/IEC 2009 – All rights reserved

Date
RT
ORM label RT label RT region RT parameters publish- References
code
ed
AIN_EL_ABD_1970 [83502T,
Bahrain Island; Δx = {ΔX(m)}, Δy = {ΔY(m)}, Δz = App. B.3,
AIN_EL_ABD_1970_BAHRAIN_ISLAND 12 +24º ≤ φ ≤ +28º; {ΔZ(m)}, ω = ω = ω = 0″ : precise, Δs 1970 "AIN-A"],
1 2 3
+49º ≤ λ ≤ +53º = 0 : precise [GEOTRAN
, "AIN-A"]
[83502T,
Saudi Arabia; App. B.3,
Δx = -143, Δy = -236, Δz = 7, ω = ω =
1 2
AIN_EL_ABD_1970_SAUDI_ARABIA 13 +8º ≤ φ ≤ +38º; 1970 "AIN-B"],
ω = 0″, Δs = 0.
+28º ≤ λ ≤ +62º [GEOTRAN
, "AIN-B"]
AMERICAN_SAMOA- [83502T,
American
_1962 Δx = {ΔX(m)}, Δy = {ΔY(m)}, Δz = App. B.10,
AMERICAN_SAMOA_1962_AMERICAN- Samoa Islands;
15 {ΔZ(m)}, ω = ω = ω = 0″ : precise, Δs 1962 "AMA"],
1 2 3
_SAMOA_ISLANDS -19º ≤ φ ≤ -9º;
= 0 : precise [GEOTRAN
-174º ≤ λ ≤ -165º
, "AMA"]
ANNA_1_1965 [83502T,
Cocos Islands; Δx = {ΔX(m)}, Δy = {ΔY(m)}, Δz = App. B.9,
ANNA_1_1965_COCOS_ISLANDS 16 -14º ≤ φ ≤ -10º; {ΔZ(m)}, ω = ω = ω = 0″ : precise, Δs 1965 "ANO"],
1 2 3
+94º ≤ λ ≤ +99º
= 0 : precise [GEOTRAN
, "ANO"]
© ISO/IEC 2009 – All rights reserved 397

Date
RT
ORM label RT label RT region RT parameters publish- References
code
ed
ANTIGUA_1943 Antigua and [83502T,
Leeward Δx = {ΔX(m)}, Δy = {ΔY(m)}, Δz = App. B.8,
ANTIGUA_1943_ANTIGUA_LEEWARD-
17 Islands; {ΔZ(m)}, ω = ω = ω = 0″ : precise, Δs 1943 "AIA"],
1 2 3
_ISLANDS
+16º ≤ φ ≤ +20º; = 0 : precise [GEOTRAN
-65º ≤ λ ≤ -61º , "AIA"]
ARC_1950 [83502T,
Zimbabwe; App. B.2,
Δx = -142, Δy = -96, Δz = -293, ω = ω
1 2
ARC_1950_3_ZIMBABWE 18 -29º ≤ φ ≤ -9º; 1950
"ARF-G"],
= ω = 0″, Δs = 0.
+19º ≤ λ ≤ +39º [GEOTRAN
, "ARF-G"]
[83502T,
Botswana; App. B.2,
Δx = -138, Δy = -105, Δz = -289, ω = ω
1 2
ARC_1950_BOTSWANA 19 -33º ≤ φ ≤ -13º; 1950 "ARF-A"],
= ω = 0″, Δs = 0.
+13º ≤ λ ≤ +36º [GEOTRAN
, "ARF-A"]
[83502T,
Burundi; Δx = {ΔX(m)}, Δy = {ΔY(m)}, Δz =
App. B.2,
ARC_1950_BURUNDI 20 -11º ≤ φ ≤ +4º; {ΔZ(m)}, ω = ω = ω = 0″ : precise, Δs 1950 "ARF-H"],
1 2 3
+21º ≤ λ ≤ +37º
= 0 : precise [GEOTRAN
, "ARF-H"]
398 © ISO/IEC 2009 – All rights reserved

Date
RT
ORM label RT label RT region RT parameters publish- References
code
ed
[83502T,
Lesotho; Δx = {ΔX(m)}, Δy = {ΔY(m)}, Δz = App. B.2,
ARC_1950_LESOTHO 21 -36º ≤ φ ≤ -23º; {ΔZ(m)}, ω = ω = ω = 0″ : precise, Δs 1950 "ARF-B"],
1 2 3
+21º ≤ λ ≤ +35º = 0 : precise [GEOTRAN
, "ARF-B"]
[83502T,
Malawi; App. B.2,
Δx = -161, Δy = -73, Δz = -317, ω = ω
1 2
ARC_1950_MALAWI 22 -21º ≤ φ ≤ -3º; 1950 "ARF-C"],
= ω = 0″, Δs = 0.
+26º ≤ λ ≤ +42º [GEOTRAN
, "ARF-C"]
Mean Solution
(Botswana,
Lesotho, [83502T,
Malawi, App. B.2,
Δx = -143, Δy = -90, Δz = -294, ω = ω
1 2
ARC_1950_MEAN_SOLUTION 23 Swaziland, 1950 "ARF-M"],
= ω = 0″, Δs = 0.
Zaire, Zambia [GEOTRAN
and Zimbabwe); , "ARF-M"]
-36º ≤ φ ≤ +10º;
+4º ≤ λ ≤ +42º
[83502T,
Swaziland; Δx = {ΔX(m)}, Δy = {ΔY(m)}, Δz =
App. B.2,
ARC_1950_SWAZILAND 24 -33º ≤ φ ≤ -20º; {ΔZ(m)}, ω = ω = ω = 0″ : precise, Δs 1950 "ARF-D"],
1 2 3
+25º ≤ λ ≤ +40º
= 0 : precise [GEOTRAN
, "ARF-D"]
© ISO/IEC 2009 – All rights reserved 399

Date
RT
ORM label RT label RT region RT parameters publish- References
code
ed
[83502T,
Zaire; Δx = {ΔX(m)}, Δy = {ΔY(m)}, Δz = App. B.2,
ARC_1950_ZAIRE 25 -21º ≤ φ ≤ +10º; {ΔZ(m)}, ω = ω = ω = 0″ : precise, Δs 1950 "ARF-E"],
1 2 3
+4º ≤ λ ≤ +38º = 0 : precise [GEOTRAN
, "ARF-E"]
[83502T,
Zambia; Δx = {ΔX(m)}, Δy = {ΔY(m)}, Δz = App. B.2,
ARC_1950_ZAMBIA 26 -24º ≤ φ ≤ -1º; {ΔZ(m)}, ω = ω = ω = 0″ : precise, Δs 1950 "ARF-F"],
1 2 3
+15º ≤ λ ≤ +40º = 0 : precise [GEOTRAN
, "ARF-F"]
ARC_1960 [83502T,
Kenya; App. B.2,
Δx = -157, Δy = -2, Δz = -299, ω = ω =
1 2
-11º ≤ φ ≤ +8º;
ARC_1960_3_KENYA 27 1960 "ARS-A"],
ω = 0″, Δs = 0.
+28º ≤ λ ≤ +47º [GEOTRAN
, "ARS-A"]
Mean Solution [83502T,
(Kenya and Δx = {ΔX(m)}, Δy = {ΔY(m)}, Δz = App. B.2,
ARC_1960_MEAN_SOLUTION 28 Tanzania); {ΔZ(m)}, ω = ω = ω = 0″ : precise, Δs 1960 "ARS-M"],
1 2 3
-18º ≤ φ ≤ +8º;
= 0 : precise [GEOTRAN
+23º ≤ λ ≤ +47º , "ARS-M"]
400 © ISO/IEC 2009 – All rights reserved

Date
RT
ORM label RT label RT region RT parameters publish- References
code
ed
[83502T,
Tanzania; App. B.2,
Δx = -175, Δy = -23, Δz = -303, ω = ω
1 2
ARC_1960_TANZANIA 29 -18º ≤ φ ≤ +5º; 1960 "ARS-B"],
= ω = 0″, Δs = 0.
+23º ≤ λ ≤ +47º [GEOTRAN
, "ARS-B"]
ASCENSION_1958 [83502T,
Ascension
Δx = {ΔX(m)}, Δy = {ΔY(m)}, Δz = App. B.8,
Island;
ASCENSION_1958_ASCENSION_ISLAND 31 {ΔZ(m)}, ω = ω = ω = 0″ : precise, Δs 1958 "ASC"],
1 2 3
-9º ≤ φ ≤ -6º;
= 0 : precise [GEOTRAN
-16º ≤ λ ≤ -13º
, "ASC"]
AUSTRALIAN_GEOD- Australia and [83502T,
_1966 Tasmania; App. B.4,
AUSTRALIAN_GEOD_1966_AUSTRALIA- Δx = -133, Δy = -48, Δz = 148, ω = ω =
1 2
33 -46º ≤ φ ≤ -4º; 1966 "AUA"],
_TASMANIA ω = 0″, Δs = 0.
+109º ≤ λ ≤ [GEOTRAN
+161º , "AUA"]
AUSTRALIAN_GEOD- Australia and [83502T,
_1984 Tasmania; App. B.4,
AUSTRALIAN_GEOD_1984_3_AUSTRALIA- Δx = -134, Δy = -48, Δz = 149, ω = ω =
1 2
34 -46º ≤ φ ≤ -4º; 1984 "AUG"],
_TASMANIA ω = 0″, Δs = 0.
+109º ≤ λ ≤ [GEOTRAN
+161º , "AUG"]
© ISO/IEC 2009 – All rights reserved 401

Date
RT
ORM label RT label RT region RT parameters publish- References
code
ed
Australia and
Tasmania; Δx = -116, Δy = -50,47, Δz = 141,69, ω
AUSTRALIAN_GEOD_1984_7_AUSTRALIA- [CECT,
35 -46º ≤ φ ≤ -4º; = 0,23″, ω = 0,39″, ω = 0,344″, Δs = 1984
2 3
_TASMANIA Table 1]
-6
+109º ≤ λ ≤ 0,098 3 x 10 .
+161º
AYABELLE- [83502T,
_LIGHTHOUSE_1991 Djibouti; Δx = {ΔX(m)}, Δy = {ΔY(m)}, Δz = App. B.2,
AYABELLE_LIGHTHOUSE_1991_DJIBOUTI 36 +5º ≤ φ ≤ +20º; {ΔZ(m)}, ω = ω = ω = 0″ : precise, Δs 1991
"PHA"],
1 2 3
+36º ≤ λ ≤ +49º = 0 : precise [GEOTRAN
, "PHA"]
BEACON_E_1945 [83502T,
Iwo Jima Island;
Δx = {ΔX(m)}, Δy = {ΔY(m)}, Δz = App. B.10,
+22º ≤ φ ≤ +26º;
BEACON_E_1945_IWO_JIMA_ISLAND 37 {ΔZ(m)}, ω = ω = ω = 0″ : precise, Δs 1945 "ATF"],
1 2 3
+140º ≤ λ ≤
= 0 : precise [GEOTRAN
+144º
, "ATF"]
BELLEVUE_IGN_1987 Efate and
Erromango [83502T,
Islands Δx = {ΔX(m)}, Δy = {ΔY(m)}, Δz = App. B.10,
BELLEVUE_IGN_1987_EFATE-
{ΔZ(m)}, ω = ω = ω = 0″ : precise, Δs
39 (Vanuatu); 1987 "IBE"],
1 2 3
_ERROMANGO_ISLANDS
-20º ≤ φ ≤ -16º; = 0 : precise [GEOTRAN
+167º ≤ λ ≤
, "IBE"]
+171º
402 © ISO/IEC 2009 – All rights reserved

Date
RT
ORM label RT label RT region RT parameters publish- References
code
ed
BERMUDA_1957 [83502T,
Bermuda; Δx = {ΔX(m)}, Δy = {ΔY(m)}, Δz = App. B.8,
BERMUDA_1957_BERMUDA 40 +31º ≤ φ ≤ +34º; {ΔZ(m)}, ω = ω = ω = 0″ : precise, Δs 1957 "BER"],
1 2 3
-66º ≤ λ ≤ -63º = 0 : precise [GEOTRAN
, "BER"]
BISSAU_1991 [83502T,
Guinea-Bissau; Δx = {ΔX(m)}, Δy = {ΔY(m)}, Δz = App. B.2,
BISSAU_1991_GUINEA_BISSAU 42 +5º ≤ φ ≤ +19º; {ΔZ(m)}, ω = ω = ω = 0″ : precise, Δs 1991 "BID"],
1 2 3
-23º ≤ λ ≤ -7º = 0 : precise [GEOTRAN
, "BID"]
BOGOTA_OBS_1987 [83502T,
Colombia; Δx = {ΔX(m)}, Δy = {ΔY(m)}, Δz = App. B.7,
-10º ≤ φ ≤ +16º;
BOGOTA_OBS_1987_COLOMBIA 43 {ΔZ(m)}, ω = ω = ω = 0″ : precise, Δs 1987 "BOO"],
1 2 3
-85º ≤ λ ≤ -61º = 0 : precise [GEOTRAN
, "BOO"]
BOGOTA_OBS_1987_PM- Δx = 307, Δy = 304, Δz = -318, ω = 0″, [83502T,
_BOGOTA Colombia; ω = 0″, ω = -74º 4′ 51,3″, Δs = 0. App. B.7,
2 3
BOGOTA_OBS_1987_PM_BOGOTA-
44 -10º ≤ φ ≤ +16º; Note: The referenced z-axis rotation 1987 "BOO"],
_COLOMBIA
-11º ≤ λ ≤ +13º
has been offset so that Bogota is [GEOTRAN
contained in the x-positive xz-plane. , "BOO"]
© ISO/IEC 2009 – All rights reserved 403

Date
RT
ORM label RT label RT region RT parameters publish- References
code
ed
BUKIT_RIMPAH_1987 Bangka and
[83502T,
Belitung Islands
Δx = {ΔX(m)}, Δy = {ΔY(m)}, Δz =
App. C.2,
BUKIT_RIMPAH_1987_BANGKA- (Indonesia);
45 {ΔZ(m)}, ω = ω = ω = 0″ : precise, Δs 1987 "BUR"],
1 2 3
_BELITUNG_ISLANDS -6º ≤ φ ≤ +0º;
[GEOTRAN
= 0 : precise
+103º ≤ λ ≤
, "BUR"]
+110º
CAMP_AREA_1987 McMurdo Camp
[83502T,
Area
Δx = {ΔX(m)}, Δy = {ΔY(m)}, Δz = App. C.2,
(Antarctica);
CAMP_AREA_1987_MCMURDO_CAMP 48 {ΔZ(m)}, ω = ω = ω = 0″ : precise, Δs 1987 "CAZ"],
1 2 3
-85º ≤ φ ≤ -70º;
= 0 : precise [GEOTRAN
+135º ≤ λ ≤
, "CAZ"]
+180º
CAMPO_INCHAUSPE- [83502T,
_1969 Argentina; App. B.7,
Δx = -148, Δy = 136, Δz = 90, ω = ω =
1 2
CAMPO_INCHAUSPE_1969_ARGENTINA 49 -62º ≤ φ ≤ -20º; 1969 "CAI"],
ω = 0″, Δs = 0.
-76º ≤ λ ≤ -47º [GEOTRAN
, "CAI"]
CANTON_
...

Annex F
(normative)
Abbreviations and acronyms used in the construction of labels
F.1 Introduction
For each SRM concept, the corresponding Table F.1 through Table F.9 lists words and their abbreviations, as
well as phrases and their acronyms, to be used for constructing labels. In these tables the notation "[nnn]"
where nnn represents one or more letters or numbers means that the letters or numbers between the brackets
are appended to the base word or partial word in the indicated position to give alternate but related words that
have the same abbreviation or acronym. Thus the entry "geodeti[c][que]" means that both the word "geodetic"
and the word "geodetique" may be abbreviated with the abbreviation "GEOD" in the adjacent column.
F.2 Tables
Table F.1 — Abbreviations and acronyms used in RDs
Word or phrase Abbreviation or acronym
one Dimensional 1D
two Dimensional 2D
three Dimensional 3D
TM
Coupled Ocean/Atmospheric Mesoscale Prediction System COAMPS
Geodetic Reference System GRS
Institut Géographique National (France) IGN
International Association of Geodesy IAG
Mesoscale (weather) Model 5 MM5
Moderate resolution Transmittance (atmospheric radiation
MODTRAN
transfer)
Navy Operational Global Atmospheric Prediction System
NOGAPS
(United States)
World Geodetic System WGS
Table F.2 — Abbreviations and acronyms used in CSs
Word or phrase Abbreviation or acronym
one Dimensional 1D
two Dimensional 2D
three Dimensional 3D
© ISO/IEC 2009 – All rights reserved
Table F.3 — Abbreviations and acronyms used in ORMTs
Word or phrase Abbreviation or acronym
two Dimensional 2D
three Dimensional 3D
Table F.4 — Abbreviations and acronyms used in ORMs
Word or phrase Abbreviation or acronym
two Dimensional 2D
three Dimensional 3D
adjust[ed][ment] ADJ
American AM
TM
Coupled Ocean/Atmospheric Mesoscale Prediction System COAMPS
European Terrestrial Reference System ETRS
geodeti[c][que] GEOD
Geocentric Datum of Australia GDA
Greek Geodetic Reference System GGRS
Geodetic Reference System GRS
heliocentric HELIO
Institut Géographique National (France
...

Annex G
(normative)
Change and deprecation plan
G.1 Introduction
As various instances of SRM concepts are added or declared obsolete, this International Standard and its
authorized registered items will evolve. Declaring an SRM concept instance obsolete is called deprecation. To
ensure the long-term coherence and orderly evolution of this International Standard, this annex defines
processes for change or deprecation of instances of SRM concepts. This annex also defines how a
deprecated SRM concept instance may be reinstated. Change, deprecation, or reinstatement is in accordance
with ISO/IEC 9973 (see [ISO/IEC 9973]).
G.2 Change
Redefinition of an SRM concept instance means changing that item to such an extent that it would require
amendment or republication. That is, the item would no longer represent the same concept instance, or the
SRM code and/or SRM label would no longer denote the same concept instance.
Reuse of an SRM code or SRM label means assignment of that SRM code or SRM label to denote a different
concept instance than originally assigned.
To ensure stable evolution while protecting the investment of users, care shall be taken when changes are
made to SRM concept instances, whether they were originally defined in this International Standard or later by
registration. The following rules apply both to changes to this International Standard by amendment or
republication and to changes to SRM registered items:
a) Changes to the extent allowed in corrigenda, including editorial changes that clarify without changing
the semantic meaning or any of the associated data, may be made to an SRM concept instance in this
International Standard.
b) Changes to an SRM concept instance in this International Standard not permitted by a) shall be
accomplished by deprecation following the procedure defined in G.3.2.
c) No changes of any type shall be made to any SRM concept instance defined by registration. Instead,
the existing SRM registered item shall be deprecated following the procedure defined in G.3.3.
d) No SRM code or SRM label shall be redefined or reused except by the process of reinstatement
defined in G.4.
G.3 Deprecation
G.3.1 Introduction
The committee responsible for the development of this International Standard shall publish and maintain a
standing document containing lists of all deprecated SRM concept instances. For each deprecated instance,
the document shall contain the reason for the deprecation, the identification of the document(s) that
implemented the deprecation (amendments, republications, or registration proposals) and a link to the current
online version of the deprecated concept instance. This document shall be made available on the World Wide
© ISO/IEC 2009 – All rights reserved
Web and shall be referenced by hyperlink from both the SRM register area of the International Register of
Items and future amended or republished editions of this International Standard.
G.3.2
...

Annex H
(normative)
Templates for registration proposals
H.1 Introduction
This annex contains a set of blank forms that may be used to create proposals for various types of SRM
registered items as specified in Clause 13.
These forms include four common initial elements that apply to all instances of SRM concepts that can be
registered. These common elements are described in Table H.1.
Table H.1 — Common registration proposal specification elements
Element Definition
Date of proposal
Date the registration proposal is submitted.
Sponsoring authority Sponsor of the registration proposal.
Justification for inclusion Justification for the registration proposal.
Additional comments Any additional comments on the registration proposal.
H.2 Proposal for the registration of a CS
Each proposal for the registration of a CS shall provide values of all of the elements contained in Table H.1
and in Table H.2. The required contents of the specification column are described in Table 5.5.
Table H.2 — Coordinate system registration proposal elements
Element Specification
Description
CS label
Function type
CS descriptor
Properties
CS parameters and constraints
Coordinate-components
Domain of the generating
function or mapping equations
© ISO/IEC 2009 – All rights reserved
Element Specification
Generating function or mapping

equations
Domain of the inverse of the
generating function or mapping
equations
Inverse of the generating
function or mapping equations
COM
Point distortion
Figures
Notes
References
H.3 Proposal for the registration of a temporal CS
Each proposal for the registration of a temporal CS shall provide values of all of the elements contained in
Table H.1 and in Table H.3. The required contents of the specification column are described in Table 6.1.
Table H.3 — Temporal coordinate system registration proposal elements
Element Specification
Temporal CS label
Description
Epoch
Unit of duration
Relationship to TAI
References
H.4 Proposal for the registration of an RD
Each proposal for the registration of an RD shall provide values of all of the elements contained in Table H.1
and in Table H.4. The required contents of the specification column are described in Table 7.9.
Table H.4 — RD registration proposal elements
Element Specification
RD label
Description
Physical object
© ISO/IEC 2009 – All rights reserved
Element Specification
Parameters
Date
References
H.5 Proposal for the registration of an ORMT
Each proposal for the registration of an ORMT shall provide values of all of the elements contained in Table
H.1 and in Table H.5. The required contents of the specification column are described in Table 7.11.
Table H.5 — ORMT registration proposal elements
Element Specification
ORMT label
Description
RD set
Binding constraints
Notes
H.6 Proposal for the registration of an ORM
Each proposal for the registration of an ORM shall provide values of all of the elements contained in Table H.1
and in Table H.6. The required contents of the specification column are described in Table 7.15.
Table H.6 — ORM registration proposal elements
Element Specification
ORM label
Published name
Reference ORM
Binding information
Region
ORMT label
RD parameterization
Reference transformation Repeat as needed using H.7.
References
© ISO/IEC 2009 – All rights reserved
H.7 Proposal for the registration of a reference transformation
Each proposal for the registration of an RT shall provide values of all of the elements contained in Table H.1
and in Table H.7. The required contents of the specification column are described in Table 7.16.
Table H.7 — RT registration proposal elements
Element Specification
ORM label
RT label
RT region
RT parameters
Date published
References
H.8 Proposal for the registration of an OBRS
Each proposal for the registration of an OBRS shall provide values of all of the elements contained in Table
H.1 and in Table H.8. The required contents of the specification column are described in Table 7.17.
Table H.8 — OBRS registration proposal elements
Elemen
...

Annex I
(informative)
Conformance testing for SRF operations
I.1 Introduction
This annex provides guidelines that may be useful for developing conformance requirements and
conformance tests for implementation of the concepts specified in this International Standard including, but
not limited to, the API specified in Clause 11.
I.2 Computational error
The meaning of “error” depends on the context and application domain. Potential sources of error in SRF
operations include formulation error, numerical approximation error, round-off error, truncation error and other
errors associated with implementing SRF operations. In Annex B, computational error is defined to be the sum
of digitization error and approximation errors made to simplify the implementation or to improve the
computational efficiency of the process. Errors of this nature should not be confused with errors arising from
modelling the true shape of a spatial object (celestial or abstract) by an approximate shape. In this
International Standard, an ORM used to approximate the shape of an object is assumed exact. How well an
ORM approximates the shape of a celestial object is outside the scope of this International Standard.
The specification of an SRF operation defines the domain and range as well as providing a functional
specification of how each value in the domain is converted into a value in the range. The functional
specifications are the mathematical functions in one or more variables given in Clause 10. These functional
specifications include a set of rules related to the appropriate ORM, bindings to the CS, and instances related
to a particular celestial object.
I.3 SRF operations baseline
Each SRF operation specified in Clause 10 has a theoretically exact specification in terms of mathematical
functions. These formulations are specified assuming the use of theoretically exact arithmetic (infinite
precision) for developing values of an SRF operation. These exact specifications fall into one of four basic
categories:
a) a finite sum of elementary mathematical functions,
b) a finite sum of quadratures,
c) an infinite iterative process, or
d) an infinite power series.
In practice, implementations that use one of these categories require the use of finite precision arithmetic
along with termination in a finite number of steps or after a finite number of terms are computed. Some of the
formulations may have removable singularities in the domain of a function, usually at extremes of the domain.
When implementing such formulations, care should be taken in the neighbourhood of singularities to use the
appropriate numerical approximations or to isolate the singular points with an open set.
© ISO/IEC 2009 – All rights reserved
I.4 Implementations
This International Standard may be implemented in many different ways. Potential implementations include:
a) manual computation without using computers,
b) fixed-purpose hardware, or
c) software executing on general-purpose digital computers ranging from embedded processors to large-
scale computer systems.
Given the wide range of possible implementations and the differing requirements of application domains,
conformance requirements in this International Standard may be restricted to a sub-set of the domains
involved. (See Annex B for a discussion of computational error and Clause 14 for specifics on conformance.)
I.5 Fundamental measure of conformance
There are several conformance criteria that are discussed in Clause 14. One fundamental measure is the
numerical difference between the individual data points of an exact or reference set of points and the
corresponding data points generated by a particular implementation. The absolute difference between the
points in the reference data set and the corresponding points obtained from a particular implementation is
referred to as a computational error. The computational error may have units of length, be angular measures
or be dimensionless depending on the particular SRF operation being evaluated.
When the reference data are generated, it assumes a computational digital accuracy at least as accurate as
double precision, as specified in IEC 60559 (see [IEC 60559]). This means that the size of the mantissa of a
floating-point number is 52 bits, which corresponds to about 15,5 decimal digits of precision (see [IEC 60559]).
Particular implementations may not have to meet this requirement on precision but developers of the system
should understand that use of lower precision arithmetic could increase the computational error when dealing
with SRF operations.
I.6 Error metrics for SRF operations
An error metric is a function that allows data points developed using the exact formulations of Clause 10 to be
compared to corresponding data points resulting from using an implementation, in order to determine the
numerical difference between them. The value of the error metric is the computational error between the data
points that are being compared. Computational errors as defined in this International Standard are absolute
errors. These are positive numbers and may have units of measure associated with them. When the values
being compared are in terms of the same units of measure, there are standard computational error measures
based on the Euclidean metric.
In the case of geodetic to geocentric coordinate conversion, a given exact geodetic coordinate (λ, ϕ, h)
corresponds to an exact geocentric coordinate (x, y, z) and both coordinates are assumed to be known. An
implementation may use an approximate method for performing the conversion. This results in an
approximate geocentric coordinate (x , y , z ). The error in the conversion is then given directly in metres by
a a a
2 2 2
E = dp + ds + h−h .
( ) ( ) ( )
a
Sometimes the data that is being compared involves a mixture of measurement units, such as metres and
radians, and the process for determining the
...

Annex J
(normative)
Deprecated SRM concept instances
J.1 Introduction
This annex contains tables defining those instances of SRM concepts whose use is deprecated as defined in
Annex G. Users of these RDs, ORMs, and DSSs are strongly cautioned that these concepts are expected to
be removed in a future version of this International Standard.
J.2 RDs
This sub-annex presents the specifications of deprecated RDs. The contents of these specification elements
are defined in Table 7.9. Table J.1 is a directory of these RDs organized by type of ellipsoid. The RD entries in
each table are grouped by celestial object type and then ordered alphabetically by their label.
Table J.1 — Deprecated RD specification directory
Deprecated RD specification table Table
Deprecated oblate ellipsoid RDs Table J.2
Deprecated sphere RDs Table J.3
Deprecated prolate ellipsoid RDs Table J.4
Deprecated tri-axial ellipsoid RDs Table J.5

Table J.2 — Deprecated oblate ellipsoid RDs
Parameters
RD
Major
RD label Description Date References
Error
code
semi- Flattening, f
estimate
axis, a
Object type: Earth
[DIGEST,
World Geodetic Assumed
WGS_1960 143 6 378 165 1/298,3 1960 Table 6.1,
System 1960 precise
"WS"]
[DIGEST,
World Geodetic
WGS_1966 1/298,25 Unknown 1966
144 6 378 145 Table 6.1,
System 1966
"WC"]
Object type: Planet (non-Earth)
Object type: Satellite
Object type: Star
© ISO/IEC 2009 – All rights reserved
Table J.3 — Deprecated sphere RDs
In this International Standard, no sphere RDs are deprecated, therefore the table is empty.
Table J.4 — Deprecated prolate ellipsoid RDs
In this International Standard, no prolate ellipsoid RDs are deprecated, therefore the table is empty.
Table J.5 — Deprecated tri-axial ellipsoid RDs
In this International Standard, no tri-axial ellipsoid RDs are deprecated, therefore the table is empty.
J.3 ORMs
This sub-annex presents the specifications of deprecated ORMs. The contents of these specification elements
are defined in Table 7.15. Table J.6 is a directory of these ORMs organized by both whether they are object-
fixed or dynamic, and by type of object. The ORM entries in each table are grouped by celestial object type
and then ordered alphabetically by their label.
Table J.6 — Deprecated ORM specification directory
Deprecated ORM specification table Table
Deprecated abstract object ORMs Table J.7
Deprecated object-fixed ERMs Table J.8
Deprecated dynamic ERMs Table J.9
Deprecated time-fixed instances of dynamic ERMs Table J.10
Deprecated object-fixed planet (non-Earth) ORMs Table J.11
Deprecated dynamic planet (non-Earth) ORMs Table J.12
Deprecated time-fixed instances of dynamic planet (non-Earth) ORMs Table J.13
Deprecated object-fixed satellite ORMs Table J.14
Deprecated dynamic satellite ORMs Table J.15
Deprecated time-fixed instances of dynamic satellite ORMs Table J.16
Deprecated object-fixed stellar ORMs Table J.17
Deprecated stellar ORMs Table J.18
Deprecated time-fixed instances of dynamic stellar ORMs Table J.19

Table J.7 — Deprecated abstract object ORMs
In this International Standard, no abstract object ORMs are deprecated, therefore the table is empty.
Table J.8 — Deprecated object-fixed ER
...

11 Application program interface
11.1 Introduction
This International Standard specifies an API for the SRF operations in Clause 5 and Clause 10. The API
specifies non-object data types (see 11.2), and object classes (see 11.3) used to perform the spatial
operations. Two functions are provided to create certain object instances (see 11.4 and 11.5). Two query
functions are also provided to indicate the extent of support of an API implementation for a profile of the SRM
(see 11.6 and Clause 12). The API also specifies data storage structures for the representation of SRM
concepts that are not used to perform spatial operations (see 11.9).
Class is the term used to categorize the general form of object instances. Each class definition specifies the
methods (if any) that operate on the object. Methods are specified by giving their syntax (input and output
parameters), semantics (how the inputs interact with the state of an instance of the class and produce any
outputs), and error conditions. In particular, the state of an instance of the class is implicitly an input for each
of its methods with the exception of the Create method. The Create method of an object depends only on
its explicit inputs. The state of a class instance may change only as the result of applying a method of the
class.
The active objects created as instances of a given class are reliably denoted by object references. Once
created, objects exist and respond to method invocations until they are destroyed. The property of being
created and existing until destruction is termed the object life cycle. Classes inherit methods from other
classes through the subclass/superclass relationship. Method inheritance is transitive: a subclass also inherits
the methods that have been inherited by its superclass.
Non-object data types do not have an object life cycle nor do they have operations other than those defined by
a programming language that this API might be bound to.
EXAMPLE  Integer is a non-object data type. Programming languages to which this API may be bound have
definition mechanisms and operations for creating and then performing arithmetic operations on integers as variables
and/or constants in the programming language.
The API specifies seven abstract classes (see 11.3.3 and 11.3.5):
a) LifeCycleObject,
b) BaseSRF,
c) BaseSRF2D,
d) BaseSRF3D,
e) BaseSRFwithTangentPlaneSurface,
f) BaseSRFwithEllipsoidalHeight, and
g) BaseSRFMapProjection.
These abstract classes are used as base classes from which subclasses including concrete classes inherit
common sets of methods. LifeCycleObject includes the creation and destruction methods that all other
classes inherit. The LifeCycleObject creation method specification may be overridden in a concrete
subclass to provide subclass specific inputs and error conditions. The use of abstract classes in this
International Standard is solely for the purpose of specifying common methods in only one place instead of
repeating the same specification in each concrete class for which it applies. API implementations are not
required to implement abstract classes.
The API specifies six classes whose methods are not exposed as part of the API:
© ISO/IEC 2009 – All rights reserved
a) three coordinate classes: Coordinate2D, Coordinate3D, and SurfaceCoordinate;
b) one direction class Direction and
c) two position classes: Position2D, and Position3D.
These classes are private classes that hide all aspects of the implementation of instances of these objects
from the application.
The API specifies a set of concrete classes that correspond to specific SRFTs specified in Clause 8 (see
11.3.6 through 11.3.10). An instance of one of these concrete classes corresponds to a specific SRF.
Instances of concrete SRF classes that correspond to the coded collection of SRFT instances specified in
Table 8.30 are created by the function CreateStandardSRF. CreateStandardSRF takes the
corresponding SRF_Code (see 11.4) as an input.
Instances of concrete SRF classes that correspond to the members of SRF Sets specified in Table 8.31 are
also created by the function CreateSRFSetMember. CreateSRFSetMember takes an SRFS_Code_Info
(see 11.5) as an input.
The class hierarchy is illustrated in Figure 11.1. Procedural rules for using LifeCycleObjects in
applications and examples of use of the API are provided in 11.8.
11.2 Non-object data types
11.2.1 Overview
Basic non-object data types represent single pieces of information such as numbers, codes, and other
individual data items. Structured data types represent data records of basic non-object data types.
11.2.2 Abbreviations
Table 11.1 lists the SRFTs and their abbreviations used in the formation of enumerant names and record
element names of non-object types.
Table 11.1 — SRFT abbreviations
Abbreviation SRFT
CC Celestiocentric
CD Celestiodetic
CM Celestiomagnetic
EC Equidistant Cylindrical
EI Equatorial Inertial
HAEC Heliospheric Aries Ecliptic
HEEC Heliospheric Earth Ecliptic
HEEQ Heliospheric Earth Equatorial
LCC Lambert Conformal Conic
LCE_3D Lococentric Euclidean 3D
LSA Local Space Azimuthal
© ISO/IEC 2009 – All rights reserved
Abbreviation SRFT
LSP Local Space Polar
LSR_2D Local Space Rectangular 2D
LSR_3D Local Space Rectangular 3D
LTSAS Local Tangent Space Azimuthal Spherical
LTSC Local Tangent Space Cylindrical
LTSE Local Tangent Space Euclidean
M Mercator
OMS Oblique Mercator Spherical
PD Planetodetic
PS Polar Stereographic
SEC Solar Ecliptic
SEQ Solar Equatorial
SMD Solar Magnetic Dipole
SME Solar Magnetic Ecliptic
TM Transverse Mercator
11.2.3 Numbers
Two categories of numbers are specified: integer numbers and floating-point numbers. The general-purpose
integer data types are Integer_Positive and Integer. All implementations that conform to this standard
shall support at least the minimum ranges for values of these data types as specified in Table 11.2.
Table 11.2 — Integer data types
Data type Value range
Integer_Positive
[1, 4 294 967 295]
Integer
[-2 147 483 647, 2 147 483 647]

Long_Float is a non-object data type defined for floating-point numbers. This data type corresponds to the
double precision floating-point data type specified by IEC 60559. However, implementations on architectures
that support other floating-point representations are allowed.
11.2.4 Logicals
The general-purpose logical data type is Boolean. All implementations that conform to this standard shall
support this type as specified in Table 11.3.
Table 11.3 — Logical data type
Data type Values
Boolean [ false (or 0), true (or 1) ]
© ISO/IEC 2009 – All rights reserved
11.2.5 Object_Reference
An Object_Reference is an opaque non-object data type that allows an application to reliably access an
instance of an object. Object_References may be compared for equality and tested to see if they are equal
to the special value NULL_Object. If two Object_References are equal, they refer to the same object
instance. If an Object_Reference is equal to the special value NULL_Object it does not reference any
object instance. In all the method specifications in this clause, whenever an argument passed to or returned
from a method is an object, it is an object reference that is passed.
11.2.6 Enumerated data types
11.2.6.1 Introduction
Enumerated data types are data types whose values are specified from an ordered list of names. The names
are assigned numbers whose values indicate the position within the ordered list. It is these numbers that are
actually manipulated by the implementation. Enumerated data types are a closed list the members of which do
not change based on registration or deprecation. This clause specifies the enumerated data types within this
International Standard.
11.2.6.2 Axis_Direction
This data type represents the values of the axis direction parameter(s) of the SRFTs
LOCAL_SPACE_RECTANGULAR_3D and LOCAL_SPACE_RECTANGULAR_2D.
Axis_Direction ::= ( POSITIVE_PRIMARY_AXIS,
POSITIVE_SECONDARY_AXIS,
POSITIVE_TERTIARY_AXIS,
NEGATIVE_PRIMARY_AXIS,
NEGATIVE_SECONDARY_AXIS,
NEGATIVE_TERTIARY_AXIS )
11.2.6.3 Coordinate_Valid_Region
This data type represents coordinate location with respect to valid-regions (see 8.3.2.4).
Coordinate_Valid_Region ::= ( VALID,
EXTENDED_VALID,
DEFINED )
VALID denotes a coordinate that is contained in the valid-region and in the CS domain.
EXTENDED_VALID denotes a coordinate that is contained in the extended valid-region and in the CS
domain but not in the valid-region.
DEFINED denotes a coordinate that is contained in the CS domain but not in the valid or the extended
valid-regions.
11.2.6.4 Interval_Type
This data type is used to specify coordinate-component intervals in the SetValidRegion,
SetExtendedValidRegion, GetValidRegion, and GetExtendedValidRegion methods of class
BaseSRF3D and in the SetValidGeodeticRegion, SetExtendedValidGeodeticRegion,
GetValidGeodeticRegion, and GetExtendedValidGeodeticRegion methods of class
BaseSRFMapProjection.
© ISO/IEC 2009 – All rights reserved
Interval_Type::= ( OPEN_INTERVAL,  // The bounded open interval (a, b).
GE_LT_INTERVAL, // The bounded interval [a, b).
GT_LE_INTERVAL, // The bounded interval (a, b].
CLOSED_INTERVAL, // The bounded interval [a, b].
GT_SEMI_INTERVAL, // The unbounded interval (a, +infinity).
GE_SEMI_INTERVAL, // The unbounded interval [a, +infinity).
LT_SEMI_INTERVAL, // The unbounded interval (-infinity, b).
LE_SEMI_INTERVAL, // The unbounded interval (-infinity, b].
UNBOUNDED      // All values (-infinity, +infinity)
)
11.2.6.5 Polar_Aspect
This data type represents the values of the polar aspect parameter of SRFT POLAR_STEREOGRAPHIC.
Polar_Aspect ::= ( NORTH,
SOUTH )
11.2.7 Selection data types
11.2.7.1 Introduction
Selection data types are similar to enumerated data types but form a set of entries that may be extended.
Selection data types are all defined to be as distinct sub-data types of the numeric of data type Integer, but
with specific meanings attached to each value. The set of selections may be augmented by assigning
meanings to additional values. Selection data types are otherwise processed in the same manner as
enumerated data types. The integer codes are unique within each concept set, but not between sets. Although
the RT_Code is used in combination with an ORM_Code, its code space follows the general rule and is
independent of the ORM_Code.
In each code space the valid Integer values are 0 and greater. Negative code values are implementation
dependent and non-conforming. In each code space, the Integer value 0 (UNSPECIFIED) is reserved.
Some API methods and functions allow 0 (UNSPECIFIED) as an input Integer code value and/or an output
Integer code value. The valid use of 0 (UNSPECIFIED) is defined in the specification of the appropriate
method or function.
11.2.7.2 CS_Code
The Integer code data type CS_Code specifies a CS by its code as defined in Clause 5 or by registration.
Table 5.7 is a directory of CS specifications, each of which includes a code value and a corresponding label.
11.2.7.3 DSS_Code
The Integer code data type DSS_Code specifies a DSS by its code as defined in Table 9.2 and in Table
J.20 or by registration. Each DSS specification includes a code value and a corresponding label.

11.2.7.4 ORM_Code
The Integer code data type ORM_Code specifies an ORM by its code as defined in Annex E and Annex J or
by registration. Each ORM specification includes a code value and a corresponding label (see Clause 7).
© ISO/IEC 2009 – All rights reserved
11.2.7.5 ORMT_Code
The Integer code data type ORMT_Code specifies an ORM Template code defined in Clause 7 or by
registration. Table 7.12 is a directory of ORMT specifications, each of which includes a code value and a
corresponding label.
11.2.7.6 RT_Code
The Integer code data type RT_Code specifies a reference transformation H . Each RT_Code is defined in
SR
Annex E in the entry for the ORM or by registration, specified by the ORM_Code value, with which it is
associated. Each reference transformation specification associated with an ORM includes a code value and a
corresponding label.
API methods or functions that require the RT_Code data type shall also require its associated ORM_Code.
11.2.7.7 SRF_Code
The Integer code data type SRF_Code specifies an SRF by its code as defined in Table 8.30 or by
registration. Each SRF specification includes a code value and a corresponding label (see Clause 8).

11.2.7.8 SRFS_Code
The Integer code data type SRFS_Code specifies an SRF set by its code as defined in Table 8.48 or by
registration. Each SRF set specification includes a code value and a corresponding label (see Clause 8).

SRFS_Code ::= ( < 0 : // implementation_dependent,
0 : SRFS_UNSPECIFIED,
1 : SRFS_ALABAMA_SPCS,
2 : SRFS_GTRS_GLOBAL_COORDINATE_SYSTEM,
3 : SRFS_JAPAN_RECTANGULAR_PLANE_CS,
4 : SRFS_LAMBERT_NTF,
5 : SRFS_UNIVERSAL_POLAR_STEREOGRAPHIC,
6 : SRFS_UNIVERSAL_TRANSVERSE_MERCATOR,
7 : SRFS_WISCONSIN_SPCS,
>7 : // reserved for registration )

11.2.7.9 SRFS member types
11.2.7.9.1 Introduction
The Integer code types that specify the SRFS members associated with the SRFS defined in Table 8.48.
11.2.7.9.2 SRFSM_Alabama_SPCS_Code
The Integer code data type SRFSM_Alabama_SPCS_Code specifies a member of the Alabama SPCS
SRFS in Table 8.50 or by registration.
11.2.7.9.3 SRFSM_GTRS_Global_Coordinate_System _Code
The Integer code data type SRFSM_GTRS_Global_Coordinate_System_Code specifies a member of
the GTRS Global Coordinate System SRFS in Table 8.52 and Table 8.53 or by registration.
© ISO/IEC 2009 – All rights reserved
11.2.7.9.4 SRFSM_Japan_Rectangular_Plane_CS_Code
The Integer code data type SRFSM_Japan_Rectangular_Plane_CS_Code specifies a member of the
Japan Rectangular Plane CS SRFS in Table 8.55 or by registration.
11.2.7.9.5 SRFSM_Lambert_NTF_Code
The Integer code data type SRFSM_Lambert_NTF_Code specifies a member of the Lambert NTF SRFS in
Table 8.57 or by registration.
11.2.7.9.6 SRFSM_Universal_Polar_Stereographic_Code
The Integer code data type SRFSM_Universal_Polar_Stereographic_Code specifies a member of
the Universal Polar Stereographic SRFS in Table 8.59 or by registration.
11.2.7.9.7 SRFSM_Universal_Transverse_Mercator_Code
The Integer code data type SRFSM_Universal_Transverse_Mercator_Code specifies a member of
the Universal Transverse Mercator SRFS in Table 8.61 or by registration.
11.2.7.9.8 SRFSM_Wisconsin_SPCS _Code
The Integer code data type SRFSM_Wisconsin_SPCS_Code specifies a member of the Wisconsin SPCS
SRFS Table 8.63 or by registration.
11.2.7.10 SRFT_Code
The Integer code data type SRFT_Code specifies an SRFT by its code as defined in Clause 8 or by
registration. Table 8.3 is a directory of SRFT specifications. Each SRFT specification includes a code value
and a corresponding label.
11.2.7.11 Status_Code
The Status_Code non-object selection data type specifies the status codes associated with methods on
instances of classes specified in this International Standard. The meaning of values other than SUCCESS
varies according to the class and method or function and is further defined in the “Error conditions” element of
each method or function specification in Table 11.6 through Table 11.48 (see common error conditions in
11.3.2). This selection data type may be extended in a language binding specification.
Status_Code ::= ( < 0 : // implementation_dependent,
0 : UNSPECIFIED, // reserved
1 : SUCCESS, // the operation was performed successfully
2 : INVALID_SRF,
3 : INVALID_SOURCE_SRF,
4 : INVALID_SOURCE_COORDINATE,
5 : INVALID_TARGET_COORDINATE,
6 : INVALID_POINT1_COORDINATE,
7 : INVALID_POINT2_COORDINATE,
8 : OPERATION_UNSUPPORTED,
9 : INVALID_SOURCE_DIRECTION,
10 : INVALID_TARGET_DIRECTION,
11 : INVALID_CODE,
12 : INVALID_INPUT,
13 : CREATION_FAILURE,
© ISO/IEC 2009 – All rights reserved
14 : DESTRUCTION_FAILURE,
15 : FLOATING_OVERFLOW,
16 : FLOATING_UNDERFLOW,
17 : FLOATING_POINT_ERROR,
18 : MEMORY_ALLOCATION_ERROR,
>18 : // reserved for language binding specification )

11.2.8 Array data types
11.2.8.1 Introduction
Array data types specify an ordered set whose elements may be of any single data type. Table 11.4 specifies
the notation for Array data types.
Table 11.4 — Array data type notation
Data type Notation
One-dimensional array Data_Type_Name[ length ]
Two-dimensional array
Data_Type_Name[ rows, cloumns ]

The symbols “length”, "rows", and "columns" are positive integers. The length of a one-dimensional array is
specified by "length". When the length is specified by another field of a record data type or by a function
parameter, the field name or function parameter name that will be used to indicate that the size of the array is
obtained from the value of that construct. The index of the first element in the array is either “0” or “1”
depending on the language binding.
For two-dimensional arrays, "rows" and "columns" specify the number of rows and columns of the array
respectively. The ordering of the set is row-major. The indices of the first element in the array are both either
“0” or “1” depending on the language binding.
11.2.8.2 Coordinate2D_Array
This data type specifies an array of Coordinate2D objects.
Coordinate2D_Array ::= {
length  Integer_Positive;
coordinate2D_array  Object_Reference[ length ];
}
11.2.8.3 Coordinate3D_Array
This data type specifies an array of Coordinate3D objects.
Coordinate3D_Array ::= {
length Integer_Positive;
coordinate3D_array  Object_Reference[ length ];
}
11.2.8.4 Coordinate_Valid_Region_Array
This data type specifies an array of Coordinate_Valid_Region variables.
Coordinate_Valid_Region_Array ::= {
length  Integer_Positive;
© ISO/IEC 2009 – All rights reserved
valid_region_array  Coordinate_Valid_Region[ length ];
}
11.2.8.5 Direction_Array
This data type specifies an array of Direction objects.
Direction_Array ::= {
length  Integer_Positive;
direction_array  Object_Reference[ length ];
}
11.2.8.6 Vector_3D
This data type specifies an array of three Long_Float variables representing a vector in 3D Euclidean
space.
Vector_3D ::= Long_Float[ 3 ]
11.2.8.7 Matrix_3x3
This data type specifies a two-dimensional square array of nine Long_Float variables representing a 3x3
matrix (see 10.4.6).
Matrix_3x3 ::= Long_Float[ 3, 3 ]
11.2.8.8 Matrix_4x4
This data type specifies a two-dimensional square array of 16 Long_Float variables representing a 4x4
matrix (see 10.4.6).
Matrix_4x4 ::= Long_Float[ 4, 4 ]
11.2.9 Structured data types
11.2.9.1 Introduction
Non-object data types created as records whose elements are basic non-object data types are called
structured non-object data types. This International Standard specifies a set of structured non-object data
types to collect the (non-ORM) parameters needed to specify an SRF by means of an SRF template, and to
collect parameters needed to specify an ORM transformation.
The elements of structured data types that represent lengths shall be evaluated in the units of metre, and the
elements that represent angles shall be evaluated in the units of radian.
The following notation is used for defining the variant record data structures for non-object types:
::= (    )
{
  
  
…
[
:    ;
:    ;
…
]
© ISO/IEC 2009 – All rights reserved
}
Where:
: The variant record data type that is being defined.
:  The name of the selector
: The selection data type used to select the content of the variant record.
: The name of a record element.
: The data type of a record element. Data type “” signifies the
element is not present in the record.
: A selection data type enumerant for which a record element applies.
{}: The body of the variant record.
[]: The variant part of the variant record.
11.2.9.2 SRFT parameters
11.2.9.2.1 EC_Parameters
This non-object data type specifies the parameters that correspond to SRFT EQUIDISTANT_CYLINDRICAL.
EC_Parameters ::= {
origin_longitude Long_Float;
central_scale Long_Float;
false_easting Long_Float;
false_northing Long_Float;
}
11.2.9.2.2 LCC_Parameters
This non-object data type specifies the parameters that correspond to SRFT
LAMBERT_CONFORMAL_CONIC.
LCC_Parameters ::= {
origin_longitude Long_Float;
origin_latitude Long_Float;
latitude1 Long_Float;
latitude2 Long_Float;
false_easting Long_Float;
false_northing Long_Float;
}
11.2.9.2.3 LSR_2D_Parameters
This non-object data type specifies the parameters that correspond to SRFT
LOCAL_SPACE_RECTANGULAR_2D.
LSR_2D_Parameters ::= {
forward_direction Axis_Direction;
}
11.2.9.2.4 LSR_3D_Parameters
This non-object data type specifies the parameters that correspond to SRFT
LOCAL_SPACE_RECTANGULAR_3D.
LSR_3D_Parameters ::= {
© ISO/IEC 2009 – All rights reserved
forward_direction  Axis_Direction;
up_direction  Axis_Direction;
}
11.2.9.2.5 Local_Tangent_Parameters
This non-object data type specifies the parameters that correspond to SRFT
LOCAL_TANGENT_SPACE_AZIMUTHAL_SPHERICAL, and
SRFT LOCAL_TANGENT_SPACE_CYLINDRICAL.
Local_Tangent_Parameters ::={
geodetic_longitude Long_Float;
geodetic_latitude Long_Float;
azimuth Long_Float;
height_offset Long_Float;
}
11.2.9.2.6 LTSE_Parameters
This non-object data type specifies the parameters that correspond to SRFT
LOCAL_TANGENT_SPACE_EUCLIDEAN.
LTSE_Parameters ::={
geodetic_longitude Long_Float;
geodetic_latitude Long_Float;
azimuth Long_Float;
x_false_origin Long_Float;
y_false_origin Long_Float;
height_offset Long_Float;
}
11.2.9.2.7 LCE_3D_Parameters
This non-object data type specifies the parameters that correspond to SRFT
LOCOCENTRIC_EUCLIDEAN_3D.
LCE_3D_Parameters ::= {
lococentre  Vector_3D;
primary_axis  Vector_3D;
secondary_axis  Vector_3D;
}
11.2.9.2.8 M_Parameters
This non-object data type specifies the parameters that correspond to SRFT MERCATOR.
M_Parameters ::= {
origin_longitude Long_Float;
central_scale Long_Float;
false_easting Long_Float;
false_northing Long_Float;
}
11.2.9.2.9 Oblique_Mercator_Parameters
This non-object data type specifies the parameters that correspond to SRFT
OBLIQUE_MERCATOR_SPHERICAL.
© ISO/IEC 2009 – All rights reserved
Oblique_Mercator_Parameters ::= {
longitude1 Long_Float;
latitude1 Long_Float;
longitude2 Long_Float;
latitude2 Long_Float;
central_scale Long_Float;
false_easting Long_Float;
false_northing Long_Float;
}
11.2.9.2.10 PS_Parameters
This non-object data type specifies the parameters that correspond to SRFT POLAR_STEREOGRAPHIC.
PS_Parameters ::= {
polar_aspect Polar_Aspect;
origin_longitude Long_Float;
central_scale Long_Float;
false_easting Long_Float;
false_northing Long_Float;
}
11.2.9.2.11 SRFS_Code_Info
This Variant_Record_Data_Type specifies an arbitrary SRFS_Code with its associated SRFS member
code. The record element SRFSM_unspecified shall be set to zero (unspecified) when the selector value
is SRFS_UNDEFINED.
SRFS_Code_Info ::= ( srfs_code  SRFS_Code )
{
[
SRFS_UNSPECIFIED:
SRFSM_unspecified Integer;
SRFS_ALABAMA_SPCS:
SRFSM_alabama_spcs SRFSM_Alabama_SPCS_Code;
SRFS_GTRS_GLOBAL_COORDINATE_SYSTEM:
SRFSM_gtrs_global_coordinate_system
SRFSM_GTRS_Global_Coordinate_System_Code;
SRFS_JAPAN_RECTANGULAR_PLANE_CS:
SRFSM_japan_rectangular_plane_cs
SRFSM_Japan_Rectangular_Plane_CS_Code;
SRFS_LAMBERT_NTF:
SRFSM_lambert_ntf SRFSM_Lambert_NTF_Code;
SRFS_UNIVERSAL_POLAR_STEREOGRAPHIC:
SRFSM_universal_polar_stereographic
SRFSM_Universal_Polar_Stereographic_Code;
SRFS_UNIVERSAL_TRANSVERSE_MERCATOR:
SRFSM_universal_transverse_mercator
SRFSM_Universal_Transverse_Mercator_Code;
SRFS_WISCONSIN_SPCS:
SRFSM_wisconsin_spcs SRFSM_Wisconsin_SPCS_Code;
]
}
© ISO/IEC 2009 – All rights reserved
11.2.9.2.12 TM_Parameters
This non-object data type specifies the parameters that correspond to SRFT TRANSVERSE_MERCATOR.
TM_Parameters ::= {
origin_longitude Long_Float;
origin_latitude Long_Float;
central_scale Long_Float;
false_easting Long_Float;
false_northing Long_Float;
}
11.2.9.3 ORM transformation parameters
11.2.9.3.1 ORM_Transformation_2D_Parameters
This non-object data type represents a 2D ORM four-parameter transformation as specified in 7.3.3.
ORM_Transformation_2D_Parameters ::= {
delta_x Long_Float;
delta_y Long_Float;
omega   Long_Float;
delta_s Long_Float;
}
The valid range in radians for values of omega is (-2π, 2π). The valid range for delta_s is greater than -1.
11.2.9.3.2 ORM_Transformation_3D_Parameters
This non-object data type represents a 3D ORM seven-parameter transformation as specified in 7.3.2.
ORM_Transformation_3D_Parameters ::= {
delta_x Long_Float;
delta_y Long_Float;
delta_z Long_Float;
omega_1 Long_Float;
omega_2 Long_Float;
omega_3 Long_Float;
delta_s Long_Float;
}
The valid range in radians for values omega_1, omega_2, and omega_3 is (-2π, 2π). The valid range for
delta_s is greater than -1.
11.3 Object classes
11.3.1 Introduction
SRF objects specify methods that implement the spatial operations specified in Clause 10. To aid in
specification, most of the functionality of the API is defined using a class hierarchy with each abstract class
providing the specification of those methods that are common to each of its subclasses. The remaining
functionality is provided in concrete class and function specifications. The implementation of abstract classes
is not required.
© ISO/IEC 2009 – All rights reserved
The functionality of the methods are specified in the class specification tables (see 11.3.2) that provide the
method name, the semantics, inputs and outputs of the method, and the error conditions of the method. These
methods manipulate internal data (object state) and any input parameters passed in. The success condition is
a nominal behaviour of all methods and is not listed within the error conditions element. The success condition
is associated with Status_Code SUCCESS.
EXAMPLE 1 In Table 11.13, the phrase “this SRF” refers to the internal state of an instance of a concrete class
subclassed (directly or indirectly) from the abstract class specified in the table. In particular, the abstract method
GetORMCode “Outputs the ORM_Code and the RT_Code of this SRF”, and shows “Inputs: none”.
Language bindings may add additional error conditions and related binding-specific mechanisms including the
passing of inputs and outputs, and the presentation of method status. Language bindings shall specify these
mechanisms, since this International Standard does not restrict such mechanisms. Under an error condition,
output values are undefined. When several error conditions apply to a method invocation, the first error
condition detected by an implementation shall be presented as the method status. The error conditions
applicable to a method invocation are the common error conditions specified in 11.3.2 and the additional error
conditions specified in the class specification table for the method and any language-binding specific error
conditions applicable to the method.
A language binding mechanism for presentation of method status shall support the association of a unique
error Status_Code (11.2.7.11)
EXAMPLE 2 If a language binding supports exception handling and if a language binding uses that mechanism to
present method failure, then an exception object method that returns the corresponding Status_Code would satisfy this
requirement.
11.3.2 Class specification format
Class data types are specified in tables in Table 11.5 through Table 11.44 with the following elements:
Table 11.5 — Class specification elements
Element Definition
The name of the object class.
Class
The corresponding SRM concept.
Description
The specification of inherited functionality listing the superclasses of the
class in hierarchical order. Each superclass name is followed by a list of
Superclass(es)
the methods it specifies. The method list excludes methods that are
overridden.
Method or
The name of the method.
Abstract method or
Private method
The specification of the method functionality.
Semantics
The specification(s) of the method input parameters, or "none". The state
of the invoking object is implicitly an input and is not additionally listed in
Inputs
this element. The Create method of an object class is an exception. The
Create method of an object class depends only on its explicit input
parameters.
© ISO/IEC 2009 – All rights reserved
Element Definition
Outputs The specification(s) of the method output parameters, or “none”.
The list of Status_Code values that coorespond to error conditions.
Error conditions Each listed value specifies the condition for which it is applicable.
Common error conditions (see below) are not listed in this element. The
“success condition” is not listed in this element.

The method element of a concrete class is labelled “Method”. The method element of an abstract class is
labelled “Abstract method” or “Private method”. A private method is used to document the functionality of other
methods. A subclass inherits all the abstract methods of its superclass including methods that the superclass
has inherited. In particular, an abstract method inherited by a concrete class shall be implemented for the
concrete class. An implementation may implement private methods in concrete classes for internal use, but
public access to a concrete implementation of a private method is not a requirement. The order in which the
methods are listed in each class follows a life cycle pattern, i.e., creation methods, then data manipulation
methods, and then spatial operations.
The Error conditions element of a method specification does not separately list the following common error
conditions.
a) INVALID_SRF if the SRF object invoking the method was not successfully initialized by the API or is
invalid. The condition does not apply to create methods.
b) FLOATING_OVERFLOW if a floating-point overflow error occurred in the performance of the method.
c) FLOATING_UNDERFLOW if a floating-point underflow error occurred in the performance of the method.
d) FLOATING_POINT_ERROR on input, if a Long_Float input is positive or negative infinity, or a not-a-
number (NAN) value. On output, if a floating-point error (other than an overflow or underflow error)
occurred in the performance of the method.
e) MEMORY_ALLOCATION_ERROR if a memory allocation error occurred in the performance of the
method.
11.3.3 LifeCycleObject
The LifeCycleObject class is the most basic abstract class from which all other classes inherit.
LifeCycleObject is an abstract class. All other abstract classes are defined in 11.3.5.
Table 11.6 — LifeCycleObject
Element Specification
LifeCycleObject
Class
This is the most basic abstract class from which all other classes inherit. An
object derived from a concrete subclass of LifeCycleObject is invalid until
Description
the Create method is successfully invoked. A valid object is invalid after the
Destroy method is invoked.
Superclass(es) None, this is a top level object.
Abstract method Create
© ISO/IEC 2009 – All rights reserved
Element Specification
This method creates an instance of a concrete class. An implementation may
Semantics
perform memory allocation and/or object initialization as part of this method.
Specific inputs are specified in concrete classes that are directly or indirectly
Inputs
subclassed from this class data type.
object_reference: Object_Reference
Outputs
Error conditions CREATION_FAILURE if the object instance could not be created.
Abstract method Destroy
This method destroys an instance of a concrete class. An implementation may
Semantics
perform memory deallocation and/or object finalization as part of this method.
object_reference: Object_Reference
Inputs
Outputs none
Error conditions DESTRUCTION_FAILURE if the object was not successfully deallocated.

11.3.4 Private objects
11.3.4.1 Introduction
Private object classes are concrete classes that represent objects whose methods and attributes are not
exposed to the API user. Instances of these objects may be created by methods on other objects specified in
the API. Object references for instances of private objects may be passed to and returned from methods. This
allows an implementation of the API to store data that can be maintained for these private object classes in
whatever form is convenient for the implementation.
11.3.4.2 Coordinate3D
The Coordinate3D class represents a coordinate of CS data type 3D. It specifies no additional public
methods.
Table 11.7 — Coordinate3D
Element Specification
Coordinate3D
Class
Description A coordinate of CS data type 3D (see 5.3).
Superclass(es) LifeCycleObject: Create, Destroy

11.3.4.3 Coordinate2D
The Coordinate2D class represents a coordinate of CS data type 2D. It specifies no additional public
methods.
© ISO/IEC 2009 – All rights reserved
Table 11.8 — Coordinate2D
Element Specification
Class Coordinate2D
Description A coordinate of CS data type 2D (see 5.3).
Superclass(es)
LifeCycleObject: Create, Destroy

11.3.4.4 SurfaceCoordinate
The SurfaceCoordinate class represents a coordinate of CS data type surface. It specifies no additional
public methods.
Table 11.9 — SurfaceCoordinate
Element Specification
Class SurfaceCoordinate
Description A coordinate of CS data type surface (see 5.5.2.).
Superclass(es) LifeCycleObject: Create, Destroy

11.3.4.5 Direction
The Direction class encapsulates an SRF representation of a spatial direction including the reference
position coordinate and a vector in the local tangent frame of the SRF at the reference position. It specifies no
additional public methods.
Table 11.10 — Direction
Element Specification
Direction
Class
Description A direction (see 10.5.2).
Superclass(es) LifeCycleObject: Create, Destroy

11.3.4.6 Position3D
The Position3D class represents a point in a 3D position-space. It specifies no additional public methods. It
is the input or output of some private methods of the BaseSRF3D class.
Table 11.11 — Position3D
Element Specification
Position3D
Class
Description A point in a 3D position-space
Superclass(es) LifeCycleObject: Create, Destroy

© ISO/IEC 2009 – All rights reserved
11.3.4.7 Position2D
The Position2D class represents a point in a 2D position-space. It specifies no additional public methods. It
is the input or output of some private methods of the BaseSRF2D class.
Table 11.12 — Position2D
Element Specification
Position2D
Class
Description A point in a 2D position-space
Superclass(es) LifeCycleObject: Create, Destroy

11.3.5 Abstract classes
11.3.5.1 BaseSRF
This is the base class for all SRF classes. BaseSRF provides common methods to return coded values that
may be associated with an SRF class instance.
© ISO/IEC 2009 – All rights reserved
Table 11.13 — BaseSRF
Element Specification
Class BaseSRF
Description An abstract class specifying the common methods of all SRF classes
Superclass(es) LifeCycleObject: Create, Destroy
GetORMCodes
Abstract method
Semantics
Outputs the ORM_Code and the RT_Code of this SRF.
Inputs none
orm_code: ORM_Code
Outputs
rt_code: RT_Code
Error conditions No additional error conditions. (See 11.3.2.)
GetSRFCodes
Abstract method
1) Outputs the SRFT_Code of this SRF class instance.
2) If created by the CreateStandardSRF function, outputs a valid
SRF_Code (otherwise output 0). See 11.4.
Semantics
3) If created by the CreateSRFSetMember function, outputs a valid
SRFS_Code_Info (otherwise outputs the SRFS_Code_Info with
SRFS_Code selector value set to SRFS_UNSPECIFIED). See 11.5.
Inputs none
srft_code: SRFT_Code
srf_code: SRF_Code
Outputs
srfs_code_info: SRFS_Code_Info
Error conditions No additional error conditions. (See 11.3.2.)
GetCSCode
Abstract method
Semantics Outputs the CS_Code code of this SRF.
Inputs
none
cs_code: CS_Code
Outputs
Error conditions No additional error conditions. (See 11.3.2.)

11.3.5.2 BaseSRF2D
This is the base class for all 2D SRF classes. BaseSRF2D is a subclass of BaseSRF. This abstract class adds
the following methods:
CreateCoordinate2D,
GetCoordinate2DValues,
ChangeCoordinate2DSRF,
ChangeCoordinate2DSRFObject,
ChangeCoordinate2DArraySRF,
ChangeCoordinate2DArraySRFObject, and
EuclideanDistance.
These methods, respectively, create a Coordinate2D, query component values of an existing
Coordinate2D, change Coordinate2D representation from some other 2D SRF instance, change an array
of Coordinate2D representation from some other 2D SRF instance, or compute the Euclidean distance
between coordinates.
© ISO/IEC 2009 – All rights reserved
The ChangeCoordinate2DSRF method is for the case of source and target SRF instances based on object-
fixed ORMs for the same spatial object using the methodology of 10.4.2 and the ORM reference
transformations specified by the RT_Code input to the concrete SRF Create method. The method
ChangeCoordinate2DSRFObject is for the general case of any pair of instances of concrete SRFs
subclassed from BaseSRF2D where the ORM transformation H is explicitly specified with an input
ST
ORM_Transformation_2D_Parameters data structure. The ChangeCoordinate2DArraySRF and the
ChangeCoordinate2DArraySRFObject methods are similar to the above operating on arrays of
coordinates.
BaseSRF2D also adds the private methods Generating2D and InverseGenerating2D that are used to
specify the functionality of the ChangeCoordinate2DSRF, and ChangeCoordinate2DSRFObject
methods.
Table 11.14 — BaseSRF2D
Element Specification
BaseSRF2D
Class
An abstract class representing the common elements of concrete SRF classes
Description
that have a coordinate system of CS data type 2D.
LifeCycleObject: Create, Destroy
Superclass(es)
BaseSRF: GetORMCodes, GetSRFCodes, GetCSCode
Abstract method CreateCoordinate2D
This method accepts the two ordered coordinate-components and for a specific
SRF concrete class instance creates a 2D coordinate instance initialized with the
Semantics values passed in. Coordinate-components that represent lengths shall be
evaluated in metres. Coordinate-components that represent angles shall be
evaluated in radians.
first_coordinate_component: Long_Float
Inputs
second_coordinate_component:  Long_Float
new_coordinate:    Coordinate2D
Outputs
INVALID_INPUT if the coordinate values are not in the accuracy domain of this
Error conditions
SRF.
GetCoordinate2Dvalues
Abstract method
This method retrieves the two ordered coordinate-components of a 2D
coordinate instance previously initialized through the API. Coordinate-
Semantics
components that represent lengths shall be evaluated in metres. Coordinate-
components that represent angles shall be evaluated in radians.
coordinate:    Coordinate2D
Inputs
first_coordinate_component: Long_Float
Outputs
second_coordinate_component:  Long_Float
INVALID_SOURCE_COORD if the coordinate is not associated with this SRF, or
Error conditions
not initialized through the API.
© ISO/IEC 2009 – All rights reserved
Element Specification
Abstract method ChangeCoordinate2DSRF
This method changes the SRF representation of the spatial position specified by
the input Coordinate2D source_coordinate in the source SRF
source_srf to a Coordinate2D target_coordinate in this SRF, the target
SRF, in accordance with 10.4.2 using the implicit ORM transformation H given
ST
in Equation (9). The required functionality is equivalent to:
1) apply the Generating2D method of srf_source to the input
Semantics
source_coordinate to obtain a source Position2D as an output,
2) apply the implicit H to the source Position2D to obtain a target
ST
Position2D, and
3) apply the InverseGenerating2D method of this SRF to the target
Position2D to obtain the target_coordinate output.
source_srf:  BaseSRF2D
Inputs
source_coordinate:  Coordinate2D
target_coordinate:  Coordinate2D
Outputs
1) INVALID_SOURCE_SRF if source_srf was not successfully initialized
through the API or is invalid.
2) INVALID_SOURCE_COORDINATE if source_coordinate is not (1) in the
Error conditions accuracy domain of the source_srf, or (2) associated with the
source_srf.
3) INVALID_TARGET_COORDINATE if the target_coordinate is not in the
accuracy domain of this SRF.
ChangeCoordinate2DSRFObject
Abstract method
This method changes the SRF representation of the spatial position specified by
the input Coordinate2D source_coordinate in the source SRF
source_srf to a Coordinate2D target_coordinate in this SRF, the target
SRF, using an explicit ORM transformation H as specified by the h_st input in
ST
accordance with sub-clause 10.4.2. The required functionality is equivalent to:
1) apply the Generating2D method of srf_source to the input
Semantics
source_coordinate to obtain a source Position2D as an output,
2) apply the explicit H to the source Position2D to obtain a target
ST
Position2D, and
3) apply the InverseGenerating2D method of this SRF to the target
Position2D to obtain the target_coordinate output.
source_srf: BaseSRF2D
source_coordinate: Coordinate2D
Inputs
h_st:          ORM_Transformation_2D_Parameters
target_coordinate: Coordinate2D
Outputs
1) INVALID_SOURCE_SRF if source_srf was not successfully initialized
through the API or is invalid.
2) INVALID_SOURCE_COORDINATE if source_coordinate is not (1) in the
accuracy domain of the source_srf, or (2) associated with the
Error conditions
source_srf.
3) INVALID_INPUT if h_st parameter values are not in range.
4) INVALID_TARGET_COORDINATE if the target_coordinate is not in the
accuracy domain of this SRF.
© ISO/IEC 2009 – All rights reserved
Element Specification
Abstract method ChangeCoordinate2DArraySRF
This method performs the same operation defined for the
ChangeCoordinate2DSRF method on each Coordinate2D object in the
source_coordinate_array. The processing is in array
...

Bibliography
The following documents provide additional information, which may be of use to users of this International
Standard.
Identifier Reference
Abramowitz, Milton and Stegun, I. A. Handbook of Mathematical Functions. Washington:
ABST
National Bureau Of Standards, 1964. (Reprinted - New York: Dover Publications, 1972).
Alabama state legislature (ASL). System designated; state divided into east and west zones
[online]. The Code of Alabama 1975, title 35, chapter 2, section 35-2-1. Alabama: ASL,
ALSP
1975 [cited 30 March 2005]. Available from World Wide Web:
.
American Institute of Aeronautics and Astronautics (AIAA). Recommended Practice for
Atmospheric and Space Flight Vehicle Coordinate Systems. Washington: AIAA, 1992. ISBN
RPASFV
0930403827.
Bhavnani, K. H. and Vancour, R. P. Coordinate Systems for Space and Geophysical
BHAV Applications. Hanscom Air Force Base (Massachusetts): US Air Force Phillips Laboratory,
1991. Scientific report no. 9, PL-TR-91-2296.
Birkel, Paul A., et al. Pushing the Envelope: The Worldwide Low-Resolution Terrain
Database [online]. Proceedings of the SISO 1999 Spring Simulation Interoperability
BIRK
Workshop. Orlando (Florida): SISO, 1999 [cited 11 July 2005]. Available from World Wide
Web: . Paper no. 99S-SIW-016, filename DOC_2455.pdf.
Borkowski, K. M. Accurate Algorithms to Transform Geocentric to Geodetic Coordinates
[online]. Bulletin Geodesique (BG), vol. 63, no. 1, p. 50-56. Berlin: BG, 1989 [cited 30 March
BORK
2005]. Available from World Wide Web (abstract):
.
Bowditch, Nathaniel. The American Practical Navigator. 2002 Bicentennial ed. Bethesda
BOWD
(Maryland): National Geospatial-Intelligence Agency, 2002. Corrected through US Notice to
Mariners No. 14/2005, 2 April 2005. Document NVPUB9V1.
Bowring, B. R. Transformation from Spatial to Geophysical Coordinates. Survey Review,
BOWR vol. 23, no. 181, p. 323-327. Bristol (UK): Commonwealth Association for Surveying and
Land Economy, 1976.
Canadian Hydrographic Service (CHS), Department of Fisheries and Oceans.
IGLD85
ESTABLISHMENT OF INTERNATIONAL GREAT LAKES DATUM (1985). Burlington
(Ontario): CHS, 1995.
Connerney, John E. P. Magnetic Fields of the Outer Planets. Journal of Geophysical
MFOP
Research, vol. 98, p. 18659-18679. Washington: American Geophysical Union, 1993.
Coordinating Committee, Great Lakes Basic Hydraulic and Hydrologic Data (BHHD).
nd
IGLD79 Establishment of International Great Lakes Datum (1955). 2 ed. Chicago (Illinois): Great
Lakes BHHD, 1979.
Digital Geographic Information Working Group (DGIWG). Digital Geographic Information
Exchange Standard (DIGEST), Part 3: Codes and Parameters [online]. Ed. 2.1.
DIGEST
Washington: DGIWG, 2000 [cited 30 March 2005]. Available from World Wide Web:
.
Dozier, Jeff. Improved Algorithm for Calculation of UTM and Geodetic Coordinates.
DOZI Washington: US National Oceanic and Atmospheric Administration, 1980. Technical report
NESS 81.
© ISO/IEC 2009 – All rights reserved
Identifier Reference
Duxbury, T.C., et al. Mars Geodesy/Cartography Working Group Recommendations on
Mars Cartographic Constants and Coordinate Systems. Symposium on Geospatial Theory,
DUXB
Processing and Applications, commission IV, working group 9. Ottawa (Ontario):
International Society for Photogrammetry and Remote Sensing, 2002.
Einstein, Albert. The Meaning of Relativity. 5th ed. Princeton (New Jersey): Princeton
EINS
University Press, 1988.
Ewing, Clair E. and Mitchell, Michael M. Introduction to Geodesy. New York: Elsevier North-
EWIN
Holland, 1970.
Featherstone, W. E. A comparison of existing co-ordinate transformation models and
CECT parameters in Australia. Journal of Spatial Science (formerly Cartography), vol. 26, no. 1, p.
13-25. East Perth WA (Australia): Mapping Sciences Institute, 1997.
Forsberg, R., et al. OSGM02: A new geoid model of the British Isles [online]. Copenhagen
OSGM02
NV (Denmark): KMS, National Survey and Cadastre, 2002 [cited 30 September 2008].
Available from World Wide Web: .
Fukushima, T. Fast transform from geocentric to geodetic coordinates. Journal of Geodesy,
FUKU
vol. 73, no. 11, p. 603-610. Heidelberg (Germany): Springer-Verlag Heidelberg, 1999.
Greeley, Ronald and Batson, Raymond M. (editors). Planetary Mapping. New York:
PMAP
Cambridge University Press, 1990. ISBN 0521307740.
Hapgood, M. A. Space Physics Coordinate Transformations: A User Guide. Planetary and
HAPG Space Science, vol. 40, no. 5, p. 711-717. Place of publication unknown: Elsevier Science,
1992.
Heikkinen, M. Geschlossene formeln zur berechnung raumlicher geodatischer korinaten
aus rechtwinkligen korrdinaten. Zeitschrift fur Vermessungswesen, vol. 5, p. 207-211.
HEIK
Germany: publisher unknown, 1982.
Heller, Warren G. and Le Schack, A. Richard. Military Geodesy and Geospace Science.
HELL Hanscom Air Force Base (Massachusetts): US Air Force Geophysics Laboratory, 1981.
Document AFGL-TR-81-0028.
Hembree, L. A., Earth Radii used in Numerical Weather Models. Monterey (California):
ERNWM
Naval Research Laboratory, 2005. NRL memorandum report NRL/MR/7543-05-8888.
Hoke, J. E., et al. Map Projections and Grid Systems for Meteorological Applications. Offutt
HOKE
Air Force Base (Nebraska): US Air Force Air Weather Service, 1985.
Institut Géographique National (IGN). Lambert: Projection associée au système géodésique
LIIE
NTF. Paris: IGN, 2003.
Institut Géographique National (IGN). Lambert-93: Projection associée au système
PASG
géodésique RGF93. Paris: IGN, 2000.
Institut Géographique National (IGN). RGF93 et autres systèmes lègaux: Réseau
RGF
Gédésique Français. Paris: IGN, 2004.
Intergovernmental Committee on Surveying & Mapping (ICSM). Geocentric Datum of
Australia Technical Manual [online]. Ver 2.2. Australia: ICSM, 2002 [cited 18 May 2008].
GDA
Available from World Wide Web: .
ISO/IEC 18023-1:2006, Information technology — SEDRIS — Part 1: Functional
I18023-1
specification.
ISO/IEC 18025:2005, Information technology — Environmental Data Coding Specification
I18025
(EDCS).
I19111 ISO 19111:2003, Geographic information — Spatial referencing by coordinates.
© ISO/IEC 2009 – All rights reserved
Identifier Reference
ISO/IEC Directives, Part 2 — Rules for the structure and drafting of International Standards.
ISOD2
5th ed. 2004.
Ito, K. (editor). Encyclopedic Dictionary of Mathematics. 2nd ed. Cambridge
EDM
(Massachusetts): MIT Press, 1993. ISBN 0262590204.
Kolaczek, Barbara, Kovalevsky, Jean and Mueller, Ivan I. Reference Frames in Astronomy
KOVA and Geophysics. Boston (Massachusetts): Kluwer Academic Publishers, 1990. ISBN
079230182X.
Lee, L. P. The Transverse Mercator Projection of the Entire Spheroid. Empire Survey
LLEE Review, no. 16, p. 208-217. Bristol (UK): Commonwealth Association for Surveying and
Land Economy, 1962.
Lide, D. R. (editor). CRC Handbook of Chemistry and Physics. 81st ed. Boca Raton
HCP
(Florida): CRC Press, 2000. ISBN 0849304814.
Ministry of Land, Infrastructure and Transport (MLIT). Notification No. 9 [online]. Japan:
JMLIT
MLIT, 2002 [cited 30 March 2005]. Available from World Wide Web:
.
...

4 Concepts
4.1 Introduction
The SRM provides an integrated framework and precise terminology for describing spatial concepts and
operations on spatial information (including positions, directions, and distances). The SRM includes the
following features:
a) precise and uniform definitions of commonly used spatial coordinate systems, including those based
on map projections,
b) spatial referencing support for physical spatial objects, including artificial objects and non-terrestrial
celestial bodies, as well as abstract spatial objects,
c) spatial operations on positions and directions, including coordinate conversions and transformations,
and calculations of distances and other geometric quantities, along with an application program
interface for performing these spatial operations,
d) codes and labels to support the encoding and exchange of spatial data,
e) an extensible framework that supports the registration of additional instances of SRM concepts, and
f) profiles to allow subsets of the SRM to be defined to conform to the specific requirements of an
application or an application domain.
This International Standard is based on the following conceptual approach:
a) Spatial positions are identified by coordinates in a spatial coordinate system. The collection of spatial
positions associated with a spatial object of interest, such as the Earth, is called its object-space (see
4.2).
b) A spatial reference frame specifies a spatial coordinate system by combining an abstract coordinate
system with an object reference model. An abstract coordinate system may be combined with many
different object reference models. Thus, a geodetic coordinate tied to the Earth object reference
model WGS_1984 does not identify the same place as when tied to the Earth object reference model
EUROPE_1950, or when tied to an object reference model for Mars (see 4.6.3 and Clause 8).
c) An abstract coordinate system associates coordinates with positions in an abstract Euclidean space,
which is called its position-space. Abstract coordinate systems are defined independently of any
object-space. Thus, there are many spatial spherical coordinate systems for a given object-space, but
there is only one abstract spherical coordinate system for a position-space (see 4.6.1 and Clause 5).
d) An object reference model determines a precise relationship between position-space and the object-
space for a spatial object of interest. Different object reference models for the Earth relate position-
space to the object-space of the Earth in different ways. Thus, the object reference model WGS_1984
relates the position-space x-axis to the direction from the Earth’s center of mass towards the
intersection of the Greenwich meridian with the equator, while the object reference model
EARTH_INERTIAL_J2000r0 relates the position-space x-axis to the direction from the Earth’s center
of mass towards the first point of Aries (see 4.5 and Clause 7).
e) The position-space to object-space relationship determined by an object reference model is
expressed mathematically by a length-preserving embedding function called a normal embedding
(see 4.3 and Clause 7).
f) A reference datum is a geometric primitive that relates measurements and/or geometric
characteristics of object-space to position-space. Object reference models use reference datums to
specify the position-space to object-space relationship. An object reference model may also use
reference datums to model a geometric aspect of a spatial object. Thus, an oblate ellipsoid reference
datum may be used to model the figure of the Earth or other celestial bodies (see 4.4 and Clause 7).
g) Temporal coordinate systems are introduced to describe the time-varying characteristics of spatial
reference frames (see 4.6 and Clause 6).
© ISO/IEC 2009 – All rights reserved
h) Vertical offset surfaces are introduced to define heights with respect to equipotential or other complex
surfaces. In particular, the vertical offset surface EGM96_GEOID represents the geopotential surface
defined by the WGS 84 EGM 96 Earth Gravitational Model that is closely associated with the mean
ocean surface (see 4.8 and Clause 9).
The relationships among some of these concepts are depicted in Figure 4.1. An abstract coordinate system is
based on the underlying Euclidean structure of position-space. The reference datums that comprise the object
reference model determine how position-space relates to object-space. That relationship is mathematically
expressed by a normal embedding. A spatial reference frame combines the abstract coordinate system with
the object reference model to specify a spatial coordinate system. This allows positions to be expressed
relative to a spatial object of interest, such as the Earth.

Figure 4.1 — SRM conceptual relationships
The concepts outlined in this sub-clause are discussed in greater detail in the remainder of this clause. This
International Standard takes a functional approach to the definition of these concepts. Basic geometric
concepts, including the concepts of point, line, and plane, are assumed. Annex A provides a concise summary
of important specialized mathematical concepts and notational conventions used in this International
Standard.
4.2 Spatial objects and object-space
Object-space is an abstract universe or a real universe that is associated with a designated spatial object of
interest. Object-space is the context in which all spatial locations are represented and spatial operations are
performed. A rigid spatial object is assumed to be fixed in its object-space (see Example 1).
The spatial objects of concern in this International Standard may be divided into two types: physical objects
and abstract objects.
The set of all continuations of a spatial object is called the universe of the object. In physics, this is called “the space of
the object”. [EINS]
© ISO/IEC 2009 – All rights reserved
Physical objects are real world objects. The length of one metre has intrinsic meaning in the object-space of a
physical object.
Abstract objects are conceptual objects including virtual, engineering, and/or mathematical models. A length
of one metre does not have intrinsic meaning in the object-space of abstract objects. For the purpose of
specifying relationships among abstract object-spaces, a designated length scale shall be associated with
each abstract object-space.
A point in object-space may have a fixed location with respect to the spatial object. If points and objects have
a time-dependent relationship, locations shall be qualified by a time value in a temporal coordinate system.
Thus, at a specified time, the points and objects have a spatially-fixed relationship.
EXAMPLE 1 The Sun and the Earth are both physical objects, each with its own object-space. In the object-space of
the Sun, the Sun is fixed and the Earth moves. In the object-space of the Earth, the Earth is fixed and the Sun moves.
EXAMPLE 2 At any given instant the International Space Station (ISS) has a location in the object-space of the Earth.
EXAMPLE 3 Each component of the ISS has a location in the object-space of the ISS.
EXAMPLE 4 A solar collector component of the ISS was manufactured in compliance with an engineering design. The
CAD/CAM model that specifies the design for that component is defined in an abstract object-space.
4.3 Position-space and normal embeddings
Position-space is an n-dimensional Euclidean space, for n = 1, 2, or 3. Position-space serves as a vector
space abstraction of object-space so that the methods of linear algebra and multivariate calculus may be
applied to spatial concepts.
A normal embedding is a distance-preserving function from positions in position-space to points in object-
space. The distance-preserving property requires that, whenever a pair of points in object-space corresponds
via the normal embedding function to a pair of positions in position-space, the Euclidean distance between the
pair of positions in position-space equals the distance in metres between the pair of object-space points. The
distance-preserving property implies that a normal embedding is one-to-one and continuous. Normal
embeddings also preserve other important geometric properties. Position-space together with a normal
embedding is a specific algebraic model of object-space. In particular, normal embeddings are used to relate
abstract coordinate systems in Euclidean space to spatial coordinate systems in object-space (see 4.6.3).
The origin of a normal embedding is the point in object-space associated by a normal embedding with the
position-space origin. A normal embedding of a 3D position-space is right-handed if the triangle formed by the
three points associated to the x-axis unit point, the y-axis unit point, and the z-axis unit point, in that order, has
a clockwise orientation when viewed from the origin of the normal embedding. Otherwise, the normal
embedding is left-handed. In this International Standard, all 3D normal embeddings shall be right-handed.
Algebraic models of an object-space are not unique. There are infinitely many normal embeddings of an n-
dimensional position-space. Figure 4.2 illustrates two distinct normal embeddings. These normal embeddings
provide two distinct algebraic models of the same object-space. Some dynamic applications require a
continuum of normal embeddings parameterized by time.
© ISO/IEC 2009 – All rights reserved
y-axis
y-axis
1 2
z-axis
z-axis
c
c
similarity
transformation
T
x-axis
x-axis
position-space
position -space
E
E
y-axis
z-axis
y-axis
z-axis
p
x-axis
x-axis
object-space
Figure 4.2 — Two position-space normal embeddings
Any two normal embeddings for the same object-space can be inter-converted with a transformation
consisting of a translation, a rotation and a scale factor. Such a transformation is called a similarity
transformation. If E and E are two normal embeddings, there is a similarity transformation T such that E is
1 2 2
the composition of E with T, E = E
T. This is depicted in Figure 4.2 where p = E c and p = E c . The
1 ( ) ( )
1 1 2 2
2 1
similarity transformation is such that c =T c so that E c = E T c .
( ) ( ) ( ( ))
1 2 2 2 1 2
The method of specifying a normal embedding varies across disciplines and application domains. In the case
of an abstract spatial object, the object-space is itself a Euclidean space and the identity function is an implicit
normal embedding. In some application domains, a normal embedding is implicitly defined by the specification
of the origin point and axis directions. In the case of geodesy, an origin point at the centre of the Earth cannot
be directly specified. Instead, its location is implied by specifying other geometric entities from physical
measurements. Other disciplines use a variety of techniques to either implicitly or explicitly define a normal
embedding. This International Standard abstracts and encapsulates these techniques within the concepts of
reference datum and object reference model.

Each y-axis points away from the viewer.
© ISO/IEC 2009 – All rights reserved
4.4 Reference datums
A reference datum is a geometric primitive in position-space. Reference datums are points or directed curves
in 2D position-space or points, directed curves or oriented surfaces in 3D position-space.
A reference datum is bound when the reference datum in position-space is identified with a corresponding
constructed entity (i.e., a measured or conceptual geometric aspect of a spatial object) in object-space. The
term “corresponding” in this context means that each position-space reference datum is bound to a
constructed geometric entity of the same geometric object type. That is, position-space points are bound to
object-space points, position-space lines to object-space lines, position-space curves to object-space curves,
position-space planes to object-space planes, and position-space surfaces to object-space surfaces.
EXAMPLE 1 An ellipsoid reference datum with major semi-axis a and minor semi-axis b is the surface implicitly
defined by:
2 2 2
x y z
f x,y,z = + + −1= 0
( )
2 2 2
a a b
and is illustrated in Figure 4.3.
z-axis
b
a
y-axis
a a
a
b
x-axis
Figure 4.3 — An ellipsoid reference datum
Figure 4.4 illustrates two distinct bindings of a point reference datum. On the left, the point reference datum is
bound to a specific point in the abstract object-space of a CAD/CAM model. On the right, the point reference
datum is bound to a corresponding point in the physical object-space of an object that has been manufactured
in accordance to that CAD/CAM model.
In some application domains, bound reference datums are used to model a significant aspect of the problem
domain. In particular, in geodesy, oblate ellipsoids are used to model the figure of the Earth or a subset
thereof.
© ISO/IEC 2009 – All rights reserved
point RD in
position-space
bound to a point on a
(physical) manufactured
object
bound to a point on an
(abstract) CAD/CAM model
Figure 4.4 — A reference datum bound to abstract and physical object-spaces
EXAMPLE 2 Semi-axis values a and b, are selected to specify an oblate ellipsoid reference datum. The
a≥b,
following steps (see Figure 4.5) illustrate one way to bind an ellipsoid reference datum specified by semi-axis values a and
b to a conceptual ellipsoid that represents the figure of the Earth in a region as approximated by a geodetic survey control
network:
a) A point on the surface of the reference datum is specified. This point has a computable geodetic latitude ϕ.
b) The specified position-space point is identified with a specific point in object-space.
c) The direction of the oblate ellipsoid rotational axis is constructed in object-space.
d) The direction of the outward surface normal at the point is constructed in object-space so that the angle it
makes with respect to the oblate ellipsoid rotational axis direction is .
(π/2−ϕ)
This binding requires the specification of a point and two directions in object-space.

specified surface normal specified ellipsoid
axis direction
specified surface point
π/2− ϕ
b
a
Figure 4.5 — A reference datum binding
This International Standard specifies a set of reference datums for use in subsequent specifications, including
points, axis lines, planes, and ellipsoids. Additional reference datums may be defined by registration, as
described in 4.13.
A reference datum may be associated with a corresponding constructed entity in object-space by means of a
reference datum binding. The same reference datum may also be associated with a set of points in object-
© ISO/IEC 2009 – All rights reserved
space by means of a normal embedding. The associated set in the latter case is the normal embedding
functional image of the locus of points of the reference datum. These two means of association are not
necessarily related, nor will the two sets of associated points in object-space be necessarily coincident or
otherwise related.
A normal embedding of position-space and a reference datum binding are compatible if the normal embedding
image of the reference datum primitive is coincident with the points (and direction or orientation, as applicable)
of the constructed entity of the reference datum binding.
In general, a reference datum binding may be compatible with many different normal embeddings. Given a set
of two or more bound reference datums, a single normal embedding that is compatible with each of the
bindings may or may not exist. By properly combining multiple reference datum bindings, a unique compatible
(right-handed in the 3D case) normal embedding may be specified.
EXAMPLE 3  The origin point reference datum is bound to a specific constructed point in object-space. The x-axis
reference datum is bound to a specific constructed directed line in object-space. No compatible normal embedding exists
unless the constructed point lies on the constructed directed line. If the point lies on the directed line, then there is exactly
one compatible normal embedding in 1D position-space. In cases of 2D or 3D position-spaces, if the point lies on the
directed line, there are infinitely many compatible normal embeddings.
4.5 Object reference models
An object reference model for a spatial object is a set of bound reference datums for which there exists
exactly one (right-handed in the 3D case) normal embedding of position-space into object-space that is
compatible with each reference datum binding in the set.
z -ax is
specified surface point
y -
axis
x -
axis
normal embedding origin
Figure 4.6 — An object reference model
EXAMPLE 1 An object reference model is constructed from three reference datums: an oblate ellipsoid reference
datum (with specified parameter values a and b), a z-axis reference datum and an xz-plane reference datum. These
reference datums are bound as follows:
a) The oblate ellipsoid reference datum is bound to a conceptual ellipsoid in object-space as in 4.4 Example 2
with major and minor semi-axis values a and b metres, respectively.
© ISO/IEC 2009 – All rights reserved
b) The z-axis reference datum is bound to a conceptual line in object-space. This conceptual line is selected to
coincide with the axis of rotation of the conceptual ellipsoid to ensure the existence of a compatible normal
embedding.
c) The equatorial plane of the conceptual ellipsoid determines the xy-plane of any resulting spatial coordinate
system. The intersection of the equatorial plane of the conceptual ellipsoid with the z-axis conceptual line
determines the origin and the z-axis of the resulting spatial coordinate system. However, these two
reference datum bindings alone do not fully determine the direction of the x-axis of the resulting spatial
coordinate system.
d) The xz-plane reference datum then is bound to a conceptual plane in object-space. This conceptual plane is
selected to contain the z-axis conceptual line to ensure the existence of a compatible normal embedding.
e) The z-axis conceptual line divides the xz-conceptual plane into two half-planes. One half-plane is designated
as the x-positive half-plane. The intersection of the equatorial plane of the conceptual ellipsoid with this x-
positive half-plane determines the x-axis of the spatial coordinate system and its direction. Since there is
one and only one y-axis choice that is right-handed, a compatible normal embedding is uniquely determined
by these three reference datum bindings (see Figure 4.6).
A binding constraint is a relationship in object-space between the constructed entities of two or more bound
reference datums, or a size relationship between a reference datum primitive and its corresponding
constructed entity. Binding constraints are formulated to ensure that there will exist at least one compatible
normal embedding when the reference datums are bound.
EXAMPLE 2 The object reference model in 4.5 Example 1 includes the following three binding constraints:
a) The oblate ellipsoid reference datum is bound to a conceptual ellipsoid that has major semi-axis length of a
metres and minor semi-axis length of b metres.
b) The z-axis reference datum is bound to an object-space conceptual line that coincides with the axis of rotation of
the conceptual ellipsoid.
c) The xz-plane reference datum is bound to an object-space conceptual plane that contains the z-axis conceptual
line.
Object reference models that have similar reference datums and that have the same binding constraints are
abstracted in the notion of an object reference model template.
An object reference model template is a set of reference datums and binding constraints such that, whenever
the reference datums in the set are bound in compliance with the set of binding constraints, then that bound
set of reference datums form an object reference model. An object reference model template can be used to
conveniently specify multiple object reference models.
EXAMPLE 3 Based on 4.5 Example 1, an object reference model template may be specified by the following set of
three reference datums and set of three binding constraints. The reference datum set is:
a) An oblate ellipsoid with major semi-axis a and minor semi-axis b.
b) The z-axis.
c) The xz-plane.
The binding constraints are:
a) The object-space ellipsoid major semi-axis length shall be a metres and the minor semi-axis length shall be b
metres.
b) The z-axis binding shall coincide with the axis of rotation of the ellipsoid.
c) The xz-plane binding shall contain the z-axis.
An object reference model is a realization of an object reference model template if the reference datums of the
object reference model match the reference datum set of the object reference model template, and the
reference datum bindings of the object reference model are compliant with its binding constraints.
© ISO/IEC 2009 – All rights reserved
EXAMPLE 4 The object reference model in 4.5 Example 1 is a realization of the object reference model template in 4.5
Example 3.
EXAMPLE 5 Object reference model European Datum 1950 (specified in Annex E as object reference model
EUROPE_1950) is a realization of the object reference model template in 4.5 Example 3 using the International 1924
ellipsoid reference datum (specified in Annex D as reference datum INTERNATIONAL_1924.)
The object reference model template concept allows for a consistent method of specification for object
reference models. This International Standard specifies a standard set of object reference model templates
(see Clause 7). It also specifies a set of standard object reference models as object reference model template
realizations (see Annex E).
4.6 Coordinate systems
4.6.1 Abstract coordinate systems
An abstract coordinate system is a means of identifying a set of positions in a position-space by coordinate
n-tuples. The space of these n-tuples is called coordinate-space.
An abstract coordinate system is comprised of a domain, a range, and a generating fun
...

14 Conformance
14.1 Introduction
This clause specifies conformance of:
a) functional implementations of the SRM (14.2),
b) exchange formats that use SRM data structures and associated data types (14.3),
c) language bindings of the SRM API (14.4),
d) applications that use the SRM API (14.5), and
e) specifications that reference this International Standard (14.6).
Functional implementation and exchange format conformance are based on profiles. A profile represents a
useful subset of the SRM. Compliance of an application to a profile is also defined. Profiles are defined in
Clause 12.
This clause addresses the required computational accuracy for SRF operations (see 14.2). This clause
specifies accuracy in terms of the maximum computational error of an implementation of an SRF operation.
The accuracy requirement does not apply to the final result of a sequence or chain of SRF operations, only to
each individual SRF operation in the sequence. This clause does not directly address the software
environment, performance, or resource requirements of applications or implementations that conform to
profiles of this International Standard. This clause does not define the application requirements or dictate the
functional content of applications that use SRM implementations.
14.2 Functional implementation conformance
A functional implementation of the SRM conforms to a standard or registered profile P if the following
conditions are satisfied:
a) Each ORM and RT in the ORM profile set of P shall be used with the same label, code, and
terminology defined in this International Standard or by registration,
b) Each SRFT in the SRFT profile set of P shall be used with the same label, code, and terminology
defined in this International Standard or by registration,
c) Each SRF in the SRF profile set of P shall be used with the same label, code, and terminology defined
in this International Standard or by registration,
d) Each SRFS and SRFS member in the SRFS profile set of P shall be used with the same label, code,
and terminology defined in this International Standard or by registration,
e) Each DSS in the DSS profile set of P shall be used with the same label, code, and terminology
defined in this International Standard or by registration,
f) Any other instance of an SRM concept that is defined or specified in this International Standard or
registered shall be used with the same label, code, and terminology defined in this International
Standard or by registration,
g) The implementation shall support the data types required for the API functionality of the profile P sets
of ORMs, SRFTs, SRFs, SRFSs, and DSSs. Additional functionality and data types may be supported
by an implementation. If the implementation supports the API functionality specified in this
© ISO/IEC 2009 – All rights reserved
International Standard, the methods and functions shall use the data types specified in this
International Standard.
h) The implementation shall support the full functionality of all SRF operations defined for each SRF that
belongs to the profile in accordance with Clause 5 and Clause 10,
i) The data types and data structures shall match the specification of the corresponding data types as
defined in this International Standard, and
j) The implementation shall conform to the computational accuracy requirement of profile P.
A functional implementation of the SRM is free to exceed the requirements of any profile to which it claims
conformance.
14.3 Conformance of exchange formats
An exchange format conforms to a standard or registered profile P, if the following conditions are satisfied:
a) Each ORM and RT in the ORM profile set of P shall be used with th
...

9 Designated spatial surfaces and vertical offsets
9.1 Introduction
Many spatial applications require the specification of object-space surfaces that are more complex than a
surface represented by an RD. An RD surface generating function is restricted by definition to be a multi-
variate polynomial of degree 2 or less. Surfaces of interest are often more complex than this restriction allows.
These surfaces are termed designated spatial surfaces. These surfaces often represent some conceptual or
physical aspect of object-space such as a gravity equipotential surface. Some designated spatial surfaces can
be analytically represented by means of a smooth surface in position-space and a normal embedding. Such a
model is termed a designated spatial surface model.
For SRFs that have a vertical coordinate-component, certain designated spatial surfaces may be used to
define vertical offset values. Many real-world measurement systems used in geodesy define the value of the
vertical coordinate-component of an SRF to be zero at a designated spatial surface. If the point of intersection
between each vertical coordinate-component curve and the designated spatial surface is unique, it specifies a
vertical offset value, and the designated spatial surface is termed a vertical offset surface for the given SRF.
In this International Standard, the vertical coordinate-component is always zero at an RD surface. For a given
point, the difference in values of the vertical coordinate-component between these two vertical measurement
systems is called the vertical offset. If the designated spatial surface has a designated spatial surface model,
then the vertical offset may be computed. In the case of SRFs which designate ellipsoidal height as the
vertical coordinate-component, the API (Clause 11) provides a method for the vertical offset computation.
9.2 Designated spatial surface
A designated spatial surface (DSS) is a surface in object-space. A DSS may be used to represent an
application-specific aspect of the object-space.
Two important cases of DSSs are:
a) equipotential surfaces including geoids, and
b) models of mean sea level surfaces based on sounding and tidal data.
A DSS model is comprised of a smooth surface in position-space and a normal embedding such that the
normal embedding image of the position-space surface either coincides with the DSS or approximates it in an
application-specific sense.
EXAMPLE  The International Great Lakes Datum 1955 is associated with a DSS that conceptually represents the
mean water level of certain bodies of water and extensions of the surface to inland areas. It is empirically represented by a
physical network of locations with assigned values for height above the conceptual surface. Various levelling techniques
are applied to extrapolate these height values to other locations. There is currently no mathematically defined surface in
position-space to model the International Great Lakes Datum 1955 DSS.
An equipotential surface is an implicitly defined surface given by P(x,y,z)−c = 0 , where P is a potential
function defined in (a portion of) position-space and c is a value in the range of P.
If P is a smooth function, the equipotential surface is a smooth surface. If the smooth surface is embedded
into object-space with a normal embedding, it is a DSS model for the corresponding DSS in object-space.
An important special case of an equipotential surface is a mathematical model of the gravity potential of a
celestial body. The geoid is a specific equipotential surface of the Earth’s gravity field that best fits the global
mean sea surface in a minimum variance sense. Global, regional, and local approximations of the geoid are
developed from empirical measurements in association with specific ERMs. Gravity equipotential surfaces
have also been modelled for other planets.
© ISO/IEC 2009 – All rights reserved
NOTE  The geoid cannot be measured directly. Current models of the Earth’s gravity potential are usually realized as
truncated power series in spherical harmonics.
9.3 Vertical offset surface
A DSS is a vertical offset surface (VOS) with respect to an SRF in a region of object-space if, for each point in
the region, the DSS intersects the vertical coordinate-component curve containing the point exactly once. The
VOS concept is restricted to SRFs that have a designated vertical coordinate-component and that are based
on an object-fixed ORM. The vertical coordinate-component designation for an SRF is defined in 8.4.
The vertical coordinate-component zero surface is the set of points for which the vertical coordinate-
component value is zero (see 5.5.2). Given a point p on the vertical coordinate-component zero surface that is
in the region of a VOS, the vertical offset at p is the value of the vertical coordinate-component at the
intersection of the VOS with the vertical coordinate-component curve that contains p. The vertical offset at p is
denoted v(p). If p is not in the region of a VOS or if a VOS has not been specified, the vertical offset at p shall
be defined to be zero.
NOTE  All points on the same vertical coordinate-component curve have the same vertical offset value.
For a VOS with respect to an SRF based on an oblate ellipsoid (or sphere) ORM, the vertical offset at a point
p on the oblate ellipsoid (or sphere) with surface geodetic coordinate (λ,ϕ) is denoted by v λ,ϕ .
( )
In many cases, the values v λ,ϕ are not known or the values are approximately known at specific locations.
( )
When a DSS has a DSS model, the v λ,ϕ values may be computed. If a DSS is a VOS for two SRFs, SRF
( )
S
and SRF , and if the vertical offset function for SRF v λ,ϕ is known, then the vertical offset function for
( )
T S
S
SRF v λ,ϕ may be computed from v as follows:
( )
T S
T
′ ′ ′
c = λ,ϕ,v λ,ϕ c = λ,φ,h
Each SRF coordinate of the form ( ( )) lies on the VOS. If ( ) is the
S S S T
′ ′
v λ,φ =h′
corresponding coordinate representation in SRF , then ( ) .
T
T
The API (Clause 11) provides a vertical offset computation for DSS models that are a VOS with respect to a
given SRF with ellipsoidal height as the vertical coordinate-component.
EXAMPLE 1 If an SRF is derived from SRFT CELESTIODETIC or from a map projection SRFT, the ellipsoidal height
coordinate-component is the designated vertical coordinate-component. Given a VOS with respect to the SRF, v λ,ϕ is
( )
the distance from the ellipsoid to the VOS along the ellipsoidal height curve at (λ,ϕ) in the region of the VOS (see Figure
9.1).
VOS
v λ,ϕ
( )
oblate
ellipsoid
p
λ,ϕ
( )
ellipsoidal height coordinate curve

Figure 9.1 — Vertical offset surface for ellipsoidal height
© ISO/IEC 2009 – All rights reserved
EXAMPLE 2 If an SRF is derived from SRFT LOCAL_TANGENT_SPACE_EUCLIDEAN or SRFT
LOCAL_TANGENT_SPACE_CYLINDRICAL, the designated vertical coordinate-component is height and the vertical
coordinate-component zero surface is a plane. Given a VOS with respect to the SRF, The vertical offset at a point p in the
plane is the distance from p to the VOS along a line normal to the plane (see Figure 9.2).
VOS
v(p)
p
plane of the vertical
coordinate zero surface
Figure 9.2 — Vertical offset surface tangent plane
9.4 Geoidal separation
λ,ϕ
If the VOS is a geoid, v(λ,ϕ) is called the geoidal separation at ( ) (see Figure 9.3). The specification of
the geoidal separation is equivalent to the specification of the geoid surface because the geoid DSS can be
constructed from the set of geoidal separation values.
geoid
geoidal
separation oblate
ellipsoid
λ,ϕ
( )
Figure 9.3 — Geoidal separation
NOTE  The geoidal separation is often published as a table of values of .
v λ,ϕ
( )
9.5 Vertical offset height and elevation
Given a VOS with respect to an SRF with vertical coordinate-component h, the vertical offset height h at point
e
p is defined as h = h - v(p) (see Figure 9.4).
e
EXAMPLE  If the SRF is derived from SRFT CELESTIODETIC and If (λ, ϕ, h) is the coordinate of p, then
h = h - v(λ, ϕ).
e
© ISO/IEC 2009 – All rights reserved
If the VOS is a geoid, then h is called the elevation of p with respect to the geoid. Note that in the geoid case,
e
(ellipsoidal height) - (elevation) = v(λ,ϕ).
NOTE 1 h is an approximation of the distance from p to the VOS. In general, the vertical coordinate-component curve
e
intersection with the VOS is not perpendicular to the VOS. When the intersection is not perpendicular, h does not equal
e
the distance.
NOTE 2 VOS is similar in concept to vertical datum as defined in ISO 19111. ISO 19111 uses the term vertical datum
to define a vertical coordinate reference system as part of a (3D) compound coordinate reference system.

p
h
e
VOS
v λ,ϕ
( )
oblate
ellipsoid
λ,ϕ
( )
ellipsoidal height coordinate curve

Figure 9.4 — Vertical coordinate-component with respect to a vertical offset surface
9.6 Use of vertical offset height in spatial referencing
If a DSS is a VOS for a 3D SRF, and c = (c , c ) is a surface coordinate in the in
...

Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are members of
ISO or IEC participate in the development of International Standards through technical committees
established by the respective organization to deal with particular fields of technical activity. ISO and IEC
technical committees collaborate in fields of mutual interest. Other international organizations, governmental
and non-governmental, in liaison with ISO and IEC, also take part in the work. In the field of information
technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of the joint technical committee is to prepare International Standards. Draft International
Standards adopted by the joint technical committee are circulated to national bodies for
...

Alphabetical Index
2D SRF  145 celestiodetic SRFT  151
3D SRF  145 celestiomagnetic OBRS  137
celestiomagnetic SRFT  158
ε-neighbourhood  324
central scale  43
A
class  219
abstract CS  27
closed curve  328
abstract object  11
closed set  324
accuracy domain template 301
closure of a set  324
accuracy domain 301
closure point  324
affine  325
code 307
angle between two curves  328
common error conditions  233
applicable ORM to SRFT 301
compatible normal embedding  115
approximation error  336
compatible ORM and SRFT 301
arc length  330
component function  325
arctan2 function  330
composition of functions  325
Aries true of date  130
computational accuracy requirement302
augmented equidistant cylindrical CS  80
computational error  336
augmented Lambert conformal conic CS 74
conformal map projection  37
augmented map projection  44
conformance - application 321
augmented Mercator CS  65
conformance - exchange format 320
augmented oblique Mercator spherical CS 67
conformance - functional implementation 319
augmented polar stereographic CS  77
conformance - language binding 320
augmented transverse Mercator CS 70
conic classification  42
axis  33
conic projection function  333
azimuthal CS  93
connected  329
azimuthal spherical CS  55
continued normal vector  329
B
convergence of the meridian  40
basic data type  220
coordinate  28
binding constraint  116
coordinate frame rotation  114
binding of a CS via a normal embedding  143
coordinate of a position  28
bound RD  111
coordinate-component  28
Bursa-Wolfe equation  342
coordinate-component curve  31
C
coordinate-component surface  30
canonical basis  323
coordinate-space  27
Cartesian CS  33
coordinated universal time  102
celestiocentric SRFT  150
cross product  324
© ISO/IEC 2009 – All rights reserved
CS domain  27 enumerated data type  222
CS localization  34 epoch  101
CS parameters  28 equator  32
CS range  28 equatorial inertial OBRS  130
CS type  29 equatorial inertial SRFT  158
curve generating function  329 equatorial plane  5
curvilinear CS  32 equatorial spherical CS  52
curvilinear SRF  145 equidistant cylindrical CS  80
cylindrical classification  42 equidistant cylindrical SRFT  168
cylindrical CS  62 equinox  130
cylindrical projection function  333 equipotential surface  195
Euclidean 1D CS  98
D
Euclidean 2D CS  90
deprecation  501
Euclidean 3D CS  49
description 308
Euclidean distance  324
designated spatial surface  195
Euclidean distance coordinate expression 216
digitization error  335
extended valid-region  145
dimension of an ORM  144
extended valid-region specification  146
directed curve  328
direction  213 F
direction vector at c  214 false easting  43
directional point distortion  38 false northing  43
display coordinate  38 first derivative  325
distance-preserving function  112 first point of Aries  130
dot-product  323 flattening  327
DSS model  195 four parameter transformation  114
dynamic temporal coordinate system  101
G
E generating function  27
Earth gravitational model  5 generating projection  36
Earth reference model  115 geocentric solar magnetospheric SRFT  161
easting  36 geocentric SRFT  150
eccentricity  327 geodesic  330
ecliptic longitude of the Sun  343 geodesic distance  330
ecliptic plane  5 geodesic distance operation 216
elevation  198 geodetic 3D CS  58
ellipse implicitly defined  330 geodetic azimuth  39
ellipse parametrically specified  327 geodetic datum  5
ellipsoid of revolution  326 geodetic SRFT  152
© ISO/IEC 2009 – All rights reserved
geoid  195 latitudinal point distortion  38
geoidal separation  197 left-handed embedding  112
geomagnetic SRFT  158 linear CS  32
global model  115 linear function  325
gradient  324 linear SRF  145
Greenwich sidereal hour angle  343 local model  115
local space azimuthal 2D SRFT  170
H
local space polar 2D SRFT  171
heliocentric Aries ecliptic OBRS  134
local space rectangular 2D SRFT  169
heliocentric planet ecliptic OBRS  135
local space rectangular 3D SRFT  150
heliocentric planet equatorial OBRS  136
local tangent frame at coordinate c  213
heliospheric Aries ecliptic SRFT  161
local tangent space azimuthal spherical SRFT
heliospheric Earth ecliptic SRFT  162
heliospheric Earth equatorial SRFT  163
local tangent space cylindrical SRFT  156
Helmert transformation  207
local tangent space Euclidean SRFT  153
horizontal datum shift  207
local tangent vectors at coordinate c  213
localization operator  34
I
implicit surface  326 lococentre  35
lococentric  35
inertial direction  130
inner product  323 lococentric azimuthal CS  94
lococentric azimuthal spherical CS  56
integrated temporal coordinate system  101
interior of a set  324 lococentric cylindrical CS  63
lococentric equatorial spherical CS  53
interior point  324
international atomic time  102 lococentric Euclidean 2D CS  91
lococentric Euclidean 3D CS
...

0 Introduction
0.1 Purpose
Spatial information processing requires a robust capability to describe geometric properties such as position,
direction and distance. Information might be spatially referenced to local structures (Example: building
interiors) and regions (Example: cities), or spatially referenced to the Earth as a whole (Example: global
weather). Information might be spatially referenced to other celestial bodies (Examples: astronomical, orbital,
and geomagnetic observations). Information might also be spatially referenced to objects defined within
contexts such as virtual realities (Example: 3D models). In each of these cases, a spatial reference frame is
defined, with respect to which the values of geometric properties can be determined.
It is often necessary to represent a position in several different spatial reference frames, simultaneously,
according to the context in which the position is to be used. Each spatial reference frame corresponds to a
particular way of expressing position. Spatial reference frames might be relative to moving objects (Examples:
planets and spacecraft), and therefore have values that are a function of time. It is necessary to specify the
time to which the spatial position refers, and the time for which the spatial reference frame is defined.
This International Standard defines the conceptual model and the methodologies that allow the description,
and transformation or conversion, of geometric properties within or amo
...

10 SRF operations
10.1 Introduction
This International Standard specifies operations on SRF coordinates and, in the case of 3D object-spaces, on
SRF spatial directions. Underlying these operations is the similarity transformation associated with two ORMs.
Similarity transformations are treated first in 10.3. Then the general case of changing the representation of a
position as a coordinate in one SRF to its representation as a coordinate in another SRF is specified in 10.4,
followed by important special cases. The specification of a spatial direction in the context of an SRF is
defined, and the general case of changing the representation of a spatial direction in one SRF to its
representation in another SRF is specified (10.5).
Euclidean distance in 2D and 3D object-space is specified in 10.6. Distance and azimuth on the surface of an
oblate ellipsoid (or sphere) is specified in 10.7. Vertical offset is defined in 9.3.
10.2 Notation and terminology
An important category of spatial operations is changing spatial information represented in one SRF to spatial
information represented in a second SRF. For this category of operations, the adjective “source” shall be used
to refer to the first SRF, and the adjective “target” shall be used to refer to the second SRF.
The notation in Table 10.1 is used throughout this clause.
Table 10.1 — Notation
Notation Description
ORM Source ORM
S
ORM Target ORM
T
ORM Reference ORM for a given spatial object
R
H Reference transformation from ORM to the reference ORM
SR S R
H Reference transformation from ORM to the reference ORM
TR T R
H Similarity transformation from the embedding of ORM to ORM
ST S T
SRF Source SRF based on ORM
S S
SRF Target SRF based on ORM
T T
SRF The local tangent frame SRF at a coordinate (See 10.5.2)
L
CS CS of SRF
S S
CS CS of SRF
T T
Generating function of CS
G
S
S
−1
Inverse generating function of CS
G T
T
Coordinate of a spatial position in SRF
c S
S
c Coordinate of a spatial position in SRF
T
T
Direction vector in SRF (See 10.5.2)
n
S
S
n Direction vector in SRF (See 10.5.2)
T
T
© ISO/IEC 2009 – All rights reserved
10.3 Operations on ORMs
10.3.1 Introduction
The similarity transformations H between source/target pairs ORM and ORM underlie the coordinate
ST S T
operations in 10.4. Given a set of n ORMs there are n(n-1) such source and target ORM pairs. Instead of
specifying the full set of similarity transformations, this International Standard reduces the requirement to
specifying the reference transformation H from each object-fixed source ORM to the reference ORM for a
SR S R
given object. This subclause specifies the methods of expressing a similarity transformation H in terms of
ST
the reference transformations for the source and target ORMs. The cases of ORMs for a single object are
treated in 10.3.2. The more general cases in which ORM and ORM are ORMs for different objects are
S T
treated in 10.3.3.
10.3.2 ORMs for a single object
If ORM is an object-fixed ORM, its reference transformation H may be specified as a seven-parameter
S SR
transformation in the 3D case (see 7.3.2) and a by four-parameter transformation in the 2D case (see 7.3.3).
The general form of H in the 3D case is given by Equation (7). The form in the 2D case is similar. As vector
SR
operations, they are in the form of a scaled invertible matrix multiplication followed by a vector addition. This
form of vector operation is an invertible affine transformation. In the 3D case using the notation of Equation
(5):
(7)
 
x x Δx x
       
 
       
y = H y ≡ Δy + 1+Δs T y
( )
SR   SR SR
       
        
z z Δz z
       
R  S SR S
NOTE  The processes by which ORMs for the Earth are established are based on physical measurements. These
measurements are subject to error and therefore introduce various types of relative distortions between ORMs. Equation
(7) is based on the assumption that positions in object-space are error free and the equation includes no compensation for
these distortions.
The reference transformation H from ORM to ORM is similarly specified. An important operation is the
TR T R
similarity transformation H from ORM to ORM , when neither the source nor the target is necessarily the
ST S T
−1
reference ORM. The H transformation may be expressed as the composition of H with H (the inverse
ST
SR TR
of H ) as in Equation (8) (see Figure 10.1):
TR
−1
(8)
H =H
H
ST TR SR
-1
H = H °H
ST TR SR
ORM ORM
S T
-1
H
SR
H
TR
ORM
R
Figure 10.1 — Composed transformations
−1
The inverse operation H is also an affine transformation:
TR
© ISO/IEC 2009 – All rights reserved
   
 x  x Δx
  1  
     
-1 -1
H y = T y − Δy
TR TR
   
     
(1+Δs )
TR
     
   
z z Δz
     
 R  R ST
 
Δx  x
 −1  1
   
-1 -1
= T Δy + T y
 TR  TR
   
1+Δs 1+Δs
( ) ( )
TR TR
   
 
Δz z
   
 TR R
Δx  x
  1  
-1
= Δy + T y
TR
   
(1+Δs )
TR
   
Δz z
   
RT R
T −1
Because the matrix T is a rotation matrix, its transpose is also its inverse T . Its inverse is also the
T
TR TR
TR
matrix T corresponding to the reverse rotations of ORM with respect to ORM . In particular:
T R
RT
−1 T
T =T =T
RT TR TR
and
 
x Δx x
     
 
-1      
H y = Δy + T y .
TR   RT
     
(1+Δs )
TR
     
 
z Δz z
     
 R RT R
−1
The composite operation H =H
H reduces to:
ST TR SR
(9)
   
x x
   
   
   
−1
H y = H
H y
ST   TR SR  
   
     
z z
   
 S  S
Δx  x
1+Δs
( )
   
SR
= Δy + T y
ST
   
1+Δs
( )
TR
   
Δz z
   
ST S
where:
T =T T , and
ST RT SR
Δx Δx Δx
    1  
Δy = Δy + T Δy .
RT
     
(1+Δs )
TR
     
Δz Δz Δz
     
ST RT SR
If the rotation parameters are equal, then T is the identity matrix, and if Δs = Δs , H simplifies to a
ST
ST R T
translation of the origin:
 x  Δx x
     
 
     
H y = Δy + y .
ST  
     
     
 
z Δz z
     
 S ST S
Equation (8) and Figure 10.1 also apply to the 2D case.
If the source ORM is a time-dependent ORM for a spatial object, ORM (t) shall denote the ORM at time t,
S S S
and H t shall denote the similarity transformation from the embedding of ORM (t) to the embedding of the
( )
S
SR
object-fixed reference ORM . If the similarity transformation H t can be determined, it is a time-dependent
( )
R
SR
affine transformation. For a fixed value of time t , Equation (8) and Figure 10.1 generalize to
© ISO/IEC 2009 – All rights reserved
−1 −1
H t =H
H t . The generalizations to a time-dependent target ORM (t) are H t =H t
H
( ) ( ) ( ) ( )
T
ST 0 TR SR 0 ST 0 TR 0 SR
−1
and H t =H t
H t for the ORM static and time-dependent cases, respectively.
( ) ( ) ( )
S
ST 0 TR 0 SR 0
EXAMPLE  ORM (t) is the ORM EARTH_INERTIAL_J2000r0 at time t. ORM is the Earth reference ORM
S R
WGS_1984. Because ORM (t) and ORM share the same embedding origin, the H (t) transformation is a (rotation)
S R
SR
matrix multiplication operation (without vector addition). The matrix coefficients for selected values of t account for polar
motion, Earth rotation, nutation, and precession. Predicted values for these coefficients are computed and updated weekly
by the International Earth Rotation Service (IERS) [IERS] (see 7.5.2). See Annex B for other examples of dynamic ORM
reference transformations.
10.3.3 Relating ORMs for different objects
If a spatial object S exists in the space of another spatial object T, and if ORM is the reference ORM for
R
object T, and if the two objects are fixed with respect to each other, then H shall denote a similarity
SR
transformation from the embedding of ORM to the embedding of ORM . H is an affine transformation. If
S R SR
ORM is an object-fixed ORM for the object T then H is given by Equation (8). The time dependent
T ST
generalizations of Equation (8), defined in 10.3.2, are also applicable to this case.
EXAMPLE  ORM is an ORM for the space shuttle (as a spatial object). ORM is the Earth reference
S R
ORM WGS_1984. When in orbit at time t, H (t) transforms positions with respect to ORM to positions with respect to
S
SR
ORM WGS_1984.
If the object-space of S and the object-space of T do not share locations or are otherwise unrelated, a
similarity transformation between ORMs for the respective object-spaces is not defined. An abstract object S
and a physical object T is an important instance of this case (see 10.4.6). However, if H is an invertible
SR
affine transformation between ORM and the reference ORM for T, then, given an object-fixed ORM for object
S
T, ORM , Equation (8) may be used to define an invertible affine transformation H , from ORM to ORM .
T ST S T
10.4 Operations to change spatial coordinates between SRFs
10.4.1 Introduction
Given a coordinate c in a source SRF, SRF , and a target SRF, SRF , the change coordinate SRF
S T
S
operation computes the corresponding coordinate c in SRF . The general case of changing the spatial
T
T
coordinate of a location from SRF to SRF is presented in formulations in 10.4.2 for time-independent (static)
S T
and time-dependent ORM relationships. The general case assumes that the source coordinate corresponds to
a location that exists in both the source and target object spaces.
In the general case, ORM and ORM may differ, and the coordinate systems, CS and CS , may differ. The
S T S T
formulation simplifies in the special case for which ORM = ORM or, more generally, in the case for which
S T
the associated normal embeddings match. This case is presented in 10.4.3. In a further specialization of the
ORM = ORM case, it is assumed that CS and CS are geodetic and/or map projection CSs. These
S T S T
assumptions produce further simplifications (see 10.4.4).
The case for which CS = CS and ORM and ORM differ does not generally produce a computational
S T S T
simplification of the general case. However, when both the source and target SRFs are based on the CS
LOCOCENTRIC_EUCLIDEAN_3D, a simplification is produced and is presented in 10.4.5. This case is
important for operations on directions (10.5.4).

ISO 19111 defines this case as a coordinate operation.
ISO 19111 defines this case as a coordinate conversion.
ISO 19111 defines this case as a coordinate transformation.
© ISO/IEC 2009 – All rights reserved
An extension of the change SRF operation to the case of unrelated source and target object-spaces is
presented in 10.4.6 for linear SRFs. In that case, the ORM transformation is only restricted to an invertible
affine transformation.
10.4.2 Change coordinate SRF operation
SRF and SRF are two object-fixed SRFs for a spatial object and p is a point in object-space that is in the
S T
coordinate system domains for both SRFs. c denotes the coordinate of p in SRF , and c denotes the
S
S T
coordinate of p in SRF . The determination of c as a function of c is an operation on the SRF pair (SRF ,
T S
T S
SRF ). The most general form of the operation is:
T
-1
(10)
c =G
H
G (c )
T T ST S S
where:
G is the CS generating function of SRF ,
S S
H is the embedding transformation from ORM to ORM , and
ST S T
G is the CS generating function of SRF .
T T
See Figure 10.2. CS generating and inverse generation functions are specified in Clause 5.
SRF
SRF
S
T
-1
c c
S T
G ° H ° G
T ST S
change c to c operation
S T
G
S
-1
G
T
H
ST
ORM ORM
S T
Figure 10.2 — Change coordinate SRF operation
Equation (10) is known as the Helmert transformation when H is approximated with the Bursa-Wolfe
ST
equation (see Annex B).
In the time-dependent case, Equation (10) may be generalized to:
-1
c (t) =G
H (t)
G (c ) .
T T ST S S
EXAMPLE 1 If SRF and SRF are two celestiodetic SRFs for the same spatial object with different ellipsoid RDs,
S T
Equation (10) transforms the coordinate c = λ ,ϕ ,h with respect to one oblate ellipsoid to c = (λ ,ϕ ,h ) with
( )
T T T
S S S S T
respect to the other oblate ellipsoid.
NOTE  A transformation between two celestiodetic SRFs for the spatial object Earth is known as a horizontal datum
shift. A number of numerical approximations developed to implement this operation have been published. Under the
© ISO/IEC 2009 – All rights reserved
assumption of zero rotations and no scale differences (ω =ω =ω =0and Δs =0 ), a widely used approximation to
1 2 3
c = λ ,ϕ ,h
directly transform c = (λ ,ϕ ,h ) to ( ) , is the standard Molodensky transformation formula [83502T] as
S S S T T T T
S
follows:
λ λ Δλ
     
     
ϕ = ϕ + Δϕ
     
     
h h Δh
     
T S
where:
−Δxsinλ +Δycosλ
Δλ =
R ϕ +h cosϕ
( ( ) )
N
 
−Δxsinϕ cosλ −Δy sinϕ sinλ +Δz cosϕ
 
 
 
Δϕ = +Δa R (ϕ)ε sinϕ cosϕ a
  ( ) 
N
 
R (ϕ)+h
N
  
+Δf R ϕ a b R ϕ b a sinϕ cosϕ
 ( ( )( ) ( )( )) 
N M
 
Δxcosϕ cosλ +Δycosϕ sinλ +Δz sinϕ 
 
Δh =
 
−Δa a R ϕ +Δf b a R ϕ sin ϕ
( ( )) ( ) ( )
 N N 
 
Δa = difference in ellipsoid major semi-axis from source to target
Δf = difference in ellipsoid flattening from source to target
The quantities a,b,ε ,R ϕ , and R ϕ are defined in Table 5.6.
( ) ( )
N M
Equation (10) is only defined for a value of c in the CS domain if its corresponding position belongs to the
S
S
-1 −1 -1
CS range. If D is the domain of the inverse generating function G and D is the domain of the inverse
T
s S T
−1
generating function , Equation (10) is only defined for c in the set:
G
S
T
-1 -1 -1 -1 -1
(11)
G D ∩H D ≡ c in D |H (G (c )) in D
( ( )) { }
S S ST T S S ST S S
T
EXAMPLE 2 SRF is SRF GEOCENTRIC_WGS_1984 and SRF is an instance of SRFT MERCATOR, with ORM
S T
WGS_1984. Equation (10) is not defined for any c that is on the z-axis of SRF , because the z-axis is not contained in
S
S
the set in Equation (11).
SRF may optionally specify a valid-region V and may optionally specify an extended-valid region E (see
T
T T
8.3.2.4). If D is the domain of the generating function G , then V⊆ E ⊆ D . If Equation (10) is defined for
T T T T T
c , c may be valid (c is in V ) , or extended valid (c is in E \V ) or neither. The set of c coordinates for
S T T T T T T S
which c is valid is:
T
-1 -1 -1
G D ∩H G (E ) ≡ c in D |H (G (c )) in G (E )
( ( )) { }
S S ST T T S S ST S S T T
where:
-1 −1
G E ≡ p in D |G (p) in E .
( )
{ }
T T T T T
In applications that functionally conform to an SRM profile, the domain of an SRF operation is restricted to the
accuracy domain of the SRF as specified by that profile (see Clause 12).

Historically it was thought that these approximations would require less computation than direct conversion. The
perceived computational advantage may have been overcome by technology advances. New efficient algorithms for
converting celestiocentric coordinates to celestiodetic coordinates have been developed that result in appreciably faster
transformations without the attendant loss of accuracy.
© ISO/IEC 2009 – All rights reserved
10.4.3 The matched normal embeddings case
If both ORMs are the same , or, more generally, if the corresponding parameters of the seven-parameter
reference transformations of ORM and ORM match, H is the identity transformation. Consequently,
S T
ST
Equation (10) simplifies to:
-1
(12)
c =G
G c .
( )
T T S S
EXAMPLE 1 If SRF is a celestiodetic SRF (see 8.4) and SRF is the celestiocentric SRF for the same ORM
S T
-1
(ORM = ORM ), then G is the identity and Equation (12) reduces to the geodetic generating function: c =G c .
S T ( )
T T S S
EXAMPLE 2 If SRF is an induced surface celestiodetic SRF (see 8.4) and SRF is the 3D celestiodetic SRF for the
S T
same ORM (ORM = ORM ), Equation (12) changes c = (λ,ϕ) from a coordinate of CS type surface to c = (λ,ϕ,0) a
S T
S T
coordinate of CS type 3D.
If SRF is a 3D SRF that has ellipsoidal height designated as the vertical coordinate-component of the SRF
T
(see 8.4), and SRF is the induced zero height surface SRF, the promotion operation converts a surface
S
st nd
coordinate c in SRF to a 3D coordinate in SRF by setting the 1 and 2 coordinate-components of c to
S T
S T
st nd rd
the 1 and 2 coordinate-components of c and setting the 3 coordinate-component, ellipsoidal height, to 0.
S
Coordinate promotion is a special case of Equation (12). Applicable SRFs include those based on SRFT
CELESTIODETIC, PLANETODETIC, and all map projection SRFTs
EXAMPLE 3 Reversing the roles of source and target SRFs in Example 2, if SRF is a celestiodetic 3D SRF and SRF
S T
is the (induced) surface celestiodetic SRF for the same ORM, Equation (12) is not defined for c = (λ,ϕ,h) , unless h =0 .
S
Equivalently, only coordinates of the form c = (λ,ϕ,0) belong to the set in Equation (11). Coordinates in SRF that are
S
S
not on the oblate ellipsoid (or sphere) RD instance surface, can be projected to the surface along a coordinate curve by
setting h =0 .
If SRF is a 3D SRF that has ellipsoidal height designated as the vertical coordinate-component of the SRF
S
(see 8.4), and SRF is the induced zero height surface SRF, the truncation operation converts a 3D
T
st nd
coordinate c in SRF to a surface coordinate c , by setting the 1 and 2 coordinate-components of c to
S
S T T
st nd
the 1 and 2 coordinate-components of c . The point in object-space corresponding to c and the point in
S S
object-space corresponding to c are not the same point unless h =0 . Truncation, therefore, does not
T
generally preserve location.
10.4.4 Map projection SRF and celestiodetic SRF with matched normal embeddings case
The CS generating function G for a map projection SRF (or, respectively, an augmented map projection
MP
SRF) is implicitly defined (see 5.8.2 or, respectively, 5.8.6) by the composition of the generating function for
the surface geodetic CS (respectively, the geodetic 3D CS) G with the inverse mapping equations
GD
Q≡Q,Q (respectively, Q≡ Q,Q ,h ) as:
( ) ( )
1 2 1 2
G =G
Q .
MP GD
If SRF and SRF are map projection SRFs for the same object, and the corresponding seven parameters of
S T
their reference transformations match, then Equation (12) becomes:
−1
(13)
c = G
Q
G
Q c
( ) ( )( )
T GD, T T GD, S S S
−1
= P
G
G
Q c
( )
T GD, T GD, S S S
for:
© ISO/IEC 2009 – All rights reserved
Q : inverse mapping equations for SRF ,
S S
G : generating function for the surface geodetic (respectively, the geodetic 3D) CS for SRF ,
GD, S S
Q : inverse mapping equations for SRF ,
T T
P : mapping equations for SRF , and
T T
G : generating function for the surface geodetic (respectively, the geodetic 3D) CS for SRF .
GD, T T
Furthermore, if ORM = ORM , then G =G and Equation (13) simplifies to:
S T
GD, S GD, T
(14)
c = P
Q c .
( )
T T S S
NOTE  If SRF is a map projection SRF, and SRF is the corresponding augmented map projection SRF based on the
S T
same ORM, then Equation (14) is equivalent to the promotion operation (see 10.4.3).
If SRF is a celestiodetic SRF and ORM = ORM , Equation (13) simplifies to:
T T S
c =Q c .
( )
T S S
Similarly, if SRF is a celestiodetic SRF and ORM = ORM Equation (13) simplifies to:
S T S,
c = P c .
( )
T T S
10.4.5 Linear orthonormal 3D SRF to linear orthonormal 3D SRF c
...