ISO/IEC 18026:2009

INTERNATIONAL ISO/IEC
STANDARD 18026
Second edition
2009-07-15
Information technology — Spatial
Reference Model (SRM)
Technologies de l'information — Modèle de référence spatial (SRM)

Reference number
©
ISO/IEC 2009
PDF disclaimer
PDF files may contain embedded typefaces. In accordance with Adobe's licensing policy, such files may be printed or viewed but shall
not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading a PDF file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat
accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create the PDF file(s) constituting this document can be found in the General Info relative to
the file(s); the PDF-creation parameters were optimized for printing. Every care has been taken to ensure that the files are suitable for
use by ISO member bodies. In the unlikely event that a problem relating to them is found, please inform the Central Secretariat at the
address given below.
This CD-ROM contains the publication ISO/IEC 18026:2009 in portable document format (PDF), which can be
viewed using Adobe® Acrobat® Reader.
Adobe and Acrobat are trademarks of Adobe Systems Incorporated.

This second edition cancels and replaces the first edition (ISO/IEC 18026:2006), of which it constitutes a
minor revision. It also incorporates the Technical Corrigendum ISO/IEC 18026:2006/Cor.1:2007.
©  ISO/IEC 2009
All rights reserved. Unless required for installation or otherwise specified, no part of this CD-ROM may be reproduced, stored in a retrieval
system or transmitted in any form or by any means without prior permission from ISO. Requests for permission to reproduce this product
should be addressed to
ISO copyright office • C
...

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

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

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
Major semi-axis, a Flattening, f Error estimate
As specified
Despina (satellite of [RIIC, Table V,
DESPINA_1991 49 {Mean radius (km)} 0 accompanying the 1991
Neptune) "Despina"]
parameter value
As specified
[RIIC, Table V,
DIONE_1982 50 Dione (satellite of Saturn) {Mean radius (km)} 0 accompanying the 1982
"Dione"]
parameter value
As specified
[RIIC, Table V,
ELARA_1988 51 Elara (satellite of Jupiter) {Mean radius (km)} 0 1988
accompanying the
"Elara"]
parameter value
As specified
Galatea (satellite of [RIIC, Table V,
GALATEA_1991 64 {Mean radius (km)} 0 accompanying the 1991
Neptune) "Galatea"]
parameter value
As specified
[RIIC, Table V,
HIMALIA_1988 71 Himalia (satellite of Jupiter) {Mean radius (km)} 0 1988
accompanying the
"Himalia"]
parameter value
As specified
[RIIC, Table V,
IAPETUS_1988 75 Iapetus (satellite of Saturn) {Mean radius (km)} 0 accompanying the 1988
"Iapetus"]
parameter value
As specified
[RIIC, Table V,
JULIET_1988 81 Juliet (satellite of Uranus) {Mean radius (km)} 0 accompanying the 1988
"Juliet"]
parameter value
As specified
[RIIC, Table V,
LEDA_1988 87 Leda (satellite of Jupiter) {Mean radius (km)} 0 accompanying the 1988
"Leda"]
parameter value
As specified
Lysithea (satellite of [RIIC, Table V,
LYSITHEA_1988 88 {Mean radius (km)} 0 1988
accompanying the
Jupiter) "Lysithea"]
parameter value
358 © 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 V,
MOON_1991 102 Moon (satellite of Earth) {Mean radius (km)} 0 accompanying the 1991
"Moon"]
parameter value
As specified
[
...

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
(
...

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_C
...

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

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

INTERNATIONAL ISO/IEC
STANDARD 18026
Second edition
2009-07-15
Information technology — Spatial
Reference Model (SRM)
Technologies de l'information — Modèle de référence spatial (SRM)

Reference number
©
ISO/IEC 2009
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but
shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat
accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to
...

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

12 Profiles
12.1 Introduction
A profile identifies a subset of this International Standard that has been specified to meet the needs of a
specific application area. Only those subsets that can define, represent and/or process spatial positions shall
be allowed. The core of a profile is a specified set of compatible ORMs and SRFTs. A profile definition
includes error criteria for any functional implementations of SRF operations included in the profile. The default
profile requires support for all ORMs and SRFTs specified in this International Standard. Additional profiles
may be added by registration.
An ORM and an SRFT are compatible if the ORM is applicable to the SRFT. An ORM is applicable to an
SRFT if the object associated with the ORM satisfies the object or object type specification of the SRFT and
the ORM satisfies the ORM constraint specification of the SRFT.
The error criteria in a profile are defined in terms of accuracy domain templates for SRFTs. An accuracy
domain template for an SRFT is a set of coordinate-component value interval constraints expressed in terms
of the SRF template parameters and a set of error bounds for positional, directional, and ratio errors.
If S is an SRF based on an SRFT with a specified accuracy domain template, the accuracy domain of S is the
set of valid coordinates in the coordinate-space of S that satisfy the accuracy domain template interval
constraints evaluated with the SRFT parameter values for S. Error bounds pertain to SRF operations on the
coordinates in the accuracy domain of S.
The error criteria specified in a profile are used to specify functional conformance (see Clause 14).
An SRM profile specification includes:
a) a description of the profile (see 13.2.4),
b) a specification of a non-empty subset of standard and registered ORMs (along with their
corresponding RTs (see 7.4.5)) each of which shall be applicable to at least one SRFT specified in c,
c) a specification of a non-empty subset of the set of standard and registered SRFTs such that each
SRFT in the set is compatible with some ORM specified in b,
d) specifications of subsets of standard and registered SRFs and SRFSs based on compatible ORMs in
b and SRFTs in c,
e) a (possibly empty) subset of the set of standard and registered DSSs, and
f) a specification of an accuracy domain template and positional, directional, and ratio error bounds for
each SRFT specified in c.
The “default” profile is specified in 12.3. Guidelines for registering profiles are in 13.3.12. The proposal format
for profile registration is provided in H.13. Conformance requirements are specified in 14.2.
12.2 Profile specification
The elements of a profile specification are defined in Table 12.1.
© ISO/IEC 2009 – All rights reserved
Table 12.1 — SRM profile specification elements
Element Definition
Profile label The label of the profile (see 13.2.2).
Profile code The code of the profile (see 13.2.3).
Description A description of the profile (see 13.2.4).
A non-empty subset of standard and registered ORMs, each of which shall be applicable
ORM profile
to at least one SRFT in the SRFT profile set, and the RTs associated with each ORM in
set
the set.
SRFT profile A non-empty subset of standard and registered SRFTs such that each SRFT in the set is
set compatible with some ORM specified in the ORM profile set.
SRF profile A subset of the standard and registered SRFs, including only SRFs derived from SRFTs
set in the SRFT profile set, and specifying an ORM in the ORM profile set.
A subset of the standard and registered SRFSs, including only SRFSs that are derived
SRFS profile
from an SRFT in the SRFT profile set, and such that at least one ORM specified in the
set
ORM profile set satisfies the ORM constraint of the SRFS.
DSS profile A subset of the standard and registered DSSs.
set
This element may be repeated for single SRFTs or groups of SRFTs in the SRFT profile
set. Each SRFT in the SRFT profile set shall appear in one and only one of these
elements.
SRFT label(s) The label(s) of the SRFT profile set member(s).
SRFT ε : the positional error bound in metres,
P
accuracy ε : the directional error bound in radian
...

7 Reference datums, embeddings, and object reference models
7.1. Introduction
This International Standard specifies reference datums as geometric primitives in position-space that are used
to model aspects of object-space through a process termed reference datum binding. A reference datum
binding is an identification of a reference datum in position-space with a corresponding constructed entity in
object-space (see 7.2). Reference datums for celestial bodies of interest are specified in Annex D.
A normal embedding is a distance-preserving function from position-space to object-space. A normal
embedding establishes a position-space model of object-space. The image of a bound reference datum under
a normal embedding may or may not coincide with the constructed entity of the reference datum binding. If
they coincide, the reference datum binding and the normal embedding are said to be compatible (see 7.3).
A set of bound reference datums can be selected so as to be compatible with only one normal embedding. In
this way, a set of bound reference datums with properly constrained relationships can specify a unique normal
embedding. Such a constrained set of bound reference datums is called an object reference model. Object
reference models that use the same set of reference datum primitives and similar binding constraints are
abstracted in the notion of an object reference model template. Object reference model templates provide a
uniform method of object reference model specification (see 7.4).
Object reference models for celestial objects of interest are specified in Annex E. For these celestial objects,
one object reference model is designated as the reference model for the object. The transformation from each
object reference model to the reference model for the object is termed the reference transformation. Time-
independent reference transformations are also specified.
Object-specific rules to bind reference datums in a way that is compatible with the binding constraints of an
object reference model template are defined in 7.5. These object-specific binding rules are used to provide a
uniform method of specifying object reference models for specific dynamically-related celestial bodies.
7.2. Reference datums
7.2.1 Introduction
A reference datum (RD) is a geometric primitive in position-space that is used to model an aspect of object-
space through a process termed RD binding. In this International Standard, the reference datum concept is
defined for 1D, 2D, and 3D position-spaces. In the 2D and 3D cases, this International Standard specifies a
small set of reference datums for use in its own specifications. This set is not intended to be exhaustive. Users
of this International Standard may specify additional reference datums by registration in accordance with
Clause 13.
7.2.2 Reference datums
In this International Standard, an RD geometric primitive is expressed in terms of analytic geometry in
position-space. RDs are designed to correspond to constructed entities of similar geometric type in an object-
space through a process called RD binding (see 7.2.5). These geometric types are limited to a point, a
directed curve, or an oriented surface. The analytic form of the position-space representation and its
corresponding object-space geometric representation are described by category and position-space
dimension in Table 7.1. An RD of a given category is specified by the parameters and/or the analytic
expression of its position-space representation.
© ISO/IEC 2009 – All rights reserved
Table 7.1 — RD categories
Position-space representation
RD Object-space
category representation
1D 2D 3D
Point (a) (a, b) (a, b, c) a point in the
object-space
real a real a, b real a, b, c
Directed a curve in the
p = F t , p = F t ,
( ) ( )
curve
object-space with
2 3
F is smooth and R valued. F is smooth and R valued.
a designation of
direction along the
Direction at p = F t Direction at p = F t
( ) ( )
0 0 0 0
curve
dF dF
is n = (t ). is n = (t ).
0 0
dt dt
Oriented Implicit definition a surface in the
surface object-space with
f (p)= 0.
a designation of
Positive side of
one side as
surface (orientation):
positive
f (p)> 0
This International Standard specifies 2D and 3D RDs by RD category in Table 7.4 through Table 7.8. The
specification elements of those tables are defined in Table 7.2. 3D RDs based on ellipsoids are described in
7.2.3 and 7.2.4 and specified in Annex D with specification elements defined in Table 7.9. Table 7.3 is a
directory of RD specification tables or, in the case of 3D RDs based on ellipsoids, RD specification directories.
Table 7.2 — RD specification elements
Element Definition
RD label The label for the RD (see 13.2.2).
The code for the RD (see 13.2.3). Code 0 (UNSPECIFIED) is
RD code
reserved.
Description
A description of the RD including any common name for the concept.
Position-space representation
The analytic formulation of the RD in position-space

Table 7.3 — RD specification directory
Position-space
RD category Table number
dimension
2D point Table 7.4
3D point Table 7.5
2D directed curve Table 7.6
3D directed curve Table 7.7
3D oriented surface Table 7.8 and Table 7.10

© ISO/IEC 2009 – All rights reserved
Table 7.4 — 2D RDs of category point
RD label RD code Description Position-space representation
ORIGIN_2D 1 Origin in 2D (0,0)
X_UNIT_POINT_2D 2 x-axis unit point in 2D (1,0)
Y_UNIT_POINT_2D 3 y-axis unit point in 2D (0,1)

Table 7.5 — 3D RDs of category point
RD label RD code Description Position-space representation
ORIGIN_3D 4 Origin in 3D (0,0,0)
X_UNIT_POINT_3D 5 x-axis unit point in 3D (1,0,0)
Y_UNIT_POINT_3D 6 y-axis unit point in 3D (0,1,0)
Z_UNIT_POINT_3D 7 z-axis unit point in 3D (0,0,1)

Table 7.6 — 2D RDs of category directed curve
RD label RD code Description Position-space representation
X_AXIS_2D 8 x-axis in 2D
F t ≡ t,0
( ) ( )
Y_AXIS_2D 9 y-axis in 2D
F t ≡ 0,t
( ) ( )
Table 7.7 — 3D RDs of category directed curve
RD label RD code Description Position-space representation
x-axis in 3D
X_AXIS_3D 10
F t ≡ t,0,0
( ) ( )
Y_AXIS_3D 11 y-axis in 3D
F (t)≡ (0,t,0)
Z_AXIS_3D 12 z-axis in 3D
F t ≡ 0,0,t
( ) ( )
Table 7.8 — 3D RDs of category oriented surface
RD label RD code Description Position-space representation
13 xy-plane
f (x,y,z)≡ z = 0
XY_PLANE_3D
14 xz-plane
f (x,y,z)≡ y = 0
XZ_PLANE_3D
15 yz-plane
YZ_PLANE_3D f (x,y,z)≡ x = 0
© ISO/IEC 2009 – All rights reserved
7.2.3 Ellipsoidal RDs
The RDs specified in this International Standard include RDs based on oblate ellipsoids, prolate ellipsoids,
and tri-axial ellipsoids. These RDs are 3D and of category oriented surface. These RDs are specified based
upon certain geometrically-defined parameters. The position-space representations of oblate and prolate
ellipsoid RDs are expressed in the form:
2 2 2
x y z
(1)
f x,y,z = + + −1= 0.
( )
2 2 2
a a b
When a ≥b, an RD of this form is an oblate ellipsoid RD with major semi-axis a and minor semi-axis b as
illustrated in Figure 7.1.
Spheres shall be considered as a special case of oblate ellipsoids. If a =b, an oblate ellipsoid RD may be
called a sphere RD. In this case, the value r = a = b is the radius of the sphere RD.
NOTE  In general usage, spheres are a limiting case of oblate, prolate, and tri-axial ellipsoids. To remove ambiguity,
in this International Standard spheres are a special case of oblate ellipsoids only.
When a illustrated in Figure 7.1.
Instead of specifying the parameters of an oblate ellipsoid RD as the major semi-axis a and the minor semi-

axis b, it is both equivalent and sometimes convenient to use the major semi-axis a and the flattening f as
defined in Equation (2). The minor semi-axis b may be expressed in terms of the major semi-axis a and the
flattening f as in Equation (3). The flattening of a sphere RD is zero ( f = 0).

a−b
flattening definition: f ≡ (2)
a
minor semi-axis relationship:    b = a−a f
(3)
The position-space representation of a tri-axial ellipsoid RD is expressed in the form:
2 2 2
x y z
f x,y,z = + + −1= 0. (4)
( )
2 2 2
a b c
The semi-axes a, b, and c shall be positive non-zero anda≠ b≠ c≠ a .
© ISO/IEC 2009 – All rights reserved
z-axis
b
Oblate
a
y-axis
a
a
z-axis
a
b
b
Prolate
x-axis
a
y-axis
a a
a
b
x-axis
Figure 7.1 — Oblate and prolate ellipsoids

7.2.4 RDs associated with physical objects
In the case of ellipsoid RDs intended for modelling physical objects of interest, published parameter values for
these RDs are used. The specification of these RDs includes the published ellipsoid parameters and the
identification of the associated physical object. The specification elements for physical object RDs are defined
in Table 7.9.
Table 7.9 — Physical object RD specification elements
Element Specification
RD label The label for the RD (see 13.2.2).
RD code The code for the RD (see 13.2.3).
Description The description including the name as published or as commonly known.
Physical object The name of the physical object.
© ISO/IEC 2009 – All rights reserved
Element Specification
Oblate ellipsoid case Major semi-axis, a
(including the sphere case)
Flattening, f
Minor semi-axis, a
Prolate ellipsoid case
Major semi-axis, b
Tri-axial ellipsoid case x-semi-axis, a
y-semi-axis, b
z-semi-axis, c
RD parameters shall be specified by value or by reference (see 13.2.5).
If by value, the value(s) shall be followed by an error estimate expressed in
one of the following forms:
Parameters
a) error estimate: unknown
b) error estimate: assumed precise
c) error estimate (1σ): :
d) error interval: ±
−1
EXAMPLE error estimate (1σ):a :1 250, f :0,25 .
If by reference, this specification element shall express the value(s) and error
estimate(s) using the terminology found in the reference. These terms shall
be enclosed in brackets ( {} ). Any parameter value that is not specified in the
citation(s) shall be specified as in the “by value” case. An error estimate for b
−1
or for f may be substituted in place of an error estimate for f .
Date The date the RD parameters were specified or published.
References The references (see 13.2.5).

The RDs associated with physical objects are specified in Annex D. Table 7.10 is a directory of these RDs
organized by type of ellipsoid. The semi-axis and radius parameters are unitless in position-space, but are
bound to metre lengths when the RD is identified with the corresponding physical object-space constructed
entity.
Table 7.10 — Physical RD specification table locations
Type of ellipsoid RD table
Oblate ellipsoid Table D.2
Sphere Table D.3
Prolate ellipsoid Table D.4
Tri-axial ellipsoid Table D.5
Additional RDs associated with physical objects may be specified by registration in accordance with Clause
13.
© ISO/IEC 2009 – All rights reserved
7.2.5 RD binding
An RD is bound when the RD in position-space is identified with a corresponding constructed entity in object-
space. In this context, a "constructed entity" is defined to mean an intrinsic, artificial, measured, or conceptual
entity in object-space that is uniquely identifiable within the user's application domain. The term
"corresponding" in this context means that each RD is bound to a constructed entity of the same geometric
object type. That is, position-space points are bound to identified points in object-space, position-space
directed lines to constructed lines or line segments in object-space, position-space directed curves to
constructed curves or curve segments in object-space, position-space oriented planes to constructed planes
or partial planes in object-space, and position-space oriented surfaces to constructed surfaces or partial
surfaces in object-space.
When a curve or surface RD is bound, the radii of curvature on the corresponding constructed entity in object-
space shall correspond to the radii of curvature in position-space. In this International Standard, in the case of
physical objects, one unit in position-space corresponds to one metre in object-space. In the case of abstract
objects, one unit in position-space corresponds to the designated length scale unit in the abstract object-
space. In particular, the semi-axes of an ellipsoid RD shall correspond to the semi-axes of the constructed
ellipsoid to which it is bound.
If the constructed entity of an RD binding is fixed in position with respect to object-space, then the RD binding
shall be called an object-fixed RD binding. This definition assumes that the position of the constructed entity
does not change in time by an amount significant for the accuracy and time scale of an application.
EXAMPLE 1 For points on the surface of the Earth, tectonic plate movements are insignificant for many applications.
EXAMPLE 2 An RD X_AXIS_3D is bound to the line segment from the centre of the Earth to the centre of the Sun.
This RD binding is not an object-fixed RD binding with respect to the spatial object Earth.
Figure 7.2 illustrates two distinct bindings of a point RD. On the left, it is bound to a specific point in the
abstract object-space of a CAD/CAM model. On the right, it is bound to a point in physical object-space that is
on an object that has been manufactured from that CAD model.

Point RD in
position-space
Bound to a point on a
(real) manufactured
object
Bound to a point on an
(abstract) CAD/CAM model
Figure 7.2 — An RD bound to an abstract object and to a real object
7.3. Normal embeddings of position-space into object-space
7.3.1 Normal embeddings
An embedding is a position-space model of object-space formed by a one-to-one function of positions in
position-space to points in object-space. A normal embedding is an embedding that satisfies the following
distance-preserving property:
© ISO/IEC 2009 – All rights reserved
A function E from position-space to object-space is distance-preserving if for any two positions p and q in
position-space, the measured distance in object-space from E(p) to E(q) in metres is equal to t
...

2 Normative references
The following referenced documents are indispensable for the application of this document. For dated
references, only the edition cited applies. For undated references, the latest edition of the referenced
document (including any amendments) applies.
NOTE 1  Because citations to International Standards are made by giving the number of the standard followed by
the year (if applicable) and any other specific information identifying the portion of the standard cited, identifiers are not
needed for this purpose. Therefore the identifier element is grey when a reference is an International Standard.
Identifier Reference
ISO 8601:2004, Data elements and interchange formats — Information interchange —

Representation of dates and times.
ISO/IEC 9973:2006, Information technology — Computer graphics, image processing and

environmental data representation — Procedures for registration of items.
IEC 60559:1989, Binary floating-point arithmetic for microprocessor systems (previously

designated IEC 559:1989).
ISO 80000-2:—, Quantities and units — Part 2: Mathematical signs and symbols to be
...

13 Registration
13.1 Introduction
This International Standard specifies standardized instances of several SRM concepts. This International
Standard allows new instances of some SRM concepts to be specified by registration. These new instances
are termed registered items.
New instances of the following SRM concepts may be registered:
a) abstract coordinate systems (see 5.3),
b) temporal coordinate systems (see Clause 6),
c) reference datums (see 7.2),
d) object reference model templates (see 7.4.4),
e) object reference models (see 7.4.5),
f) reference transformations (see 7.4.5),
g) object binding rule sets (see 7.5),
h) spatial reference frame templates (see 8.5),
i) spatial reference frames (see 8.6),
j) spatial reference frame sets and their members (see 8.7),
k) designated spatial surfaces (see Clause 9), and
l) profiles (see Clause 12).
References for new instances of the above SRM concepts may also be registered separately (see 13.2.5).
New items are registered using the established procedures of the registration authority for this International
Standard . These procedures require the submitter to supply all information for a new SRM registered item.
Registration shall be according to the procedures in ISO/IEC 9973 (see [ISO/IEC 9973]). Registration shall not
be used to modify any existing standardized or SRM registered item (see Annex G for details concerning how
standardized and registered items may be deprecated).
Other International Standards that normatively reference this International Standard, implementations of those
standards, and implementations of this International Standard shall not use any SRM registered item codes in
the value ranges reserved for registration or future standardization by this International Standard with any
meaning other than the one defined in this International Standard or in the International Register of Items.
This clause specifies the rules and guidelines that shall be followed in preparing registration proposals.
Registration proposals include required information for new SRM registered items, as well as accompanying
administrative information (see Annex H). The guidelines in 13.2 shall apply to all SRM registered items. The
additional guidelines in 13.3 shall apply only to the indicated sets of SRM registered items.

At the time this International Standard was published, the registration authority was the ISO/IEC Registration Authority
for Items. Contact information for the ISO-designated Registration Authority for Items registered under the ISO/IEC 9973
procedures is available at the ISO Maintenance agencies and registration authorities web site:
http://www.iso.ch/iso/standards_development/maintenance_agencies.htm.
© ISO/IEC 2009 – All rights reserved
13.2 Specification elements for SRM registered items
13.2.1 Introduction
The specification of each SRM registered item shall include the following elements:
a) label: a unique, compact, character string that is used to denote the registered item,
b) code: a unique integer that is used to denote the registered item, and
c) other concept-dependent information as required in this International Standard.
Other concept-dependent information may include the following elements:
a) a description, and
b) references.
The SRFS members do not require labels in the case of some SRFSs. See 8.7.1.
13.2.2 Label
The label element of an SRM registered item specification shall be a compact and human-readable designator
that is used to denote that registered item. Labels in this International Standard may include the name or
names for the registered item.
Each label in this International Standard shall:
a) uniquely denote a specific instance within the set of instances of a given SRM concept,
b) be a succinct expression of the concept instance that it denotes,
c) be represented as a character string, and
d) be human readable.
For presentation purposes only, a long label may be displayed on more than one line by using a hyphen (-) to
separate the label before an underscore (_) character.
EXAMPLE 1 The label LOCOCENTRIC_SURFACE_EUCLIDEAN may be displayed for presentation purposes as:
LOCOCENTRIC_SURFACE -
_EUCLIDEAN.
If two concept instances differ only in the dimension of an associated position-space or the dimension of an
associated object-space, then the characters “_1D”, “_2D”, or “_3D”, as appropriate, shall be appended to the
label as a means of differentiating such concept instances.
The labels of standardized SRM concept instances in this International Standard were created by applying the
following guidelines. Labels for proposed SRM registered items shall be created according to these
guidelines:
a) A label shall be provided for each registered SRM concept instance.
b) Labels shall be character strings.
c) Labels shall contain only uppercase characters (A-Z) and digits (0-9) with the exception of the radix
delimiter symbol "r" and the underscore character (_).
d) Labels shall begin with an uppercase alphabetic character (A-Z).

Uniqueness is only within each set of SRM concepts, for example: RDs or ORMs.
© ISO/IEC 2009 – All rights reserved
e) Labels shall not contain spaces.
f) Labels may be a single word or may be composed of a series of components each of which is a word,
an abbreviation, or an acronym/initialism.
g) The underscore (_) character shall be used to concatenate the components of a label.
h) Labels should be as short as possible while capturing a common use descriptive word or phrase
representative of the registered SRM concept instance.
i) The length of a label shall not exceed sixty-three (63) characters.
The components of a registered SRM concept instance label shall be chosen according to the following
guidelines:
a) Components of labels shall not be used with a different meaning from how that component is used in
this International Standard or in previously registered SRM concept instances.
b) When abbreviating, if a word or phrase to be abbreviated appears in Annex F, the given abbreviation
for that word or phrase shall be used.
c) When abbreviating, if a word or phrase to be abbreviated does not appear in Annex F, the proposed
abbreviation should, if possible, be consistent with those specified in Annex F.
Recognized abbreviations for words, and acronyms for phrases, may be used as components of a label based
on the following guidelines:
a) Each abbreviation shall uniquely represent a single word.
b) A single abbreviation shall not represent a combination of words.
c) Each acronym shall uniquely represent a single multi-word phrase.
d) If a word is abbreviated in one label, it is not required to be abbreviated in other labels.
e) If a word is abbreviated in one label, the same abbreviation should be used wherever that word is
abbreviated.
f) If a phrase is replaced by an acronym in one label, it is not required to be replaced in other labels.
g) If a phrase is replaced by an acronym in one label, the same acronym should be used wherever that
phrase is intended.
h) New acronyms may be defined if necessary to create a label whose length meets the criteria defined
in guidelines (h) and (i) for labels.
i) Jargon shall not be used.
j) An acronym or abbreviation in a label shall not be, by itself, a word with a different meaning than that
of the word/phrase that it replaces.
EXAMPLE 2 The acronym DATUM should not be used for the phrase "Dartmouth Arc Transit Universal Meridian".
13.2.3 Code
The code element of an SRM registered item specification shall be a compact designator that is used to
uniquely identify that registered item. Codes are assigned by the registration authority for this International
Standard when a registration proposal is accepted. Therefore, codes are not included in registration
proposals.
Each code in this International Standard shall:
a) uniquely denote a specific instance within the set of instances of a given SRM concept,
b) be represented as an integer, and
© ISO/IEC 2009 – All rights reserved
c) be assigned sequentially in increasing order within the set of instances of a given SRM concept,
beginning at 1.
There is a one-to-one relationship between labels and codes in the same set of SRM concept instances.
Therefore, a label and a code may be used interchangeably to denote the same concept instance. The set of
members of a single SRFS shall be considered as a separate and distinct set from the set of members of a
different SRFS.
Application program interfaces and exchange formats often utilize codes. Applications using such codes shall
be capable of distinguishing 2 -1 different codes. Negative codes are not permitted in this International
Standard, but they may be used in a non-conforming implementation for experimentation. The code value
zero is reserved for use in the API (see Clause 11).
All codes for SRM standardized concept instances that are not assigned in this International Standard are
reserved for future standardization or for registration. Codes shall be assigned by the registration authority for
this International Standard according to these rules:
a) Nothing shall be assumed about the relationship among standardized or registered SRM concept
instances from the numerical relationships of their corresponding codes. In particular, the numerical
sequencing of codes does not impose any sequential ordering to the standardized or registered SRM
concept instances denoted by those codes.
b) Integers are used to represent codes even though only positive integer values shall ever be assigned
in either this International Standard or through registration. This allows negative integer values to be
used experimentally in applications, even though such use of negative integer values is not in
conformance to this International Standard.
c) The registration authority for this International Standard shall assign codes in increasing order
beginning at the first available integer value, and skipping no integer values, within the set of codes for
each SRM concept.
d) The registration authority for this International Standard shall coordinate the assignment of codes with
future revisions of this International Standard to ensure that no code shall be assigned more than
once in the same scope by either standardization or registration.
13.2.4 Description
The contents of the description element of an SRM registered item specification shall be a precise statement
of the nature, properties, scope, or essential qualities of the concept instance.
The descriptions of standardized SRM concept instances in this International Standard were created by
applying a set of guidelines. Descriptions for proposed SRM registered items shall be created according to
these guidelines:
a) A description shall be provided for each SRM concept instance. This description shall contain at least
one word, number, expression or formula.
b) Descriptions shall be clear and concise, containing only the content necessary to summarize the
concept instance.
c) Jargon shall not be used.
d) Abbreviations shall not be used.
e) Acronyms shall be used only if they are defined in Table 3.3.
f) If an acronym is defined in Table 3.3, it shall be used wherever the phrase would have appeared. That
is, the phrase shall not be used except in Table 3.3; wherever the phrase might have appeared, the
acronym shall be used instead.
© ISO/IEC 2009 – All rights reserved
13.2.5 References
13.2.5.1 Introduction
Two types of references are recognized in International Standards. The first type of reference is a normative
reference [ISOD2]. Identified provisions of a normative reference are incorporated by reference and "become"
part of the subject standard. Normative references play a key role in ensuring the consistency of the body of
International Standards by allowing work done by others to be reused without modification. The second type
of reference is an informative reference [ISOD2]. Identified provisions of an informative reference are cited as
being the source of, related to, or providing additional information about text in the subject standard, but the
identified provisions of the document are not themselves directly incorporated into the subject standard.
13.2.5.2 Citation format
Each citation consists of an identifier and an optional location enclosed in square brackets ( [ ] ) with the
identifier listed first, followed by a comma, followed by the location. The identifier specifies the cited document
and shall appear in either Clause 2 or the Bibliography. The location specifies the portion of the document that
is cited. Whenever possible, the location shall be specified in accordance with the requirements in [ISOD2].
When a cited document lacks a subclause structure, the location may be specified in a convenient and natural
format depending on the organization of the cited document.
EXAMPLE  [83502T, App. A-1, "HO"] and [RIIC, Table IV, "Saturn"].
13.3 Guidelines for specific SRM concepts
13.3.1 Guidelines for registration of abstract CSs
Abstract CSs shall be registered according to the following additional guidelines:
a) The function type shall be either “generating function” or “map projection”.
b) The CS descriptor shall be one of: 3D linear, 3D curvilinear, surface linear, surface curvilinear, map
projection, 2D linear, 2D curvilinear, 1D linear, 1D curvilinear, or surface (map projection) and 3D
(augmented map projection).
c) The CS properties shall be either “none” or a list of one or more properties of the CS chosen from the
following: orthogonal, not orthogonal, orthonormal, not orthonormal, conformal, or not conformal.
Conformal and not conformal only apply to map projections.
d) The CS parameters and constraints, if any, shall specify the parameters of the CS and constraints on
how those parameters interrelate.
e) The coordinate symbols and common names shall specify these symbols and terms as used in the
specification of coordinates in the CS. Thus in the case of the geodetic CS, “λ : longitude in radians,
ϕ : latitude in radians, and h : ellipsoidal height”.
f) The domain of the CS generating function or mapping equations shall be specified in terms of the
coordinate symbols and other CS parameters.
g) The CS generating function or mapping equations shall be specified in terms of the coordinate
symbols and other CS parameters. In the case of
...

INTERNATIONAL STANDARD
Information technology — Spatial Reference Model (SRM)
1 Scope
This International Standard specifies the Spatial Reference Model (SRM) defining relevant aspects of spatial
positioning and related information processing. The SRM allows precise and unambiguous specification of
geometric properties such as position (location), direction, and distance. The SRM addresses the needs of a
broad community of users, who have a range of accuracy and performance requirements in computationally
intensive applications.
Aspects of this International Standard apply to, but are not limited to:
a) mapping, charting, geodesy, and imagery;
b) topography;
c) location-based services;
d) oceanography;
e) meteorology and climatology;
f) interplanetary and planetary sciences;
g) embedded systems; and
h) modelling and simulation.
The application program interface supports more than 30 forms of position representat
...

8 Spatial reference frames
8.1 Introduction
A spatial coordinate system is a means of associating a unique coordinate with a point in object-space. It is
defined by binding an abstract CS to a normal embedding (see 8.2). A spatial reference frame is a
specification of a spatial coordinate system for a region of object-space (see 8.3). It is formed by the binding of
an abstract coordinate system to the normal embedding specified by an ORM for that object. A full
specification specifies the CS and the ORM and includes values for CS parameters, if any, and a specification
of the region of object-space. Some or all CS parameters may be bound by ORM parameters. In particular, a
CS based on an oblate ellipsoid (or sphere) must match the parameters of the oblate ellipsoid (or sphere) RD
of the ORM.
A spatial reference frame template is an abstraction of a collection of spatial reference frames that share the
same abstract coordinate system, coordinate system parameter binding rules, and similar ORMs that model
the same spatial object type (see 8.5). Spatial reference frames may be organized into specified sets so as to
form an atlas for a large region of space. This International Standard specifies a collection of spatial reference
frame templates, realizations of those templates, and sets of those realizations.
8.2 Spatial coordinate systems
If a normal embedding of position-space into object-space is defined, any abstract CS for a region of that
position-space can be used to specify a spatial CS that associates coordinates in coordinate-space to points
in object-space. This association is a binding of a CS via a normal embedding. The association is defined as:
p = E G c
( )
( )
where:
c is a coordinate in the CS domain,

G is the CS generating function,
E is the normal embedding function, and
p is the point in object-space associated with c.
CS generating function
G
v-axis
z-axis
z-axis
normal
embedding E
E( G ( c )) = p
G (c ) = (x , y, z)
c = ( u , v)
z z
y-axis
y-axis
y y
u-axis
origin
x x
x-axis
x-axis
position-space object-space
coordinate-space
Spatial CS association
Figure 8.1 — A spatial embedding of a surface CS
© ISO/IEC 2009 – All rights reserved
EXAMPLE  Figure 8.1 illustrates a spatial surface CS bound with a normal embedding of 3D position-space to the 3D
object-space. In this illustration, a surface coordinate (u, v) in coordinate-space is associated to a position (x, y, z) in the
abstract position-space. That position is then identified with a position in the space of an object via the normal embedding
of position-space. In this example, the normal embedding is determined by the selection of an origin and three unit points.
8.3 Spatial reference frame
8.3.1 Specification
A spatial reference frame (SRF) is a specification of a spatial coordinate system that is constructed from an
ORM and a compatible abstract CS, such that coordinates uniquely specify positions with respect to the
spatial object of the ORM. A specification of an SRF includes:
a) an ORM,
b) a CS compatible with the ORM,
c) a binding of all parameters of the spatial CS,
th
d) (optionally) k coordinate-component names,
e) (optionally) additional restrictions on the domain of valid coordinates in that spatial CS, and
f) (optionally) if the CS is of CS type 3D, a vertical coordinate-component identification (see 8.4).
An SRF implicitly specifies a spatial CS defined by the binding of the CS via the normal embedding associated
with the ORM.
Spatial CS compatibility and the other elements of the specification of an SRF are defined in the following
clauses.
8.3.2 SRF specification elements
8.3.2.1 ORM and CS compatibility
The compatible CS type of the CS element of an SRF depends on the dimension of the ORM. The dimension
of an ORM is defined as the dimension of the RD components of the specification of the ORM. The
compatible CS types by ORM dimension are specified in Table 8.1.
Table 8.1 — Compatible CS types
ORM dimension Compatible CS types
1D 1D CS
Curve CS
2D
2D CS
Curve CS
3D Surface CS
3D CS
The use of surface CSs or 3D CSs that are based on an oblate ellipsoid (or sphere) are restricted to ORMs
that are based on an oblate ellipsoid (or respectively, sphere) RD.
The surface CSs that are based on an oblate ellipsoid (or sphere) are:
© ISO/IEC 2009 – All rights reserved
a) surface geodetic,
b) surface planetodetic, and
c) all map projections.
The 3D CSs that are based on an oblate ellipsoid (or sphere) are:
a) geodetic 3D,
b) planetodetic 3D, and
c) all augmented map projections.
As a further restriction, some CSs are based on spheres only. CS OBLIQUE_MERCATOR_SPHERICAL has
this restriction.
An SRF may be described in terms of the properties and other characteristics of the CS that is specified by
the SRF. In particular, an SRF is said to be a 3D SRF, surface SRF, or 2D SRF if the CS of the SRF is of the
corresponding CS type. Similarly, the CS properties of linearity, orthogonality, and handedness may be used
as descriptors of an SRF corresponding to the properties of the CS that is specified by the SRF. Thus, an
SRF is said to be a linear SRF or a curvilinear SRF if the CS of the SRF has the respective linearity property.
Every 3D SRF in this International Standard is a right-handed SRF in consequence to the CS handedness
restriction imposed in 5.6.4.
8.3.2.2 CS parameter binding
All CS parameter values must be specified. In the case of a combination of a CS and an ORM based on an
oblate ellipsoid (or sphere), the major semi-axis and minor semi-axis (or equivalently, the inverse flattening)
(or respectively, sphere radius) of the ORM and CS shall match.
8.3.2.3 Coordinate-component names
A CS specification (see 5.9) includes the coordinate-component symbols with common names (if any). A
th
specification of an SRF may optionally assign SRF-specific names to the k coordinate-components. The
name assignment shall reflect the common use in the intended application domain.
th
EXAMPLE  For an equatorial spherical CS, the assignment of SRF-specific names to the k coordinate-components
of “right ascension” for λ, “declination” for θ , and “radius” for ρ.
8.3.2.4 Coordinate valid-region
A CS specification (see 5.9) includes the specification of the CS domain and CS range where the generating
function (or mapping equations) and its inverse(s) are defined. An SRF specification may further restrict the
CS domain. A valid-region is a restriction of the CS domain of the generating function (or mapping equations)
for a CS as used in an SRF. An extended valid-region is a second valid-region that contains the first valid-
region as a subset. The specification of these restrictions is important for several (SRF specific) reasons:
a) If the ORM is local, the restrictions are used to model, in coordinate-space, the local region of the
space of the object.
b) If the CS is a map projection or an augmented map projection, the restrictions are used to bound or
otherwise limit distortions (see 5.8.3.1).
© ISO/IEC 2009 – All rights reserved
c) The SRF may be used in conjunction with other SRFs to form an atlas for a large region (see 8.7 SRF
sets). In this case, the restrictions are used to control the pair-wise overlap of the spatial coverage of
members of the SRF collection.
d) If the CS generating function (or map projection mapping equations) or the inverse function(s) have
been implemented with a numerical approximation, the restrictions are used to control error bounds.
The extended valid-region is used primarily for overlapping regions in forming an atlas as in (c) above. Not all
properties of the SRF that are true in the valid-region will necessarily be true in the extended valid-region. In
particular, a distortion error bound that holds in the valid-region may not hold in the extended valid-region.
A valid-region may be described and/or specified. A valid-region description is a descriptive statement of the
region such as the spatial boundary of a named political entity.
EXAMPLE 1 “The German state of Baden-Wurttemberg” and “The Baltic Sea” are valid-region descriptions.
In this International Standard, a valid-region specification is a finite (or empty) list of coordinate-component
constraints of the form:
th
k coordinate-component belongs to a non-empty interval of real numbers I .
k
An extended valid-region specification is a finite (or empty) list of coordinate-component constraints of the
form:
th
k coordinate-component belongs to an interval of real numbers J , where I has been specified

k k
and J ⊇ I .
k k
Angular coordinate-component intervals shall be evaluated modulo 2π to represent an interval of the unit
circle. Thus, 4π 3,2π 3 representes the angular interval 4π 3,2π ∪ 0,2π 3 .
[ ] [ ) [ ]
In the case of an SRF with an oblate ellipsoid (or sphere) based ORM, celestiodetic coordinates may be
similarly constrained. In particular, valid-region specifications for a map projection based SRF may specify
coordinate-component constraints for easting, northing, latitude, and/or longitude. Celestiodetic longitude
intervals shall be evaluated modulo 2π. In particular, if the interval limits satisfyλ >λ , then:
1 2
λ ,λ = λ ,π ∪ (−π,λ ,
[ ] [ ] ]
1 2 1 2
λ ,λ = λ ,π ∪ −π,λ ,
( ] ( ] ( ]
1 2 1 2
λ ,λ = λ ,π ∪ −π,λ , and
[ ) [ ] ( )
1 2 1 2
λ ,λ = λ ,π ∪ −π,λ .
( ) ( ] ( )
1 2 1 2
EXAMPLE 2 The SRF is based on a transverse Mercator map projection (see SRFT TRANSVERSE_MERCATOR).
Valid-region specification:  167 000 ≤ u ≤ 833 000, 0 ≤ v ≤ 9 500 000
Extended valid-region specification: 0 < u,  -100 < v
In this example, I = 167 000,833 000 and I = 0,9 500 000 are closed bounded intervals, and
[ ] [ ]
Easting Northing
J = 0,+∞ and J = −100,+∞ are open semi-bounded intervals that are further constrained by the CS
( ) ( )
Easting Northing
domain.
EXAMPLE 3 The SRF is based on a transverse Mercator map projection (see SRFT TRANSVERSE_MERCATOR).
Valid-region specification:  -78º ≤ λ < -72º, 0º ≤ ϕ < 84º
Extended valid-region specification: -78,5º ≤ λ < -71,5º
In this example, I = −78⋅ π 180 , −72⋅ π 180 and I = 0,84⋅ π 180 are left-closed, right-open
[ ( ) ( )) [ ( ))
Longitude Latitude
bounded intervals, as is J = −78,5⋅ π 180 , −71,5⋅ π 180 . J is not specified. This indicates that there
[ ( ) ( ))
Longitude Latitude
are no constraints for latitude (except for the CS domain definition) in the extended valid-region specification.
© ISO/IEC 2009 – All rights reserved
8.4 SRF induced surface spatial reference frame
In the case of an SRF specified with the combination of a 3D ORM and a 3D CS, the 3D CS induces a surface
rd
CS on each coordinate-component surface (see 5.5.2). An SRF specification may optionally identify the 3
coordinate-component as the vertical coordinate-component for the SRF. In that case, the surface CS induced
on the zero-value vertical coordinate-component surface is the induced surface SRF for the specification. The
vertical coordinate-component is optionally specified in the coordinate-component name specification element
of the SRF.
rd
The CS GEODETIC and the CS PLANETODETIC 3 coordinate-components (h: ellipsoidal height), and the
rd
3 coordinate-component of any augmented map projection CS (h: ellipsoidal height) are identified in this
International Standard as the vertical coordinate-component. When an SRF is specified with any of these 3D
CSs, the h = 0 coordinate-component surface coincides with the surface of the oblate ellipsoid (or sphere) RD
of the ORM. Any SRF based on these CSs intrinsically specifies the corresponding surface CS on the oblate
ellipsoid (or sphere) RD surface.
In an SRF realized from the SRF template LOCAL_TANGENT_SPACE_EUCLIDEAN specification (see 8.5.6)
rd
or the SRF template LOCAL_TANGENT_SPACE_CYLINDRICAL specification (see 8.5.8), the 3 coordinate-
component, height, is specified as the vertical coordinate-component. In these cases, the zero-value vertical
coordinate-component surface is a plane parallel to the tangent plane at the SRF tangent point. SRF
templates are defined in 8.5.
rd
The zero-value 3 coordinate-component surface of an SRF realized from the 3D CS SRF template
LOCAL_TANGENT_SPACE_AZIMUTHAL_SPHERICAL specification (see 8.5.7) induces a lococentric
surface azimuthal CS on the tangent plane of the SRF. For the purpose of specifying an induced surface
reference frame, the 3rd coordinate-component θ, depression/elevation angle, is specified as a vertical
coordinate. The zero-value vertical coordinate-component surface is a plane parallel to the tangent plane at
the SRF tangent point.
SRF templates that are based on surface CSs that can be induced by a zero-value vertical coordinate-
component surface of an SRF based on a 3D CS are not separately specified. The induced surface CS is
noted in the corresponding 3D CS based SRF template specification.
NOTE  Starting with a 3D SRF, this International Standard identifies surface SRFs on coordinate-component
surfaces. The relationship between a surface CS and the 3D CS which induces it is functionally similar to, but conceptually
different from, the ISO 19111 concept of compound coordinate reference frame. A compound coordinate reference frame
synthesizes a 3D reference frame from a surface and a vertical system. (See also 5.8.6.1 and Clause 9.)
8.5 SRF templates
8.5.1 Introduction
A spatial reference frame template (SRFT) is an abstraction of a collection of SRFs that share the same
abstract CS, coordinate component names, CS parameter binding rules, and similar ORMs that model the
same spatial object type. An SRF template allows for a consistent derivation of SRFs. It is not necessary that
an appropriate SRFT be defined in order to define a new SRF; however in this International Standard all SRFs
are derived from SRFTs. The specification elements for SRFTs are defined in Table 8.2.
Table 8.2 — SRFT specification elements
Element Definition
SRFT label The label of the SRF template (see 13.2.2).
The code of the SRF template (see 13.2.3).
SRFT code
Code 0 (UNSPECIFIED) is reserved.
© ISO/IEC 2009 – All rights reserved
Element Definition
A short name as published or as commonly known and an
Short name and description
optional description.
One or more of: abstract, physical, Earth, planet, satellite, and
Object or object type
Sun; and, optionally, additional restrict
...

6 Temporal coordinate systems
6.1 Introduction
There is a requirement to identify time as well as location in environmental representation. Time is that
physical quantity perceived as the continued progress of existence measured by an observer as events which
are relatively ordered as “before” or “after” and which, at a given point in time, give rise to the notions of past,
present and future. Time and location are often used together by an application to describe when a given
condition exists or when an object was present at a given location.
This International Standard uses the concept of time in several ways. Dynamic systems are treated as
systems with a time parameter. These systems reduce to the case of a static relationship by fixing a value for
the time parameter. Object reference model bindings are often based on physical measurements of objects or
systems that change with time. Time is also used to identify the epoch for which these measurements are
applicable.
A temporal coordinate system is a Euclidean 1D CS (see Table 5.35) that assigns distinct coordinates to
distinct times so that larger coordinate values are assigned to later times. This International Standard uses
Coordinated Universal Time (UTC) (see 6.2.4) to provide a temporal coordinate system that enables a unique
temporal coordinate to be assigned to an event. In this International Standard, times and dates refer to UTC
unless explicitly indicated otherwise.
6.2 Temporal coordinate systems
6.2.1 Integrated and dynamic temporal coordinate systems
An integrated temporal coordinate system is a Euclidean 1D CS (see Table 5.35) based on a unit of duration
that is derived from a physical phenomenon. Fixing an origin (called the epoch) and then integrating
continuously by accumulating units of the duration specifies an integrated temporal coordinate system.
EXAMPLE  The wave length of certain atomic energy emissions determine a wave period which serves as the
physical duration that is accumulated to specify atomic clock time.
A dynamic temporal coordinate system is a Euclidean 1D CS (see Table 5.35) based on data derived from the
observation of a dynamic physical system, typically planetary motion. The specification of a dynamic temporal
coordinate system depends on the observed system being described by a mathematical model where time is
one of the parameters that unambiguously identifies the configuration of the system. The time measurement
can then be considered to be a measurement of position with units defined as a specified duration. Fixing an
origin by specifying the initial conditions of the physical system and then continuously accumulating units of
the duration specifies a dynamic temporal coordinate system.
A dynamic temporal coordinate system differs from an integrated temporal coordinate system in that the
former ties a mathematical model to the state of a physical system while the latter accumulates the duration of
a periodic phenomenon.
6.2.2 Universal time
Universal time (UT) is a general designation of a set of dynamic temporal coordinate systems based on the
rotation of the Earth. There are different forms of UT whose values may differ by a few hundredths of a
second:
a) Universal Time observed (UT0) is the mean solar time of the prime meridian obtained from direct
astronomical observation.
© ISO/IEC 2009 – All rights reserved

b) Universal Time polar motion corrected (UT1) is UT0 corrected for the effects of small movements of
the Earth relative to the axis of rotation (polar variation).
c) Universal Time Earth rotation corrected (UT2) is UT1 corrected for the effects of a small seasonal
fluctuation in the rate of rotation of the Earth.
Complete definitions of UT0, UT1, UT2, and the concepts involved in their definitions may be found in the
publications of the International Earth Rotation Service [IERS] that maintains these three temporal coordinate
systems.
6.2.3 International atomic
...

3 Terms, definitions, symbols, and abbreviated terms
3.1 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
NOTE  Symbols or abbreviations used as representations for the term are listed immediately following the term. After
the definition, where necessary, an additional clarifying note may be provided. Terms defined in the body of this document
are presented in italics at the point where they are defined. The Index provides a directory of those terms defined in the
body of this International Standard.
3.1.1
Earth gravitational model
spherical harmonic expansion of the gravitational field potential
NOTE  Rotational effects are not included in this model; gravity includes rotational effects.
3.1.2
ecliptic plane
plane defined by the orbit of a planet at a point in time
3.1.3
equatorial plane
plane through a designated centre of an object and normal to the rotational axis of the object
3.1.4
geodetic datum
datum describing the relationship of a coordinate system to the Earth
[ISO 19111]
NOTE  In most cases, the geodetic datum includes an ellipsoid definition.
3.1.5
north pole
that pole of rotation that lies on the north side of the invariable plane of the solar system
[RIIC]
NOTE 1 Some planets have retrograde rotation with respect to this definition.
NOTE 2 Map north (see Clause 5) may be unrelated to this direction.
3.1.6
spatial object
physical or virtual object to which spatial information applies
3.1.7
spatial operation
mathematical function that re-expresses coordinates, directions, and/or distances expressed in one spatial
reference frame in terms of a different spatial reference frame or a mathematical function for distance or other
geometric quantities within a single spatial reference frame
3.2 Notation, symbols and abbreviated terms
Table 3.1 lists the mathematical notation conventions used in this document.
© ISO/IEC 2009 – All rights reserved

Table 3.1 — Mathematical notation

Style Use Examples
lower case, bold, points, vectors x, p
italic
lower case, italic variables, scalars, a, b, f, x-axis
scalar-valued functions,
axes of a linear
coordinate system
upper case, bold, vector-valued functions, F, G, M
italic matrices
upper case, italic sets S, T
Upper case italic letter symbols are also used for scalar-valued functions that are customarily capitalized.
EXAMPLE  R in Table 5.6.
N
Table 3.2 lists the symbols used in this document.
Table 3.2 — Symbols
Symbol Definition
...

Contents Page
Foreword.xix

0    Introduction.xxi
0.1    Purpose .xxi
0.2    Design criteria.xxi

1 Scope . 1

2 Normative references. 3

3 Terms, definitions, symbols, and abbreviated terms . 5
3.1 Terms and definitions. 5
3.2 Notation, symbols and abbreviated terms. 5

4 Concepts . 9
4.1 Introduction . 9
4.2 Spatial objects and object-space . 10
4.3 Position-space and normal embeddings. 11
4.4 Reference datums. 13
4.5 Object reference models. 15
4.6 Coordinate systems . 17
4.6.1 Abstract coordinate systems. 17
4.6.2 Temporal coordinate systems. 20
4.6.3 Spatial coordinate systems . 20
4.7 Spatial reference frames. 22
4.8 Designated spatial surfaces and vertical offsets. 23
4.9 Spatial reference frame operations. 24
4.10 Application program interface . 25
4.11 SRM units. 25
4.12 Profiles . 25
4.13 Registration . 25

5 Abstract coordinate systems. 27
5.1 Introduction . 27
5.2 Preliminaries . 27
5.3 Abstract CS . 27
5.4 CS types. 29
5.5 Coordinate surfaces, induced surface CSs, and coordinate curves. 30
5.5.1 Introduction . 30
5.5.2 Coordinate-component surfaces and induced surface CSs . 30
5.5.3 Coordinate-component curves. 31
5.6 CS properties . 32
5.6.1 Linearity. 32
5.6.2 Orthogonality. 33
5.6.3 Linear CS properties: Cartesian, and orthonormal . 33
5.6.4 CS right-handedness and coordinate-component ordering. 33
5.7 CS localization . 34
5.8 Map projection coordinate systems . 35
5.8.1 Map projections. 35
5.8.2 Map projection as a surface CS. 36
5.8.3 Map projection geometry. 37
5.8.4 Relationship to projection functions . 40
5.8.5 Map projection CS common parameters . 43
5.8.6 Augmented map projections . 44
iii
© ISO/IEC 2009 – All rights reserved

5.9 CS specifications.45
5.9.1 Specification table elements and common functions and parameters.45
5.9.2 Euclidean 3D CS specification .49
5.9.3 Lococentric Euclidean 3D CS specification.50
5.9.4 Spherical CS specification.51
5.9.5 Lococentric spherical CS specification.53
5.9.6 Azimuthal spherical CS specification .54
5.9.7 Lococentric azimuthal spherical CS specification .56
5.9.8 Geodetic 3D CS specification.57
5.9.9 Planetodetic 3D specification .60
5.9.10 Cylindrical CS specification.62
5.9.11 Lococentric cylindrical CS specification .63
5.9.12 Mercator CS specification .64
5.9.13 Oblique Mercator spherical CS specification .67
5.9.14 Transverse Mercator CS specification .70
5.9.15 Lambert conformal conic CS specification .74
5.9.16 Polar stereographic CS specification .77
5.9.17 Equidistant cylindrical CS specification.80
5.9.18 Surface geodetic CS specification .82
5.9.19 Surface planetodetic CS specification.84
5.9.20 Lococentric surface Euclidean CS specification .85
5.9.21 Lococentric surface azimuthal CS specification.87
5.9.22 Lococentric surface polar CS specification .88
5.9.23 Euclidean 2D CS specification .90
5.9.24 Lococentric Euclidean 2D CS specification.91
5.9.25 Azimuthal CS specification.93
5.9.26 Lococentric azimuthal CS specification.94
5.9.27 Polar CS specification .95
5.9.28 Lococentric polar CS specification .96
5.9.29 Euclidean 1D CS specification .98

6 Temporal coordinate systems .101
6.1 Introduction.101
6.2 Temporal coordinate systems .101
6.2.1 Integrated and dynamic temporal coordinate systems .101
6.2.2 Universal time.101
6.2.3 International atomic time .102
6.2.4 Coordinated universal time.102
6.3 Specified temporal coordinate systems .102
6.4 Registered temporal coordinate systems.103

7 Reference datums, embeddings, and object reference models.105
7.1 Introduction.105
7.2 Reference datums.105
7.2.1 Introduction.105
7.2.2 Reference datums.105
7.2.3 Ellipsoidal RDs .108
7.2.4 RDs associated with physical objects .109
7.2.5 RD binding.111
7.3 Normal embeddings of position-space into object-space .111
7.3.1 Normal embeddings .111
7.3.2 Specification of 3D similarity transformations .112
7.3.3 Specification of 2D similarity transformations .114
7.4 Object reference model.114
7.4.1 Introduction.114
7.4.2 ORM .115
7.4.3 Binding constraint.116
7.4.4 ORM template .
...