ISO/IEC 18026:2025

Information technology — Spatial reference model (SRM)

This document 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, direction, orientation, 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 document 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 SRM specifies an application program interface (API) that supports the representations, conversion, and transformation of position and orientation information in a variety of forms. To ensure that spatial operations are performed consistently, the application program interface specifies conversion operations between alternative representations of geometric properties. This document is not intended to replace the standards and specifications developed by ISO/TC 211, ISO/TC 184, the International Astronomical Union (IAU), and the International Association of Geodesy (IAG). It is applicable to applications whose spatial information requirements overlap two or more of the application areas that are the scope of the work of ISO/TC 211, ISO/TC 184, the IAU, and the IAG.

Technologies de l'information — Modèle de référence spatial (SRM)

General Information

• Status: Published
• Publication Date: 10-Jul-2025
• ICS: 35.140 - Computer graphics
• Technical Committee: ISO/IEC JTC 1/SC 24 - Computer graphics, image processing and environmental data representation
• Drafting Committee: ISO/IEC JTC 1/SC 24 - Computer graphics, image processing and environmental data representation
• Current Stage: 6060 - International Standard published
• Start Date: 11-Jul-2025
• Due Date: 23-May-2025
• Completion Date: 11-Jul-2025

Relations

• Revises: ISO/IEC 18026:2009 - Information technology — Spatial Reference Model (SRM)
• Effective Date: 27-May-2023

Standards Content (Sample)

Annex A
(normative)
Mathematical foundations
A.1 Overview
This annex identifies the concepts from mathematics used in this document and specifies the notation used for
those concepts. A reader of this document 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].
�
A.2 ℝ as a real vector space
An ordered set of � real numbers � where � is a natural number is termed an �-tuple of real numbers and shall
� �
� �
be denoted by � = � , � , � ,⋅⋅⋅ , � The set of all �-tuples of real numbers is denoted by ℝ . ℝ is an �-
� � � �
dimensional vector space.
�
The canonical basis for ℝ is defined as:

� � � � � �
� = 1,0,⋅⋅⋅ ,0 , � = 0,1,⋅⋅⋅ ,0 ,⋅⋅⋅, � = 0,0,⋅⋅⋅ ,1 .
� � �
�
The elements of ℝ may be termed 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 �.
�
Definitions A.2(a) through A.2(j) apply to any vectors � = �� , � ,⋅⋅⋅, � � and � = �� , � ,⋅⋅⋅, � � in ℝ :
� � � � � �
a) The inner product or dot-product of two vectors � and � is defined as:

� • � = � � + � � +⋅⋅⋅ +� � .
� � � � � �
b) Two vectors � and � are termed orthogonal if � • � = 0.
c) If � ≥ 2, two vectors � and � are termed perpendicular if and only if they are orthogonal.
‖ ‖‖ ‖
NOTE 1 If � ≥ 2, � • � = � � cos��� where � is the angle between � and �.
d) � is termed orthogonal to a set of vectors if � is orthogonal to each vector that is a member of the set.
e) The norm of � is defined as

‖�‖ = � • �.
√
NOTE 2 The norm of � represents the length of the vector �. Only the zero vector � has norm zero.
f) � is termed a unit vector if ‖�‖ = 1.
g) A set of two or more orthogonal unit vectors is termed an orthonormal set of vectors.
EXAMPLE  The canonical basis is an example of an orthonormal set of vectors.
h) The Euclidean metric � is defined by

� � ‖ ‖
� �, � = � − � .
i) The value of ���, �� is termed the Euclidean distance between � and �.
© ISO/IEC 2025 – All rights reserved 441

�
j) The cross product of two vectors � and � in ℝ is defined as the vector:

� �
� × � = � � − � � , � � − � � , � � − � � .
� � � � � � � � � � � �
NOTE 3 The vector � × � is orthogonal to both � and �, and

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

�� �� ��
������� = � , ,⋅⋅⋅, �.
�� �� ��
� � �
�
Definitions A.4(a) through A.4(g) apply to any vector-valued function � defined on a replete domain � in ℝ with
�
range in ℝ .
��
a) The � -component function of a vector-valued function � is the real-valued function � defined by
�
��
� = � • � where e is the � canonical basis vector, � = 1,  2,⋅⋅⋅, �.
j
� �
442 © ISO/IEC 2025 – All rights reserved

In this case:
���� = �� ���, � ���, � ���, … , � ���� for � = �� , � , � , … , � � in �.
� � � � � � � �
b) � is termed smooth if each component function � is smooth.

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

��
�
� � � = 1,  2,⋅⋅⋅, � and � = 1,2, ⋅⋅⋅ , �.
��
�
d) The Jacobian matrix of � at the point � is the matrix of the first derivative of �.
NOTE 1 The rows of the Jacobian matrix are the gradients of the component functions of �.
e) In the case � = �, the Jacobian matrix is square, and its determinant is termed the Jacobian
determinant.
f) In the case � = �, � is termed orientation preserving if its Jacobian determinant is strictly positive for
all points in �.
�
g) A vector-valued function � defined on ℝ is linear if:

�
���� + �� = ����� + ���� for all real scalars � and vectors � and � in ℝ
NOTE 2 All linear functions are smooth.
�
� � � � � �
A vector-valued function � defined on ℝ is affine if �, defined by � � = � � − � � , is a linear function. All
�
affine functions on ℝ are smooth.
A function may be alternatively termed 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.3.6.2).
A.5 Functional composition
If � and � are two vector valued functions and the range of � is contained in the domain of �, then � ∘ �, the
composition of � with �, is the function defined by � ∘ ���� ≡ �������. � ∘ � has the same domain as �, and the
range of � ∘ � is contained in the range of �.
Functional composition also applies to scalar-valued functions � and �, If the range of � is contained in the
� � � � � �
domain of �, then � ∘ � � , the composition of � with �, is the function defined by � ∘ � � ≡ ��� � �.
�
A.6 Smooth surfaces in ℝ
A.6.1 Implicit definition
� �
A smooth surface in ℝ is implicitly specified by a real-valued smooth function � defined on ℝ as the set � of
�
all points ��, �, �� in ℝ satisfying:
� �
a) � �, �, � = 0 and
b) ���������, �, �� ≠ �.
In this case, � is termed a surface generating function for the surface �.
�
EXAMPLE 1 If � ≠ � and � are vectors in ℝ and ���� = � • �� − ��, then � is smooth and ������� = � ≠ �. The plane
which is perpendicular to � and contains � is the smooth surface implicitly defined by the surface generating function �.
© ISO/IEC 2025 – All rights reserved 443

Special cases:
When � = �1,0,0� and � = �, the ��-plane is implicitly defined.
When � = �0,1,0� and � = �, the ��-plane is implicitly defined.
When � = �0,0,1� and � = �, the ��-plane is implicitly defined.
The surface normal � at a point � = ��, �, �� on the surface implicitly specified by a surface generating function
� is defined as:
� �� �
� ≡ ���� � � .
‖����������‖
NOTE  −� is also a surface normal to � at �. The surface generating function � determines the surface normal direction:
� or −�.
The tangent plane to a surface at a point � = ��, �, �� on the surface � implicitly defined by a surface generating
function � is the plane which is the smooth surface implicitly defined by ℎ��� = � • �� − �� where � is the surface
normal to � at �.
EXAMPLE 2 If � and � are positive non-zero scalars, define

� � �
� � �
� �
� �, �, � = + + − 1.
� � �
� � �
Then � is smooth and
2� 2� 2�
���������, �, �� = � , , �
� � �
� � �
is never �0, 0, 0� on the surface implicitly specified by the set satisfying � = 0.
A.6.2 Ellipsoid surfaces
If � and � are positive non-zero scalars, the smooth function:

� � �
� � �
� �
� �, �, � = + + − 1
� � �
� � �
is a surface generating function for an ellipsoid of revolution smooth surface �.
When � ≤ �, the surface is termed an oblate ellipsoid. In this case � is termed the major semi-axis of the
oblate ellipsoid and � is termed the minor semi-axis of the oblate ellipsoid.
���
The flattening of an oblate ellipsoid is defined as � = .
�
�
The eccentricity of an oblate ellipsoid is defined as � = �1 − ��⁄�� .
� �
The second eccentricity of an oblate ellipsoid is defined as � = ���⁄�� − 1.
When � = �, the oblate ellipsoid may be termed a sphere of radius � = � = �.
When � > �, the surface is termed a prolate ellipsoid. In this case, � is termed the minor semi-axis of the prolate
ellipsoid and � is termed the major semi-axis of the prolate ellipsoid.
� � � �
NOTE 1 A sphere of radius � is also implicitly defined by the surface generating function ���, �, �� = � + � + � − � .
NOTE 2 The term spheroid is often used to denote an oblate ellipsoid with an eccentricity close to zero (“almost
spherical”).
� is half the length of the major axis. ISO 19111 labels the symbol � as the semi-major axis.
444 © ISO/IEC 2025 – All rights reserved

�
A.7 Smooth curves in ℝ
A.7.1 Parametric definition
A.7.1.1 Smooth curve
� �
A smooth curve in ℝ is parametrically specified by a smooth one-to-one ℝ valued function �(�) defined on a
replete interval � in ℝ such that ‖��(�)‖ � 0, for any � in �.
�
EXAMPLE 1 If � and � are vectors in ℝ such that � � � and �(�) � � � � �, �∞ � � � �∞, then � is smooth and
‖��(�)‖ � ‖�‖ � 0. The line which is parallel to � and which contains � is a smooth curve parametrically specified by �.
EXAMPLE 2 If � and � are positive non-zero scalars and � � �, define

� � � � � � ��
� � � � cos � , � sin � for all � in the interval �� � � � �.
�
Then � is smooth and ‖�����‖ � � � 0 for all � in the interval and therefore parametrically specifies a smooth curve in ℝ .
�
An ellipse in ℝ with major semi-axis � and minor semi-axis �, 0 � � � �, is parametrically specified by:

� � � � � � ��
� � � � cos � , � sin � for all � in the interval �� � � � �.
A.7.1.2 Tangent to a smooth curve
� �
If � � parametrically specifies a smooth curve � passing through a point � � ��� �, the tangent vector to � at
�
� shall be defined as:
� � ���� �
�
����� ��
�
where ���� � � �d� ⁄d�, d� ⁄d�, … , d� ⁄d� � is the first derivative of � evaluated at � .
� � � � �
� �
NOTE  �� is also a tangent vector to � at �. The parameterization function � � determines the tangent vector direction:
� or ��.
A locus of points is a directed curve if it is the range of a smooth curve.
The tangent line to the curve � at � is a smooth curve parametrically specified by ���� � � � � �, �∞ � � � �∞,
where � is a tangent vector to � at �. See Figure A.1.

Figure A.1 — Tangent to a curve
© ISO/IEC 2025 – All rights reserved 445

A.7.1.3 Angle between curves
If two parametrically specified smooth curves � and � intersect at a point � then the angle at � from � to �
� � � �
is defined as the (smaller) angle from the tangent vector � to the tangent vector � of the two curves,

� �
respectively, at �. This is illustrated in Figure A.2.

Figure A.2 — Angle between two curves
If a smooth curve � passes through a non-polar point � on an ellipsoid and the meridian at � is parameterized
to start at the south pole and end at the north pole, then the azimuth of � at � is the clockwise angle at � from
the meridian to �.
A.7.1.4 Closed curve
If a smooth function � is defined on a closed and bounded interval � with interval end points � and � and if �
� �
parametrically specifies a smooth curve on the interior of � and � � �(� ) � �(� ), then � generates a closed
� �
curve through �.
�(�) � (� cos(�) , � sin(�)), for all � in the interval �� � � � � � � � �.
EXAMPLE
If � and � are positive non-zero scalars and � is given, � generates a closed curve though � � (� cos(� � �) , � sin(� � �)).
A.7.1.5 Surface curves, connected and orientable surfaces
�
If � is a smooth curve in ℝ parametrically specified by � on the interval � and if � is a smooth surface generated
( )
by a surface generating function �, then � is a surface curve in � if � ∘ � � � 0 for all � in �. In this case � shall
be said to lie in �.
EXAMPLE 1 If � is a smooth surface with generating function � and if ���� defines a surface curve in � which passes
( )
through � � ��� �, then the tangent line to the curve at �, � � � � � ����� �, lies in the tangent plane to the surface � at
� �
�. This is illustrated in Figure A.3.

Since � ∘ �(�) � 0, the chain rule implies that ������� • �� � ��� ∘ �����⁄d� � 0, so that � • �� � 0, where � is the
surface normal at �. ℎ��� � � • �� � �� defines the tangent plane to the surface � at �. ℎ������ � ℎ �� � ����� �� � � •
�
� �
�� � ����� � � �� � � � • �� � 0, so the tangent line lies in the tangent plane.
�
446 © ISO/IEC 2025 – All rights reserved

Figure A.3 — Tangent plane to a surface
A smooth surface � is connected if for any two distinct points in �, there exists a smooth surface curve
parametrically specified by a smooth function defined on a bounded interval that lies in � and that contains the
two points on the curve.
A connected surface � is termed an orientable surface if the normal vector at an arbitrary point � in � can be
continued in a unique and continuous manner to the entire surface. A normal vector at a fixed point � may be
�
continued if there does not exist a closed curve � in � through � such that the normal vector direction reverses
�
when it is displaced continuously from � along � and back to � .
� �
An oriented surface is an orientable surface in which one side has been designated as positive.
EXAMPLE 2 If � is implicitly defined by � � 0, the side bounding the set satisfying � � 0 is designated as the positive
side.
EXAMPLE 3 A Möbius strip is an example of a non-orientable surface.
NOTE  If � is implicitly specified, it is an orientable surface .
A.7.2 Implicit definition
� �
A smooth curve in ℝ may be implicitly specified by a real-valued smooth function � on ℝ as the set � of all
�
� �
points �, � in ℝ satisfying:
a) ���, �� � 0 and
b) �
...

Annex B
(informative)
Implementation guidelines
B.1 Overview
This informative annex provides advisories relative to the implementation of the spatial operations contained in
this document. Implementations may introduce errors of various kinds. Since the term error has many different
meanings, depending on the application, a brief description of each of the various types of error referenced in
this document is included in this annex. This discussion is intended to clarify the meaning of the types of errors
as they relate to compliance.
B.2 Error types considered in this document
The term error has many meanings in common usage of the language. A dictionary definition might contain
definitions such as:
a) the failure of a computer program to produce an anticipated result, such as a result not falling within an
expected range,
b) a variation between the true value of a mathematical quantity and a calculated or measured value, or
c) a mistake as in an implementation or in the use of an implementation.
These are the error terms that are the most important to this document. The term error is often defined in terms
of words that themselves have alternative meanings. When used in a scientific or technical sense a modifying
adjective is often used for specificity. In this document, modifying adjectives are used to provide this specificity.
In most cases the definitions of such terms are defined where used.
B.2.1 Measurement and modelling error
In many applications and in particular in geodesy, statistical models are often used to define and characterize
the error in developing reference models. This process is quite detailed, but it suffices to provide a simplified
example. Measurements taken on an appropriate set of points are used to develop the reference model. This
process utilizes an assumed mathematical model for the shape of the Earth, usually an oblate ellipsoid or portion
thereof, formulated in terms of a geocentric coordinate system with its origin at the centre of mass of the Earth.
Free parameters are adjusted in the model to provide a minimum variance fit to the nominal surface of the real
Earth. In this way most of the local Earth reference models (or datums), such as ORM EUROPE_1950, are
developed. The root-mean-square difference between the measured points and the points computed from the
reference model is termed the residual error or standard error. Other expressions of measurement error such
as tolerance or maximum error or error interval are also in use.
In this document the reference models used are taken to be exact, that is, to have zero residual error. However,
when specifying such reference models residual error values may be given with the reference model parameters
for completeness. It is emphasized that errors associated with functional conformance in this document do not
include residual errors or tolerance.
© ISO/IEC 2025 – All rights reserved 459

B.2.2 Implementation error
Conformance compliance in this document is focused on the notion of implementation error. Implementation
error consists primarily of:
a) use of an incorrect mathematical formulation,
b) coding error such that a user error is not detected,
c) coding errors by which the mathematical formulation is incorrectly implemented,
d) excessive round-off error in the implementation of a mathematical formulation,
e) approximations used to speed up computations that cause excessive approximation error,
f) a formulation or implementation does not compensate for singularities or near singularities at some
points in the valid domain of the formulation, or
g) results that lie outside a valid range not detected by the implementation.
The process of evaluating implementation errors is, itself, subject to user error including:
a) user error such as selecting the wrong Earth reference model,
b) user error in trying to employ the software outside an applicable region, and
c) user error in trying to test the software outside a valid conformance region.
B.2.3 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 � is a real number, its representation on a
digital computer can be denoted as � . The difference between � and � is termed digitization 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. Loss of significance can occur
in computing the differences of numbers with large absolute values and the products of relatively small numbers
with large numbers.
Finite precision also can lead to excessive round-off error. The round-off error usually depends on the algorithm
employed. Sometimes the round-off error can be minimized by a different algorithm design.
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 (see ISO/IEC/IEEE 60559) arithmetic
for floating-point operations.
B.2.4 Approximation error
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 xa is the 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 termed 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-world 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
460 © ISO/IEC 2025 – All rights reserved

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 General observations on implementations
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 document. 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 document.
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.
For computationally intense applications most of the mathematical formulations contained in this document are
not appropriate for direct 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.4 Guidelines for algorithm development for spatial operations
B.4.1 Overview
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.4.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
© ISO/IEC 2025 – All rights reserved 461

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),
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 ISO/IEC/IEEE 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 termed
“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.4.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 i
...

Annex C
(informative)
Hierarchical diagrams for SRM concepts
C.1 Overview
This annex presents several diagrams that illustrate SRM concepts and their relationships. An overview of SRM
concepts and their relationships is presented in C.2. The hierarchy of reference datum categories is presented
in C.3. In C.4, examples of the use of ORM templates to define ORMs are presented.
C.2 SRM concepts
Figure C.1 illustrates the relationships among many of the key SRM concepts as a class diagram. This diagram
augments the overview of SRM concepts provided in 4.1. The shaded elements are those concepts that appear
in the SRM API (Clause 11), and that can be registered (Clause 13). In the connectors, unfilled (white) diamonds
denote aggregation while filled (black) diamonds denote composition, which only applies to the members of
Spatial Reference Frame sets. The remaining connectors denote associations, with arrowheads indicating the
direction of navigability when the association is not bi-directional.

Figure C.1 — SRM concepts and their relationships
C.3 Reference datum hierarchy
Figure C.2 illustrates the hierarchical structure of reference datum (RD) categories and instances. This diagram
augments the content of 7.2. The shaded elements are RD categories. RDs are organized into zero-dimensional
points in 2D and 3D that represent the origin and axis unit points of orthonormal frames, one-dimensional
directed curves in 2D and 3D that represent axes, and three-dimensional oriented surfaces that represent
planes, spheres, and oblate, prolate, and tri-axial ellipsoids. A few examples of the sphere and ellipsoid RDs
defined in Annex D are shown.
© ISO/IEC 2025 – All rights reserved 469

Figure C.2 — Reference datum hierarchy
C.4 ORM template realisation examples
Figures C.3 through C.5 show three examples of ORMs that realise ORM templates (ORMTs). These examples
augment the content of 7.4.4. The shaded elements are RD categories.
Example 1 In Figure C.3, the SPHERE ORMT requires three RDs: a sphere RD, a Z_AXIS_3D RD that defines the
rotational axis of the sphere,
...

Annex D
(normative)
RDs associated with physical objects
D.1 Overview
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.
Abbreviated forms used in labels in this annex are defined in Annex F.
D.2 RDs
The elements of a physical object RD specification are defined in Table 7.9. Table D.1 is a directory of RDs
associated with physical objects and is 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
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 2025 – All rights reserved
Table D.2 — Oblate ellipsoid RD specifications
Parameters
RD
RD label Description Date References
code
Major semi-axis,
Flattening,  Error estimate
Object type: Earth
AIRY_1830 17 Airy 6 377 563,396 1/299,324 964 6 Assumed precise 1830 [NGA36, App. C-1,
"AA"]
APL_4r5_1968 20 APL 4.5 6 378 144 1/298,23 Unknown 1968 [DIGEST, Table 6.1,
"AP"]
AUSTRALIAN_NATIONAL_1966 23 Australian National 6 378 160 1/298,25 Assumed precise 1966 [ISOGR, Identifier 29]
AVERAGE_TERRESTRIAL_1977 24 Average Terrestrial 6 378 135 1/298,257 Unknown 1977 [ISOGR, Identifier 26]
System
BESSEL_1841_ETHIOPIA 26 Bessel (Ethiopia, 6 377 397,155 1/299,152 812 8 Assumed precise 1841 [NGA36, App. C-1,
Indonesia, Japan, and "BR"]
Korea)
BESSEL_1841_NAMIBIA 27 Bessel (Namibia) 6 377 483,865 1/299,152 812 8 Assumed precise 1841 [NGA36, App. C-1,
"BN"]
BESSEL_MODIFIED 156 Bessel - modified 6 377 492,018 1/299,152 812 8 Unknown 1841 [DIGEST, Table 6.1,
"BM"]
CLARKE_1858 33 Clarke 6 378 235,6 1/294,260 676 8 Unknown 1858 [DIGEST, Table 6.1,
"CA"]
CLARKE_1858_MODIFIED 34 Clarke - modified 6 378 293,645 1/294,26 Unknown 1858 [DIGEST, Table 6.1,
"CB"]
CLARKE_1866 35 Clarke 6 378 206,4 1/294,978 698 2 Assumed precise 1866 [NGA36, App. C-1,
"CC"]
CLARKE_1880 36 Clarke 6 378 249,145 1/293,465 Assumed precise 1880 [NGA36, App. C-1,
"CD"]
© ISO/IEC 2025 – All rights reserved
Parameters
RD
RD label Description Date References
code
Major semi-axis,
Flattening,  Error estimate
CLARKE_1880_CAPE 37 Clarke - Cape 6 378 249,145 1/293,466 307 7 Unknown 1880 [DIGEST, Table 6.1,
"CE"]
CLARKE_1880_FIJI 38 Clarke - Fiji 6 378 301 1/293,465 Unknown 1880 [DIGEST, Table 6.1,
"CJ"]
CLARKE_1880_IGN 39 Clarke - IGN 6 378 249,2 1/293,466 020 8 Assumed precise 1880 [NGA36, App C-1,
"CG"]
CLARKE_1880_PALESTINE 40 Clarke - Palestine 6 378 300,782 1/293,466 307 7 Unknown 1880 [DIGEST, Table 6.1,
"CF"]
CLARKE_1880_SYRIA 41 Clarke - Syria 6 378 247,842 1/293,466 351 7 Unknown 1880 [DIGEST, Table 6.1,
"CI"]
DANISH_1876 45 Danish - Andrae 6 377 104,430 1/300 Unknown 1876 [DIGEST, Table 6.1,
"DA"]
DELAMBRE_1810 47 Delambre 6 376 985,228 1/308,64 Unknown 1810 [DIGEST, Table 6.1,
"DB"]
EVEREST_1948 57 Everest 1948 definition 6 377 304,063 1/300,801 7 Assumed precise 1948 [NGA36, App. C-1,
(West Malaysia and "EE"]
Singapore)
EVEREST_1956 58 Everest 1956 definition 6 377 301,243 1/300,801 7 Assumed precise 1956 [NGA36, App. C-1,
(India) "EC"]
EVEREST_1969 60 Everest 1969 definition 6 377 295,664 1/300,801 7 Assumed precise 1969 [NGA36, App. C-1,
(West Malaysia) "ED"]
EVEREST_ADJ_1937 56 Everest 1830 - adjusted 6 377 276,345 1/300,801 7 Assumed precise 1937 [NGA36, App. C-1,
(India) "EA"]
EVEREST_BRUNEI_1967 61 Everest 1830 - 1967 6 377 298,556 1/300,801 7 Assumed precise 1967 [NGA36, App. C-1,
definition (Brunei and "EB"]
East Malaysia - Sabah
and Sarawak)
© ISO/IEC 2025 – All rights reserved
Parameters
RD
RD label Description Date References
code
Major semi-axis,
Flattening,  Error estimate
EVEREST_REVISED_1962 59 Everest 1830 - revised 6 377 309,613 1/300,801 7 Assumed precise 1962 [NGA36, App. C-1,
definition (Pakistan) "EF"]
FISCHER_1960 62 Fischer - Mercury 6 378 166 1/298,3 Unknown 1960 [DIGEST, Table 6.1,
"FM"]
FISCHER_1968 63 Fischer 6 378 150 1/298,3 Unknown 1968 [DIGEST, Table 6.1,
"FC"]
GRS_1967 67 GRS 6 378 160 1/298,247 167 4 Unknown 1967 [DIGEST, Table 6.1,
"RE"]
GRS_1980 68 GRS 6 378 137 1/298,257 222 101 Assumed precise 1980 [NGA36, App. C-1,
"RF"]
HELMERT_1906 70 Helmert 6 378 200 1/298,3 Assumed precise 1906 [NGA36, App. C-1,
"HE"]
HOUGH_1960 72 Hough 6 378 270 1/297 Assumed precise 1960 [NGA36, App. C-1,
"HO"]
IAG_1975 74 IAG Best Estimate 6 378 140 1/298,257 Unknown 1975 [DIGEST, Table 6.1,
"IA"]
INDONESIAN_1974 77 Indonesian 6 378 160 1/298,247 Assumed precise 1974 [NGA36, App. C-1, "ID"]
INTERNATIONAL_1924 78 International 6 378 388 1/297 Assumed precise 1924 [NGA36, App. C-1, "IN"]
KRASSOVSKY_1940 84 Krassovsky 6 378 245 1/298,3 Assumed precise 1940 [NGA36, App. C-1,
"KA"]
KRAYENHOFF_1827 85 Krayenhoff 6 376 950,4 1/309,65 Unknown 1827 [DIGEST, Table 6.1,
"KB"]
MODIFIED_AIRY_1849 97 Modified Airy 6 377 340,189 1/299,324 964 6 Assumed precise 1849 [NGA36, App. C-1,
"AM"]
MODIFIED_FISCHER_1960 98 Modified Fischer 6 378 155 1/298,3 Assumed precise 1960 [NGA36, App. C-1,
"FA"]
© ISO/IEC 2025 – All rights reserved
Parameters
RD
RD label Description Date References
code
Major semi-axis,
Flattening,  Error estimate
PLESSIS_MODIFIED_1817 115 Plessis - modified 6 376 523 1/308,64 Unknown 1817 [DIGEST, Table 6.1,
"PM"]
SOUTH_AMERICAN_1969 125 South American 6 378 160 1/298,25 Assumed precise 1969 [NGA36, App. C-1,
"SA"]
SOVIET_GEODETIC_1985 126 Soviet Geodetic System 6 378 136 1/298,257 Unknown 1985 [DIGEST, Table 6.1,
"SG"]
SOVIET_GEODETIC_1990 127 Soviet Geodetic System 6 378 136 1/298,257 839 3 Unknown 1990 [DIGEST, Table 6.1,
"SN"]
STRUVE_1860 128 Struve 6 378 298,3 1/294,73 Unknown 1860 [DIGEST, Table 6.1,
"ST"]
WALBECK_AMS_1963 140 Walbeck 1819 - AMS 6 376 896 1/302,78 Unknown 1963 [DIGEST, Table 6.1,
"WB"]
WALBECK_PLANHEFT_1942 141 Walbeck 1819 - 6 376 895 1/302,782 156 5 Unknown 1942 [DIGEST, Table 6.1,
Planheft "WA"]
WAR_OFFICE_1924 142 War Office - McCaw 6 378 300,58 1/296 Assumed precise 1924 [NGA36, App. C-1,
"WO"]
WGS_1972 146 World Geodetic System 6 378 135 1/298,26 Assumed precise 1972 [NGA36, App. C-1,
"WD"]
WGS_1984 145 World Geodetic System 6 378 137 1/298,257 223 563 Assumed precise 1984 [NGA36, App. C-1,
"WE"]
Object type: Planet (non-Earth)
JUPITER_1988 82 Jupiter 71 492 000 1/15,4144 As specified 1988 [RIIC15, Table 4,
accompanying the "Jupiter"]
parameter value
© ISO/IEC 2025 – All rights reserved
Parameters
RD
RD label Description Date References
code
Major semi-axis,
Flattening,  Error estimate
MARS_2000 89 Mars 3 396 190 1/169,8945 As specified 2000 [RIIC15, Table 4,
accompanying the "Mars"]
parameter value
MERCURY_2015 171 Mercury 2 439 400 1/571,553 As specified 2015 [RIIC15, Table 4,
accompanying the "Mercury"]
parameter value
NEPTUNE_1991 105 Neptune 24 764 000 1/58,544 As specified 1991 [RIIC15, Table 4,
accompanying the "Neptune"]
parameter value
SATURN_1988 123 Saturn 60 268 000 1/10,20799 As specified 1988 [RIIC15, Table 4,
accompanying the "Saturn"]
parameter value
URANUS_1988 138 Uranus 25 559 000 1/43,61604 As specified 1988 [RIIC15, Table 4,
accompanying the "Uranus"]
parameter value
Object type: Satellite
LARISSA_1991 86 Larissa (satellite of 104 000 1/6,93 As specified 1991 [RIIC15, Table 5,
Neptune) accompanying the "Larissa"]
parameter value
Object type: Sun
© ISO/IEC 2025 – All rights reserved
Table D.3 — Sphere RD specifications
Parameters Date References
RD
RD label Description
code
Radius,  Error estimate
Object type: Earth
TM
COAMPS_1998 42 COAMPS 6 371 229 Precise 1998 [ERNWM, Table 1,
"COAMPS"]
MASS_1999 91 MASS 6 371 221,3 Precise 1999 [ERNWM, Table 1,
"MASS"]
MM5_1997 96 MM5 (AFWA) 6 370 000 Precise 1997 [ERNWM, Table 1,
"MM5 (AFWA)"]
MODTRAN_MIDLATITUDE_1989 99 MODTRAN (midlatitude 6 371 230 Precise 1989 [ERNWM, Table 1,
regions) "MODTRAN,
Midlatitude"]
MODTRAN_SUBARCTIC_1989 100 MODTRAN (subarctic 6 356 910 Precise 1989 [ERNWM, Table 1,
regions) "MODTRAN,
Subarctic"]
MODTRAN_TROPICAL_1989 101 MODTRAN (tropical 6 378 390 Precise 1989 [ERNWM, Table 1,
regions) "MODTRAN,
Tropical"]
MULTIGEN_FLAT_EARTH_1989 103 Multigen Flat Earth 6 366 707,02 Precise 1989 [MFCG]
NOGAPS_1988 107 NOGAPS 6 371 000 Precise 1988 [ERNWM, Table 1,
"NOGAPS"]
Object type: Planet (non-Earth)
MARS_SPHERE_2000 90 Mars 3 389 500 As specified accompanying the parameter 2000 [RIIC15, Table 4,
value "Mars"]
MERCURY_SPHERE_2015 172 Mercury 2 439 400 As specified accompanying the parameter 2015 [RIIC15, Table 4,
value "Mercury"]
© ISO/IEC 2025 – All rights reserved
Parameters Date References
RD
RD label Description
code
Radius,  Error estimate
PLUTO_2017 178 Pluto (minor planet 1 188 300 As specified accompanying the parameter 2017 [RIIC15, Table 6,
134340, a dwarf planet) value "(134340) Pluto"]
VENUS_1991 139 Venus 6 051 800 As specified accompanying the parameter 1991 [RIIC15, Table 4,
value "Venus"]
Object type: Satellite
ANANKE_1988 19 Ananke (satellite of 10 000 As specified accompanying the parameter 1988 [RIIC15, Table 5,
Jupiter) value "Ananke"]
ANTHE_2013 158 Anthe (satellite of 0 500 As specified accompanying the parameter 2013 [RIIC15, Table 5,
Saturn) value "Anthe"]
BELINDA_1988 25 Belinda (satellite of 33 000 As specified accompanying the parameter 1988 [RIIC15, Table 5,
Uranus) value "Belinda"]
BIANCA_1988 28 Bianca (satellite of 21 000 As specified accompanying the parameter 1988 [RIIC15, Table 5,
Uranus) value "Bianca"]
CARME_1988 31 Carme (satellite of 15 000 As specified accompanying the parameter 1988 [RIIC15, Table 5,
Jupiter) value "Carme"]
CHARON_2017 147 Charon (satellite of 606 000 As specified accompanying the parameter 2017 [RIIC15, Table 6,
minor planet 134340 value "(134340) Pluto: I
Pluto) Charon"]
CORDELIA_1988 43 Cordelia (satellite of 13 000 As specified accompanying the parameter 1988 [RIIC15, Table 5,
Uranus) value "Cordelia"]
CRESSIDA_1988 44 Cressida (satellite of 31 000 As specified accompanying the parameter 1988 [RIIC15, Table 5,
Uranus) value "Cressida"]
DESDEMONA_1988 48 Desdemona (satellite of 27 000 As specified accompanying the parameter 1988 [RIIC15, Table 5,
Uranus) value "Desdemona"]
DESPINA_1991 49 Despina (satellite of 74 000 As specified accompanying the parameter 1991 [RIIC15, Table 5,
Neptune) value "Despina"]
© ISO/IEC 2025 – All rights reserved
Parameters Date References
RD
RD label Description
code
Radius,  Error estimate
ELARA_1988 51 Elara (satellite of 40 000 As specified accompanying the parameter 1988 [RIIC15, Table 5,
Jupiter) value "Elara"]
GALATEA_1991 64 Galatea (satellite of 79 000 As specified accompanying the parameter 1991 [RIIC15, Table 5,
Neptune) value "Galatea"]
HIMALIA_1988 71 Himalia (satellite of 85 000 As specified accompanying the parameter 1988 [RIIC15, Table 5,
Jupiter) value "Himalia"]
JULIET_1988 81 Juliet (satellite of 42 000 As specified accompanying the parameter 1988 [RIIC15, Table 5,
Uranus) value "Juliet"]
LEDA_1988 87 Leda (satellite of 5 000 As specified accompanying the parameter 1988 [RIIC15, Table 5,
Jupiter) value "Leda"]
LYSITHEA_1988 88 Lysithea (satellite of 12 000 As specified accompanying the parameter 1988 [RIIC15, Table 5,
Jupiter) value "Lysithea"]
MOON_1991 102 Moon (satellite of Earth) 1 737 400 As specified accompanying the parameter 1991 [RIIC15, Table 5,
value "Moon"]
NAIAD_1991 104 Naiad (satellite of 29 000 As specified accompanying the parameter 1991 [RIIC15, Table 5,
Neptune) value "Naiad"]
NEREID_1991 106 Nereid (satellite of 170 000 As specified accompanying the parameter 1991 [RIIC15, Table 5,
Neptune) value "Nereid"]
OBERON_1988 108 Oberon (satellite of 761 400 As specified accompanying the parameter 1988 [RIIC15, Table 5,
Uranus) value "Oberon"]
OPHELIA_1988 109 Ophelia (satellite of 15 000 As specified accompanying the parameter 1988 [RIIC15, Table 5,
Uranus) value "Ophelia"]
PASIPHAE_1988 112 Pasiphae (satellite of 18 000 As specified accompanying the parameter 1988 [RIIC15, Table 5,
Jupiter) value "Pasiphae"]
PORTIA_1988 117 Portia (satellite of 54 000 As specified accompanying the parameter 1988 [RIIC15, Table 5,
Uranus) value "Portia"]
© ISO/IEC 2025 – All rights reserved
Parameters Date References
RD
RD label Description
code
Radius,  Error estimate
PUCK_1988 120 Puck (satellite of 77 000 As specified accompanying the parameter 1988 [RIIC15, Table 5,
Uranus) value "Puck"]
ROSALIND_1988 122 Rosalind (satellite of 27 000 As specified accompanying the parameter 1988 [RIIC15, Table 5,
Uranus) value "Rosalind"]
SINOPE_1988 124 Sinope (satellite of 14 000 As specified accompanying the parameter 1988 [RIIC15, Table 5,
Jupiter) value "Sinope"]
THALASSA_1991 132 Thalassa (satellite of 40 000 As specified accompanying the parameter 1991 [RIIC15, Table 5,
Neptune) value "Thalassa"]
TITANIA_1988 135 Titania (satellite of 788 900 As specified accompanying the parameter 1988 [RIIC15, Table 5,
Uranus) value "Titania"]
TRITON_1991 136 Triton (satellite of 1 352 600 As specified accompanying the parameter 1991 [RIIC15, Table 5,
Neptune) value "Triton"]
UMBRIEL_1988 137 Umbriel (satellite of 584 700 As specified accompanying the parameter 1988 [RIIC15, Table 5,
Uranus) value "Umbriel"]
Object type: Sun
SUN_2008 181 Sun 695 700 000 As specified accompanying the parameter 2008 [RIIC15, Table 4,
value "Sun"]
© ISO/IEC 2025 – A
...

Annex E
(normative)
ORM specifications
E.1 Overview
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 document, 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.
Abbreviated forms used in labels in this annex are defined in Annex F.
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_2013
Belinda Satellite BELINDA_1988
Bianca Satellite BIANCA_1988
Callisto Satellite CALLISTO_2001
Calypso Satellite CALYPSO_2013
Charon Satellite CHARON_2017
© ISO/IEC 2025 – All rights reserved 489

Object name Type Reference ORM label
Cordelia Satellite CORDELIA_1988
Cressida Satellite CRESSIDA_1988
Deimos Satellite DEIMOS_1993
Desdemona Satellite DESDEMONA_1988
Despina Satellite DESPINA_1991
Dione Satellite DIONE_2010
Earth Earth WGS_1984
Enceladus Satellite ENCELADUS_2016
Epimetheus Satellite EPIMETHEUS_2013
Eros (asteroid 433) Planet EROS_2002
Europa Satellite EUROPA_2007
Galatea Satellite GALATEA_1991
Ganymede Satellite GANYMEDE_2007
Gaspra (asteroid 951) Planet GASPRA_1991
Helene Satellite HELENE_2013
Iapetus Satellite IAPETUS_2010
Ida (asteroid 243) Planet IDA_1991
Io Satellite IO_1998
Janus Satellite JANUS_2013
Juliet Satellite JULIET_1988
Jupiter Planet JUPITER_2006
Larissa Satellite LARISSA_1991
Mars Planet MARS_2000
Mercury Planet MERCURY_2015
Metis Satellite METIS_2000
Mimas Satellite MIMAS_2010
490 © ISO/IEC 2025 – All rights reserved

Object name Type Reference ORM label
Miranda Satellite MIRANDA_1988
Moon Satellite MOON_1991
Naiad Satellite NAIAD_1991
Neptune Planet NEPTUNE_1991
Oberon Satellite OBERON_1988
Ophelia Satellite OPHELIA_1988
Pan Satellite PAN_2013
Pandora Satellite PANDORA_2013
Phobos Satellite PHOBOS_2010
Phoebe Satellite PHOEBE_2010
Pluto Planet PLUTO_2017
Portia Satellite PORTIA_1988
Prometheus Satellite PROMETHEUS_2013
Proteus Satellite PROTEUS_1991
Puck Satellite PUCK_1988
Rhea Satellite RHEA_2010
Rosalind Satellite ROSALIND_1988
Saturn Planet SATURN_1988
Sun Sun SUN_2008
Telesto Satellite TELESTO_2013
Tethys Satellite TETHYS_2010
Thalassa Satellite THALASSA_1991
Thebe Satellite THEBE_2000
Titan Satellite TITAN_2010
Titania Satellite TITANIA_1988
Triton Satellite TRITON_1991
© ISO/IEC 2025 – All rights reserved 491

Object name Type Reference ORM label
Umbriel Satellite UMBRIEL_1988
Uranus Planet URANUS_1988
Venus Planet VENUS_1991
492 © ISO/IEC 2025 – All rights reserved

E.2.2 Standardized ORMs
The elements of an ORM specification are defined in Table 7.33, and RT specification elements are defined in Table 7.34. 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. 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. Deprecated ORMs and
their associated RTs are specified in Annex J.
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
Object-fixed stellar ORM specifications Table E.19 Table E.20
Dynamic stellar ORM specifications Table E.21 n/a
© ISO/IEC 2025 – All rights reserved
ORM and RT specification tables ORM table RT table
Time-fixed instances of dynamic stellar ORM specifications Table E.22 Table E.23
E.2.2.1 Abstract ORMs
Table E.3 — Abstract ORM specifications
ORM Published Binding RD
ORM label Reference ORM Region ORMT label References
code name information parameterization
This is the
2D modelling reference ORM for
ABSTRACT_2D 1 none Universal BI_AXIS_ORIGIN_2D n/a none
space abstract 2D object-
space.
This is the
3D modelling reference ORM for
ABSTRACT_3D 2 none Universal TRI_PLANE n/a none
space abstract 3D object-
space.
Table E.4 — Abstract ORM reference transformation specifications
RT Date Reference
ORM label RT label RT region STT label and parameter values
code published s
IDENTITY
ABSTRACT_2D ABSTRACT_2D_IDENTITY 1 Universal n/a none
n/a (reference ORM)
IDENTITY
ABSTRACT_3D ABSTRACT_3D_IDENTITY 2 Universal n/a none
n/a (reference ORM)
© ISO/IEC 2025 – All rights reserved
E.2.2.2 Object-fixed ERMs
Table E.5 — Object-fixed ERM specifications
ORM Published Reference Binding RD
ORM label Region ORMT label References
code name ORM information parameterization
WAR_OFFICE- [NGA36, App.
ACCRA 266 Accra WGS_1984 1929 Ghana OBLATE_ELLIPSOID
_1924 D.2, "ACC"]
[NGA36, App.
ADEN_1925 300 Aden WGS_1984 1925 Yemen OBLATE_ELLIPSOID CLARKE_1880
E.2, "ADN"]
Burkina Faso,
Cameroon,
[NGA36, App.
ADINDAN_1991 3 Adindan WGS_1984 1991 Ethiopia, Mali, OBLATE_ELLIPSOID CLARKE_1880
D.2, "ADI"]
Senegal, and
Sudan
KRASSOVSKY- [NGA36, App.
AFGOOYE_1987 5 Afgooye WGS_1984 1987 Somalia OBLATE_ELLIPSOID
_1940 D.2, "AFG"]
Bahrain and INTERNATIONAL- [NGA36, App.
AIN_EL_ABD_1970 6 Ain el Abd WGS_1984 1970 OBLATE_ELLIPSOID
Saudi Arabia _1924 D.3, "AIN"]
AMERICAN_SAMOA- American American Samoa [NGA36, App.
8 WGS_1984 1962 OBLATE_ELLIPSOID CLARKE_1866
_1962 Samoa Islands D.10, "AMA"]
[DIGEST,
Amersfoort BESSEL_1841-
AMERSFOORT 267 WGS_1984 1903 Netherlands OBLATE_ELLIPSOID Table 6.2,
1885/1903 _ETHIOPIA
"AME"]
© ISO/IEC 2025 – All rights reserved
ORM Published Reference Binding RD
ORM label Region ORMT label References
code name ORM information parameterization
Anna 1 AUSTRALIAN- [NGA36, App.
ANNA_1_1965 9 WGS_1984 1965 Cocos Islands OBLATE_ELLIPSOID
(astronomic) _NATIONAL_1966 D.9, "ANO"]
Antigua Antigua and [NGA36, App.
ANTIGUA_1943 10 WGS_1984 1943 OBLATE_ELLIPSOID CLARKE_1880
(astronomic) Leeward Islands D.8, "AIA"]
Botswana,
Burundi,
Democratic
Republic of the [NGA36, App.
ARC_1950 11 Arc WGS_1984 1950 OBLATE_ELLIPSOID CLARKE_1880
Congo, Eswatini, D.2, "ARF"]
Lesotho, Malawi,
Zambia, and
Zimbabwe
Kenya, Malawi, [NGA36, App.
ARC_1960 12 Arc WGS_1984 1960 OBLATE_ELLIPSOID CLARKE_1880
and Tanzania D.2, "ARS"]
INTERNATIONAL- [NGA36, App.
ASCENSION_1958 14 Ascension WGS_1984 1958 Ascension Island OBLATE_ELLIPSOID
_1924 D.8, "ASC"]
AUSTRALIAN_GEOD- Australian Australia and AUSTRALIAN- [NGA36, App.
16 WGS_1984 1966 OBLATE_ELLIPSOID
_1966 Geodetic Tasmania _NATIONAL_1966 D.4, "AUA"]
AUSTRALIAN_GEOD- Australian Australia and AUSTRALIAN- [NGA36, App.
17 WGS_1984 1984 OBLATE_ELLIPSOID
_1984 Geodetic Tasmania _NATIONAL_1966 D.4, "AUG"]
AYABELLE- Ayabelle [NGA36, App.
18 WGS_1984 1991 Djibouti OBLATE_ELLIPSOID CLARKE_1880
_LIGHTHOUSE_1991 Lighthouse D.2, "PHA"]
© ISO/IEC 2025 – All rights reserved
ORM Published Reference Binding RD
ORM label Region ORMT label References
code name ORM information parameterization
Beacon E
INTERNATIONAL- [NGA36, App.
BEACON_E_1945 19 (Iwo Jima; WGS_1984 1945 Iwo Jima OBLATE_ELLIPSOID
_1924 D.10, "ATF"]
astronomic)
KRASSOVSKY- [NGA36, App.
BEIJING_1954 301 Beijing WGS_1984 1954 China OBLATE_ELLIPSOID
_1940 E.2, "PED"]
[DIGEST,
BEKAA_BASE- Bekaa Base CLARKE_1880-
268 WGS_1984 1920 Lebanon OBLATE_ELLIPSOID Table 6.2,
_SOUTH_END South End _IGN
"BEK"]
[NGA36, App.
BEKAA_VALLEY_1920 302 Bekaa Valley WGS_1984 1920 Lebanon OBLATE_ELLIPSOID CLARKE_1880
E.2, "BVD"]
Belgium 1972 [DIGEST,
INTERNATIONAL-
BELGIUM_1972 269 (Observatoire WGS_1984 1972 Belgium OBLATE_ELLIPSOID Table 6.2,
_1924
d'Uccle) "ODU"]
Efate and
Bellevue INTERNATIONAL- [NGA36, App.
BELLEVUE_IGN_1987 21 WGS_1984 1987 Erromango OBLATE_ELLIPSOID
(IGN) _1924 D.10, "IBE"]
Islands (Vanuatu)
[NGA36, App.
BERMUDA_1957 22 Bermuda WGS_1984 1957 Bermuda OBLATE_ELLIPSOID CLARKE_1866
D.8, "BER"]
[DIGEST,
Berne 1898 BESSEL_1841-
BERNE_1898 270 WGS_1984 1898 Switzerland OBLATE_ELLIPSOID Table 6.2,
(Switzerland) _ETHIOPIA
"BRE"]
© ISO/IEC 2025 – All rights reserved
ORM Published Reference Binding RD
ORM label Region ORMT label References
code name ORM information parameterization
Bioko Island
INTERNATIONAL- [NGA36, App.
BIOKO 303 Bioko WGS_1984 2013 (Equatorial OBLATE_ELLIPSOID
_1924 D.2, "BIO"]
Guinea)
INTERNATIONAL- [NGA36, App.
BISSAU_1991 24 Bissau WGS_1984 1991 Guinea-Bissau OBLATE_ELLIPSOID
_1924 D.2, "BID"]
Bogota INTERNATIONAL- [NGA36, App.
BOGOTA_OBS_1987 25 WGS_1984 1987 Colombia OBLATE_ELLIPSOID
Observatory _1924 D.7, "BOO"]
The
x-positive
xz-half-plane
Bogota contains
Observatory Bogota,
BOGOTA_OBS_1987- (with the Colombia INTERNATIONAL- [NGA36, App.
26 WGS_1984 Colombia OBLATE_ELLIPSOID
_PM_BOGOTA Prime (Instituto _1924 D.7, "BOO"]
Meridian at Geografico
Bogota) Augustin
Cadazzi
(IGAC)
determina-
tion).
Bangka and
BESSEL_1841- [NGA36, App.
BUKIT_RIMPAH_1987 27 Bukit Rimpah WGS_1984 1987 Belitung Islands OBLATE_ELLIPSOID
_ETHIOPIA E.2, "BUR"]
(Indonesia)
Camp Area McMurdo Camp INTERNATIONAL- [NGA36, App.
CAMP_AREA_1987 30 WGS_1984 1987 OBLATE_ELLIPSOID
(astronomic) Area (Antarctica) _1924 E.2, "CAZ"]
© ISO/IEC 2025 – All rights reserved
ORM Published Reference Binding RD
ORM label Region ORMT label References
code name ORM information parameterization
CAMPO_INCHAUSPE- Campo INTERNATIONAL- [NGA36, App.
31 WGS_1984 1969 Argentina OBLATE_ELLIPSOID
_1969 Inchauspe _1924 D.7, "CAI"]
Canton Phoenix Islands INTERNATIONAL- [NGA36, App.
CANTON_1966 32 WGS_1984 1966 OBLATE_ELLIPSOID
(astronomic) (Kiribati) _1924 D.10, "CAO"]
[NGA36, App.
CAPE_1987 33 Cape WGS_1984 1987 South Africa OBLATE_ELLIPSOID CLARKE_1880
D.2, "CAP"]
CAPE_CANAVERAL- Cape Bahamas and [NGA36, App.
34 WGS_1984 1991 OBLATE_ELLIPSOID CLARKE_1866
_1991 Canaveral Florida D.6, "CAC"]
[NGA36, App.
CARTHAGE_1987 35 Carthage WGS_1984 1987 Tunisia OBLATE_ELLIPSOID CLARKE_1880
D.2, "CGE"]
BESSEL_1841- [HELM,
CH1903_PLUS 271 CH1903+ WGS_1984 1903 Switzerland OBLATE_ELLIPSOID
_ETHIOPIA "CHW-7"]
Chatham Chatham Islands INTERNATIONAL- [NGA36, App.
CHATHAM_1971 37 WGS_1984 1971 OBLATE_ELLIPSOID
(astronomic) (New Zealand) _1924 D.10, "CHI"]
Chua INTERNATIONAL- [NGA36, App.
CHUA_1987 38 WGS_1984 1987 Paraguay OBLATE_ELLIPSOID
(astronomic) _1924 D.7, "CHU"]
[NGA36, App.
CIRCUIT 304 Circuit WGS_1984 2012 Zimbabwe OBLATE_ELLIPSOID CLARKE_1880
D.2, "CIR"]
[ERNWM,
TM
COAMPS_1998 39 COAMPS WGS_1984 1998 Global (Earth) SPHERE_ORIGIN COAMPS_1998 Table 1,
"COAMPS"]
© ISO/IEC 2025 – All rights reserved
ORM Published Reference Binding RD
ORM label Region ORMT label References
code name ORM information parameterization
CLARKE_1880- [NGA36, App.
CONAKRY_1905 305 Conakry WGS_1984 1905 Guinea OBLATE_ELLIPSOID
_IGN E.2, "COU"]
CORREGO_ALEGRE- Corrego INTERNATIONAL- [NGA36, App.
41 WGS_1984 1987 Brazil OBLATE_ELLIPSOID
_1987 Alegre _1924 D.7, "COA"]
[HELM, "CYP-
CYPRUS_1935 272 Cyprus 1935 WGS_1984 1935 Cyprus OBLATE_ELLIPSOID CLARKE_1858
7"]
[NGA36, App.
DABOLA_1991 43 Dabola WGS_1984 1991 Guinea OBLATE_ELLIPSOID CLARKE_1880
D.2, "DAL"]
DCS-3 (Astro
St Lucia and [NGA36, App.
DCS_3_ASTRO_1955 347 1955) (St WGS_1984 1955 OBLATE_ELLIPSOID CLARKE_1880
Windward Islands D.8, "DCS"]
Lucia)
Deception Island [NGA36, App.
DECEPTION_1993 44 Deception WGS_1984 1993 OBLATE_ELLIPSOID CLARKE_1880
(Antarctica) D.8, "DID"]
DHDN
[DIGEST,
Rauenberg BESSEL_1841-
DHDN_RAUENBERG 273 WGS_1984 1832 Germany OBLATE_ELLIPSOID Table 6.2,
(Berlin, _ETHIOPIA
"RAU"]
Germany)
Djakarta (also
Sumatra BESSEL_1841- [NGA36, App.
DJAKARTA_1987 49 known as WGS_1984 1987 OBLATE_ELLIPSOID
(Indonesia) _ETHIOPIA D.3, "BAT"]
Batavia)
© ISO/IEC 2025 – All rights reserved
ORM Published Reference Binding RD
ORM label Region ORMT label References
code name ORM information parameterization
Djakarta (also
The
known as
x-positive
DJAKARTA_1987_PM- Batavia; with Sumatra BESSEL_1841- [NGA36, App.
50 WGS_1984 xz-half-plane OBLATE_ELLIPSOID
_DJAKARTA the Prime (Indonesia) _ETHIOPIA D.3, "BAT"]
contains
Meridian at
Djakarta,
Djakarta)
Indonesia.
DOS (New Gizo Island
INTERNATIONAL- [NGA36, App.
DOS_1968 51 Georgia WGS_1984 1968 (Solomon OBLATE_ELLIPSOID
_1924 D.10, "GIZ"]
Islands) Islands)
DOS 71/4
(St. Helena St. Helena Island INTERNATIONAL- [NGA36, App.
DOS_71_4_1987 52 WGS_1984 1987 OBLATE_ELLIPSOID
Island; (UK
...

Annex F
(normative)
Abbreviated forms used in the construction of labels
F.1 Overview
Table F.1 lists the abbreviated forms used in the construction of labels.
The notation "[nnn]", where nnn represents one or more letters, means that the letters 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 abbreviated form. Thus, the entry "adjust[ed][ment]” means that both the word "adjusted" and the word
"adjustment" may be abbreviated with the abbreviated form "ADJ" in the adjacent column.
F.2 Table of abbreviated forms
Table F.1 — Abbreviated forms used in labels
Abbreviated
Abbreviated term
form
one-dimensional 1D
two-dimensional 2D
three-dimensional 3D
adjust[ed][ment] ADJ
American AM
CH 1903 ("CH" is the ISO 3166-1:2020 country code for Switzerland) CH1903
coordinate system CS
TM
Coupled Ocean/Atmospheric Mesoscale Prediction System COAMPS
Datum 1973 D73
Definitive Geomagnetic Reference Field DGRF
Deutschen Hauptdreiecksnetzes (Germany) DHDN
Earth gravitational model EGM
east E
European Terrestrial Reference Frame ETRF
Geocentric Datum of Australia GDA
geodeti[c][que] GEOD
geodetic reference system GRS
Geo Tile Reference System GTRS
Greek Geodetic Reference System GGRS
heliocentric HELIO
Institut Géographique National (France) IGN
international INT
International Association of Geodesy IAG
International Geomagnetic Reference Field
IGRF
© I
...

Annex G
(normative)
Change and deprecation plan
G.1 Overview
Instances of SRM concepts – such as spatial reference frames, parameter values, object reference models, and
other related information – describe models of various spatial objects of interest, including the Earth and other
celestial bodies. As the state of a spatial object changes (e.g., the locations of the geomagnetic poles of the
Earth gradually move), or the knowledge about a particular spatial object improves, the corresponding instances
of the SRM concept associated with that spatial object need to change as well. This includes adding new concept
instances, updating existing concept instances by creating new versions, or declaring older versions obsolete.
Different instances of an SRM concept may be used to represent a spatial object during different time periods.
These different instances are commonly distinguished from one another based on the start and/or end dates of
their applicable time periods. As the knowledge about a particular spatial object improves, new versions of a
concept instance may need to be created. These versions are commonly distinguished from one another based
on the version identifiers or publication dates of their respective reference documents.
As SRM concept instances are added, updated, or declared obsolete, this document and its authorized
registered items will evolve. Declaring an SRM concept instance obsolete is termed deprecation. To ensure the
long-term coherence and orderly evolution of this document, this annex defines procedures for change or
deprecation of instances of SRM concepts. This annex also defines how a deprecated SRM concept instance
may be reinstated. Addition, change, deprecation, or reinstatement procedures are in accordance with ISO/IEC
9973.
G.2 Addition
This document allows new instances of some SRM concepts to be specified by registration (see Clause 13).
New instances of SRM concepts may also be introduced through amendment or revision.
G.3 Change
G.3.1 Overview
To ensure a stable evolution process 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 document or later by
registration. The following rules apply both to changes to this document by amendment or revision and to
changes to SRM registered items:
a) Changes to an SRM concept instance, to the extent allowed in corrigenda, that correct errors without
changing its semantic meaning, shall be accomplished in accordance with G.3.2. Such changes are
termed corrections.
b) Changes to an SRM concept instance that are the result of new or refined information about the spatial
object shall be accomplished by creating a new version of the concept instance, in accordance with
G.3.3. Such changes are termed updates.
c) Versions of SRM concept instances that are determined to have become obsolete as a result of updates
may be deprecated in accordance with G.4.
© ISO/IEC 2025 – All rights reserved 637

d) 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. No SRM code or SRM label shall be reused.
e) SRM profiles shall not be changed. If an SRM profile requires change, it shall be deprecated and a new
SRM profile shall be introduced by registration or amendment.
G.3.2 Correction
Correction involves modification as a result of an error discovered in the reference document for an SRM
concept instance. This may be the result of an editorial, typographical, or other publication error in an earlier
edition of the reference document. The error may be in a parameter value, in the label, or other data fields of
the SRM concept instance. The correction may have been discovered in a later edition of the reference
document or in a corrigendum to the earlier edition.
Correction may also apply to any concept instance whose data has not changed, but a new edition of its
reference document has been published. The reference for the concept instance is corrected to refer to the new
edition.
Correction may also arise as the result of an error that occurred while incorporating information from the
reference document into this document.
When a correction is made to an SRM concept instance, the correction shall be published in a corrigendum to
this document to alert users to the change. It is not necessary to create a new version
...

Annex H
(normative)
Templates for registration proposals
H.1 Overview
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 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
Generating function or mapping

equations
© ISO/IEC 2025 – All rights reserved 641

Element Specification
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 the elements contained in Table
H.1 and in Table H.3. The required contents of the specification column are described in Table 5.38.
Table H.3 — Temporal coordinate system registration proposal elements
Element Specification
Temporal CS label
Description
References
H.4 Proposal for the registration of an RD
Each proposal for the registration of an RD shall provide values of all 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
Parameters
Date
References
642 © ISO/IEC 2025 – All rights reserved

H.5 Proposal for the registration of an STT
Each proposal for the registration of an STT shall provide values of all 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 — Similarity transformation template registration proposal elements
Element Specification
STT label
Name(s)
Description
Dimension
STT parameters
STT constraints
STT formulation
STT inverse formulation
API STT parameter structure
Notes
References
H.6 Proposal for the registration of an ORMT
Each proposal for the registration of an ORMT shall provide values of all the elements contained in Table H.1
and in Table H.6. The required contents of the specification column are described in Table 7.29.
Table H.6 — ORMT registration proposal elements
Element Specification
ORMT label
Description
RD set
Binding constraints
Notes
© ISO/IEC 2025 – All rights reserved 643

H.7 Proposal for the registration of an ORM
Each proposal for the registration of an ORM shall provide values of all the elements contained in Table H.1
and in Table H.7. The required contents of the specification column are described in Table 7.33.
Table H.7 — 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.8.
References
H.8 Proposal for the registration of a reference transformation
Each proposal for the registration of an RT shall provide values of all the elements contained in Table H.1 and
in Table H.8. The required contents of the specification column are described in Table 7.34.
Table H.8 — RT registration proposal elements
Element Specification
ORM label
RT label
RT region
STT label and parameter values
Date published
References
644 © ISO/IEC 2025 – All rights reserved
...

Annex I
(informative)
Conformance testing for SRF operations
I.1 Overview
This annex provides guidelines that may be useful for developing conformance requirements and conformance
tests for implementation of the concepts specified in this document 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 those approximation errors made to simplify the implementation and/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 approximation of the shape. In this
document, 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 document.
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 ORMs, CSs, and bindings to the CSs.
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. 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.
I.4 Implementations
This document may be implemented in many ways. Potential implementations include:
© ISO/IEC 2025 – All rights reserved 649

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 document may be restricted to a sub-set of the domains involved (see Clause
12). (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 a data
point in the reference data set and the corresponding data point obtained from a particular implementation is
referred to as a computational error. The computational error may have units of length, may be angular
measures or may be dimensionless, depending on the particular SRF operation being evaluated.
When the reference data are generated, a computational digital accuracy at least as accurate as double
precision is assumed, as specified in ISO/IEC/IEEE 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 ISO/IEC/IEEE 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
numerically compared to corresponding data points generated by an implementation. The value of the error
metric represents the computational error. Computational errors as defined in this document are absolute errors.
These are positive numbers and may have units of measure associated with them.
Given an exact (or reference) position (� , � , � ) in position-space and a computed value (�, �, �) for that
� � �
position, the error in the computation is given directly in metres by:
� � �
�
� = �� + �� + ��
where �� = � − � , �� = � − � , �� = � − � .
� � �
For SRF operations, error metrics are expressed in terms of the coordinate-components of the target SRF.
These are obtained from the formulation of � by substituting expressions for ��, ��, �� in terms of the CS
coordinate-components of the target SRF.
In the case of a target SRF based on the Euclidean 3D or the Lococentric Euclidean 3D CSs, direct substitution
of the (isomorphic) generating functions yields:
� � �
� = ��� + �� + ��
where (��, ��, ��) = (�, �, �) − (� , � , � ) is the difference between the exact and computed coordinates.
� � �
For a target SRF based on a non-linear CS, and assuming that the error is small, the following approximations
for ��, ��, �� apply:
�� �� ��
�� = �� + �� + ��
�� �� ��
650 © ISO/IEC 2025 – All rights reserved

�� �� ��
�� = �� + �� + ��
�� �� ��
�ℎ �ℎ �ℎ
�� = �� + �� + ��
�� �� ��
where (�, �, �) = (�(�, �, �), �(�, �, �), ℎ(�, �, �)) = �(�, �, �) is the CS generating function, (�, �, �) is a
( ) ( ) ( ) ( )
computed CS coordinate, � , � , � is an exact CS coordinate and ��, ��, �� = �, �, � − � , � , � .
� � � � � �
For a target SRF base
...

Annex J
(normative)
Deprecated SRM concept instances
J.1 Overview
This annex contains tables defining those SRM concept instances whose use is deprecated as defined in
Annex G. Users are strongly cautioned that deprecated concept instances are expected to be removed in a
future version of this document.
J.2 Deprecated RDs
This sub-annex presents the specifications of deprecated RDs. RD 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
© ISO/IEC 2025 – All rights reserved 655

Table J.2 — Deprecated oblate ellipsoid RDs
Parameters
RD
RD label Description Date References Notes
code
Major semi-axis,
Flattening,  Error estimate
Object type: Earth
WGS_1960 143 World Geodetic 6 378 165 1/298,3 1960 [DIGEST, Table Superseded by WGS_1972 and
System 1960 6.1, "WS"] WGS_1984, based on more recent
Assumed precise
information contained in 83502T.
WGS_1966 144 World Geodetic 6 378 145 1/298,25 Unknown 1966 [DIGEST, Table Superseded by WGS_1972 and
System 1966 6.1, "WC"] WGS_1984, based on more recent
information contained in 83502T.
Object type: Planet (non-Earth)
Object type: Satellite
Object type: Sun
Table J.3 — Deprecated sphere RDs
Parameters
RD
RD label Description Date References Notes
code
Radius,  Error estimate
Object type: Earth
Object type: Planet (non-Earth)
EROS_2000 54 Eros (asteroid 433, a minor 7 311 As specified accompanying the 2000 [RIIC, Table VI, Superseded by EROS_2002, based on
planet) parameter value "Eros"] more accurate information in RIIC15.
© ISO/IEC 2025 – All rights reserved
Parameters
RD
RD label Description Date References Notes
code
Radius,  Error estimate
MERCURY- 92 Mercury 2 439 700 As specified accompanying the 1988 [RIIC, Table IV, Superseded by MERCURY_2015, based
_1988 parameter value "Mercury"] on more accurate information in RIIC15.
PLUTO_1994 116 Pluto (minor planet 134340, 1 195 000 As specified accompanying the 1994 [RIIC, Table IV, Superseded by PLUTO_2017, based on
a dwarf planet) parameter value "Pluto"] more accurate information in RIIC15.
Object type: Satellite
CHARON_1991 32 Charon (satellite of Pluto) 593 000 As specified accompanying the 1991 [RIIC, Table V, Superseded by CHARON_2017, based on
parameter value "Charon"] more accurate information in RIIC15.
DIONE_1982 50 Dione (satellite of Saturn) 560 000 As specified accompanying the 1982 [RIIC, Table V, Superseded by DIONE_2010, based on
parameter value "Dione"] more accurate information in RIIC15.
IAPETUS_1988 75 Iapetus (satellite of Saturn) 718 000 As specified accompanying the 1988 [RIIC, Table V, Superseded by IAPETUS_2010, based on
parameter value "Iapetus"] more accurate information in RIIC15.
PAN_1991 110 Pan (satellite of Saturn) 10 000 As specified accompanying the 1991 [RIIC, Table V, Superseded by PAN_2013, based on more
parameter value "Pan"] accurate information in RIIC15.
RHEA_1988 121 Rhea (satellite of Saturn) 764 000 As specified accompanying the 1988 [RIIC, Table V, Superseded by RHEA_2010, based on
parameter value "Rhea"] more accurate information in RIIC15.
TITAN_1982 134 Titan (satellite of Saturn) 2 575 000 As specified accompanying the 1982 [RIIC, Table V, Superseded by TITAN_2010, based on
parameter value "Titan"] more accurate information in RIIC15.
Object type: Sun
SUN_1992 129 Sun 696 000 000 As specified accompanying the 1992 [SEID, Table Superseded by SUN_2008, based on more
parameter value 15.4, "Sun"] accurate information in RIIC15.

Table J.4 — Deprecated prolate ellipsoid RDs
In this document, no prolate ellipsoid RDs are deprecated, therefore the table is empty.
© ISO/IEC 2025 – All rights reserved
Table J.5 — Deprecated tri-axial ellipsoid RDs
Parameters
RD
RD label Description Date References Notes
Semi- Semi- Semi-
code
Error estimate
axis,
axis,  axis, 
Object type: Earth
Object type: Planet (non-Earth)
KLEOPATRA_2000 83 Kleopatra 108 500 47 000 40 500 As specified 2000 [RIIC, Table VI, Reclassified and removed from
(asteroid 216, a accompanying the "Kleopatra"] RIIC06.
minor planet) parameter value
Object type: Satellite
ATLAS_1988 22 Atlas (satellite of 18 500 17 200 13 500 As specified 1988 [RIIC, Table V, Superseded by ATLAS_2013,
Saturn) accompanying the "Atlas"] based on more accurate
parameter value information in RIIC15.
CALLISTO_2000 29 Callisto (satellite 2 409 400 2 409 200 2 409 300 As specified 2000 [RIIC, Table V, Superseded by
of Jupiter) accompanying the "Callisto"] CALLISTO_2001, based on
parameter value more accurate information in
RIIC15.
CALYPSO_1988 30 Calypso 15 000 8 000 8 000 As specified 1988 [RIIC, Table V, Superseded by
(satellite of accompanying the "Calypso"] CALYPSO_2013, based on
Saturn) parameter value more accurate information in
RIIC15.
DEIMOS_1988 46 Deimos (satellite 7 500 6 100 5 200 As specified 1988 [RIIC, Table V, Superseded by DEIMOS_1993,
of Mars) accompanying the "Deimos"] based on more accurate
parameter value information in RIIC15.
ENCELADUS_1994 52 Enceladus 256 300 247 300 244 600 As specified 1994 [RIIC, Table V, Superseded by
(satellite of accompanying the "Enceladus"] ENCELADUS_2006, based on
Saturn) parameter value more accurate information in
RIIC15.
© ISO/IEC 2025 – All rights reserved
Parameters
RD
RD label Description Date References Notes
Semi- Semi- Semi-
code
Error estimate
axis,
axis,  axis, 
EPIMETHEUS- 53 Epimetheus 69 000 55 000 55 000 As specified 1988 [RIIC, Table V, Superseded by
_1988 (satellite of accompanying the "Epimetheus"] EPIMETHEUS_2013, based on
Saturn) parameter value more accurate information in
RIIC15.
EUROPA_2000 55 Europa (satellite 1 564 130 1 561 230 1 560 930 As specified 2000 [RIIC, Table V, Superseded by EUROPA_2007,
of Jupiter) accompanying the "Europa"] based on more accurate
parameter value information in RIIC15.
GANYMEDE_2000 65 Ganymede 2 632 400 2 632 290 2 632 350 As specified 2000 [RIIC, Table V, Superseded by
(satellite of accompanying the "Ganymede"] GANYMEDE_2007, based on
Jupiter) parameter value more accurate information in
RIIC15.
HELENE_1992 69 Helene (satellite 18 000 16 000 15 000 As specified 1992 [SEID, Table Superseded by HELENE_2013,
of Saturn) accompanying the 15.10, "Helene"] based on more accurate
parameter value information in RIIC15.
HYPERION_2000 73 Hyperion 164 000 130 000 107 000 As specified 2000 [RIIC, Table V, Superseded by
(satellite of accompanying the "Hyperion"] HYPERION_2010, based on
Saturn) parameter value more accurate information in
RIIC15.
IO_2000 79 Io (satellite of 1 829 400 1 819 300 1 815 700 As specified 2000 [RIIC, Table V, Superseded by IO_1998, based
Jupiter) accompanying the "Io"] on more accurate information in
parameter value RIIC15.
JANUS_1988 80 Janus (satellite 97 000 95 000 77 000 As specified 1988 [RIIC, Table V, Superseded by JANUS_2013,
of Saturn) accompanying the "Janus"] based on more accurate
parameter value information in RIIC15.
MIMAS_1994 94 Mimas (satellite 209 100 196 200 191 400 As specified 1994 [RIIC, Table V, Superseded by MIMAS_2010,
of Saturn) accompanying the "Mimas"] based on more accurate
parameter value information in RIIC15.
© ISO/IEC 2025 – All rights reserved
Parameters
RD
RD label Description Date References Notes
Semi- Semi- Semi-
code
Error estimate
axis,
axis,  axis, 
PANDORA_1988 111 Pandora 55 000 44 000 31 000 As specified 1988 [RIIC, Table V, Superseded by
(satellite of accompanying the "Pandora"] PANDORA_2013, based on
Saturn) parameter value more accurate information in
RIIC15.
PHOBOS_1988 113 Phobos (satellite 13 400 11 200 9 200 As specified 1988 [RIIC, Table V, Superseded by PHOBOS_2010,
of Mars) accompanying the "Phobos"] based on more accurate
parameter value information in RIIC15.
PHOEBE_1988 114 Phoebe (satellite 115 000 110 000 105 000 As specified 1988 [RIIC, Table V, Superseded by PHOEBE_2010,
of Saturn) accompanying the "Phoebe"] based on more accurate
parameter value information in RIIC15.
PROMETHEUS- 118 Prometheus 74 000 50 000 34 000 As specified 1988 [RIIC, Table V Superseded bu
_1988 (satellite of accompanying the "Prometheus"] PROMETHEUS_2013, based on
Saturn) parameter value more accurate information in
RIIC15.
TELESTO_1988 130 Telesto (satellite 15 000 12 500 7 500 As specified 1988 [RIIC, Table V, Superseded bu
of Saturn) accompanying the "Telesto"] TELESTO_2013, based on more
parameter value accurate information in RIIC15.
TETHYS_1991 131 Tethys (satellite 535 600 528 200 525 800 As specified 1991 [RIIC, Table V, Superseded by TETHYS_2010,
of Saturn) accompanying the "Tethys"] based on more accurate
parameter value information in RIIC15.
Object type: Sun
© ISO/IEC 2025 – All rights reserved
J.3 Deprecated ORMs
This sub-annex presents the specifications of deprecated ORMs and their associated RTs. ORM specification
elements are defined in Table 7.33, and RT specification elements are defined in Table 7.34. Table J.6 is a
directory of deprecated ORMs organized by category of ORM and type of object. The ORM entries in each table
are ordered alphabetically by their label. 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 J.6.
Table J.6 — Deprecated ORM specification directory
Deprecated ORM specification table ORM table RT table
Deprecated abstract object ORMs Table J.7 none
Deprecated object-fixed ERMs Table J.8 none
Deprecated dynamic ERMs Table J.9 n/a
Deprecated time-fixed instances of dynamic ERMs Table J.10 Table J.11
Deprecated object-fixed planet (non-Earth) ORMs Table J.12 Table J.13
Deprecated dynamic planet (non-Earth) ORMs Table J.14 n/a
Deprecated time-fixed instances of dynamic planet (non-Earth) ORMs Table J.15 none
Deprecated object-fixed satellite ORMs Table J.16 Table J.17
Deprecated dynamic satellite ORMs Table J.18 n/a
Deprecated time-fixed instances of dynamic satellite ORMs Table J.19 none
Deprecated object-fixed stellar ORMs Table J.20 Table J.21
Deprecated dynamic stellar ORMs Table J.22 n/a
Deprecated time-fixed instances of dynamic stellar ORMs Table J.23 none
Table J.7 — Deprecated abstract object ORMs
In this document, no abstract object ORMs are deprecated, therefore the table is empty.
Table J.8 — Deprecated object-fixed ERMs
In this document, no object-fixed ERMs are deprecated, therefore the table is empty.
Table J.9 — Deprecated dynamic ERMs
In this document, no dynamic ERMs are deprecated, therefore the table is empty.

© ISO/IEC 2025 – All rights reserved 661

Table J.10 — Deprecated time-fixed instances of dynamic ERMs
ORM Published Reference Binding RD
ORM label Region ORMT label References Notes
code name ORM information parameterization
Superseded by
OBRS [DAGF,
GEOMAGNETIC_1945-
GEOMAGNETIC DGRF CELESTIOMAGNETIC Vicinity BI_AXIS- Table I,
77 WGS_1984 n/a _IGRF13, based on
_1945 1945 Note: Object-fixed base of Earth _ORIGIN_3D "DGRF
more accurate
epoch for the 5 year 1945"]
information in IAGA.
period 1945 to 1950.
Superseded by
OBRS [DAGF,
GEOMAGNETIC_1950-
GEOMAGNETIC DGRF CELESTIOMAGNETIC Vicinity BI_AXIS- Table I,
78 WGS_1984 n/a _IGRF13, based on
_1950 1950 Note: Object-fixed base of Earth _ORIGIN_3D "DGRF
more accurate
epoch for the 5 year 1950"]
information in IAGA.
period 1950 to 1955.
Superseded by
OBRS [DAGF,
GEOMAGNETIC_1955-
GEOMAGNETIC DGRF CELESTIOMAGNETIC Vicinity BI_AXIS- Table I,
79 WGS_1984 n/a _IGRF13, based on
_1955 1955 Note: Object-fixed base of Earth _ORIGIN_3D "DGRF
more accurate
epoch for the 5 year 1955"]
information in IAGA.
period 1955 to 1960.
Superseded by
OBRS [DAGF,
GEOMAGNETIC_1960-
GEOMAGNETIC DGRF CELESTIOMAGNETIC Vicinity BI_AXIS- Table I,
80 WGS_1984 n/a _IGRF13, based on
_1960 1960 Note: Object-fixed base of Earth _ORIGIN_3D "DGRF
more accurate
epoch for the 5 year 1960"]
information in IAGA.
period 1960 to 1965.
© ISO/IEC 2025 – All rights reserved
ORM Published Reference Binding RD
ORM label Region ORMT label References Notes
code name ORM information parameterization
Superseded by
OBRS [DAGF,
GEOMAGNETIC_1965-
GEOMAGNETIC DGRF CELESTIOMAGNETIC Vicinity BI_AXIS- Table I,
81 WGS_1984 n/a _IGRF13, based on
_1965 1965 Note: Object-fixed base of Earth _ORIGIN_3D "DGRF
more accurate
epoch for the 5 year 1965"]
information in IAGA.
period 1965 to 1970.
Superseded by
OBRS [DAGF,
GEOMAGNETIC_1970-
GEOMAGNETIC DGRF CELESTIOMAGNETIC Vicinity BI_AXIS- Table I,
82 WGS_1984 n/a _IGRF13, based on
_1970 1970 Note: Object-fixed base of Earth _ORIGIN_3D "DGRF
more accurate
epoch for the 5 year 1970"]
information in IAGA.
period 1970 to 1975.
Superseded by
OBRS [DAGF,
GEOMAGNETIC_1975-
GEOMAGNETIC DGRF CELESTIOMAGNETIC Vicinity BI_AXIS- Table I,
83 WGS_1984 n/a _IGRF13, based on
_1975 1975 Note: Object-fixed base of Earth _ORIGIN_3D "DGRF
more accurate
epoch for the 5 year 1975"]
information in IAGA.
period 1975 to 1980.
Superseded by
OBRS [DAGF,
GEOMAGNETIC_1980-
GEOMAGNETIC DGRF CELESTIOMAGNETIC Vicinity BI_AXIS- Table I,
84 WGS_1984 n/a _IGRF13, based on
_1980 1980 Note: Object-fixed base of Earth _ORIGIN_3D "DGRF
more accurate
epoch for the 5 year 1980"]
information in IAGA.
period 1980 to 1985.
© ISO/IEC 2025 – All rights reserved
ORM Published Reference Binding RD
ORM label Region ORMT label References Notes
code name ORM information parameterization
Superseded by
OBRS [DAGF,
GEOMAGNETIC_1985-
GEOMAGNETIC DGRF CELESTIOMAGNETIC Vicinity BI_AXIS- Table I,
85 WGS_1984 n/a _IGRF13, based on
_1985 1985 Note: Object-fixed base of Earth _ORIGI
...

11 Application program interface
11.1 Overview
This clause specifies an API for the operations and concepts defined in this document. It specifies:
a) data types,
b) classes and their methods, and
c) functions.
The data types specified in this clause are composed of basic and structured data types. Data types supporting
methods and functions are defined in 11.2. To support the conformance of exchange formats (see 14.3),
additional data types for storage and/or transmission are defined in 11.5.
Class specifications serve to organize methods related to specific SRM concepts. In this sense, class instances
represent SRM concept instances. An API object is an instance of a class. A class defines methods that produce
outputs by operating on the state of an object and its inputs. Classes and their methods are defined in 11.3.
Functions are specified outside of the class specifications and operate only on the specified inputs to produce
their corresponding outputs. The capabilities provided by these functions include creating instances of standard
and set-based SRFs, and querying the extent of support of an API implementation. These functions are specified
in 11.4.
Implementations of classes and their methods, and other functions, shall conform to computational accuracy
requirements (see 14.2). The computational accuracy requirements do not apply to a sequence or chain of SRF
operations, only to each individual SRF operation in the sequence.
Due to variations in class-specific equivalent data representations, it is possible that Get methods will return
values that are different from previously input parameter values in corresponding Create methods (see
11.3.11).
Functional implementation and exchange format conformance are based on profiles (see Clause 12).
Conformance of an application to a profile is defined in 14.5.
11.2 Data types
11.2.1 Overview
Data types are organized into basic data types and structured data types. Basic data types consist of single
values, whereas structured data types consist of multiple values. Basic data types include numeric data types,
enumerated data types, and selection data types. Selection data types are similar to enumerated data types but
can be extended via registration. Structured data types include array data types, record data types and variant
record data types. The elements of arrays are all of the same data type and are referenced by position within
the array, whereas the elements of records may be of different data types and are referenced by name. In
variant records, a selector is used to choose one record data type from among several alternative record data
types.
11.2.2 SRFT abbreviated forms
Table 11.1 lists the SRFT names and their abbreviated forms used in the formation of enumerant names and
record element names of data types.
301 © ISO/IEC 2025 – All rights reserved

Table 11.1 — SRFT abbreviated forms
Abbreviated form SRFT name
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_2D Local Space Azimuthal 2D
LSP_2D Local Space Polar 2D
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
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
302 © ISO/IEC 2025 – All rights reserved

11.2.3 Numbers
Two categories of numbers are specified: integer numbers and floating-point numbers. The general-purpose
integer data types are Integer, Integer_Positive and Integer_Unsigned. 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
[−2 147 483 647, 2 147 483 647]
Integer_Positive
[1, 4 294 967 295]
Integer_Unsigned
[0, 4 294 967 295]
Long_Float is a data type defined for floating-point numbers. This data type corresponds to the double
precision floating-point data type specified by ISO/IEC/IEEE 60559. However, implementations on architectures
that support other floating-point representations are allowed. When recording a Long_Float number in a file
or archive, the floating-point data type specified in ISO/IEC/IEEE 60559 shall be used. It is the responsibility of
the implementation to make suitable conversions when the internal floating-point format differs from the standard
floating point data type.
11.2.4 Logicals
The general-purpose logical data type is Boolean. All implementations that conform to this standard shall
support this data type as specified in Table 11.3.
Table 11.3 — Logical data type
Data type Values
Boolean
[ false (or 0), true (or 1) ]
11.2.5 Object_Reference
An object reference is a generic reference to a class instance. Object_Reference is an opaque data type
that implements this concept. If the values of two Object_References are equal, they shall refer to the same
class instance. In all the method specifications in this clause, whenever an argument passed to or returned from
a method is a class instance, it is an Object_Reference that is passed or returned.
The NULL_Object is defined as a special Object_Reference. If the value of an Object_Reference is
equal to the value of the NULL_Object, it does not reference any class instance. On an error condition, some
language bindings may require method and/or function outputs to be defined. In these cases,
Object_Reference outputs shall be set to NULL_Object as appropriate.
11.2.6 Enumerated data types
11.2.6.1 Overview
Enumerated data types are data types whose values are specified from an ordered list of names. Enumerated
data types are a closed list, the members of which do not change based on registration or deprecation.
303 © ISO/IEC 2025 – All rights reserved

11.2.6.2 Axis_Direction_2D
This data type represents the values of the axis direction parameter(s) of the SRFT
LOCAL_SPACE_RECTANGULAR_2D.
Axis_Direction_2D ::= ( POSITIVE_FIRST_BASIS_AXIS_2D,
POSITIVE_SECOND_BASIS_AXIS_2D,
NEGATIVE_FIRST_BASIS_AXIS_2D,
NEGATIVE_SECOND_BASIS_AXIS_2D)
POSITIVE_FIRST_BASIS_AXIS_2D indicates that the primary axis of the
LOCAL_SPACE_RECTANGULAR_2D SRF is to be aligned with the positive first basis axis of its
LOCOCENTRIC_EUCLIDEAN_2D CS.
POSITIVE_SECOND_BASIS_2D indicates that the primary axis of the LOCAL_SPACE_RECTANGULAR_2D
SRF is to be aligned with the positive second basis axis of its LOCOCENTRIC_EUCLIDEAN_2D CS.
NEGATIVE_FIRST_BASIS_AXIS_2D indicates that the primary axis of the
LOCAL_SPACE_RECTANGULAR_2D SRF is to be aligned with the negative first basis axis of its
LOCOCENTRIC_EUCLIDEAN_2D CS.
NEGATIVE_SECOND_BASIS_AXIS_2D indicates that the primary axis of the
LOCAL_SPACE_RECTANGULAR_2D SRF is to be aligned with the negative second basis axis of its
LOCOCENTRIC_EUCLIDEAN_2D CS.
11.2.6.3 Axis_Direction_3D
This data type represents the values of the axis direction parameter(s) of the SRFT
LOCAL_SPACE_RECTANGULAR_3D.
Axis_Direction_3D ::= ( POSITIVE_FIRST_BASIS_AXIS_3D,
POSITIVE_SECOND_BASIS_AXIS_3D,
POSITIVE_THIRD_BASIS_AXIS_3D,
NEGATIVE_FIRST_BASIS_AXIS_3D,
NEGATIVE_SECOND_BASIS_AXIS_3D,
NEGATIVE_THIRD_BASIS_AXIS_3D )
POSITIVE_FIRST_BASIS_AXIS_3D indicates that the specified (primary or secondary) axis of the
LOCAL_SPACE_RECTANGULAR_3D SRF is to be aligned with the positive first basis axis of its
LOCOCENTRIC_EUCLIDEAN_3D CS.
POSITIVE_SECOND_BASIS_AXIS_3D indicates that the specified (primary or secondary) axis of the
LOCAL_SPACE_RECTANGULAR_3D SRF is to be aligned with the positive second basis axis of its
LOCOCENTRIC_EUCLIDEAN_3D CS.
POSITIVE_THIRD_BASIS_AXIS_3D indicates that the specified (primary or secondary) axis of the
LOCAL_SPACE_RECTANGULAR_3D SRF is to be aligned with the positive third basis axis of its
LOCOCENTRIC_EUCLIDEAN_3D CS.
NEGATIVE_FIRST_BASIS_AXIS_3D indicates that the specified (primary or secondary) axis of the
LOCAL_SPACE_RECTANGULAR_3D SRF is to be aligned with the negative first basis axis of its
LOCOCENTRIC_EUCLIDEAN_3D CS.
NEGATIVE_SECOND_BASIS_AXIS_3D indicates that the specified (primary or secondary) axis of the
LOCAL_SPACE_RECTANGULAR_3D SRF is to be aligned with the negative second basis axis of its
LOCOCENTRIC_EUCLIDEAN_3D CS.
304 © ISO/IEC 2025 – All rights reserved

NEGATIVE_THIRD_BASIS_AXIS_3D indicates that the specified (primary or secondary) axis of the
LOCAL_SPACE_RECTANGULAR_3D SRF is to be aligned with the negative third basis axis of its
LOCOCENTRIC_EUCLIDEAN_3D CS.
11.2.6.4 Interval_Type
This data type is used to specify coordinate-component intervals.
Interval_Type::= ( OPEN_INTERVAL,
GE_LT_INTERVAL,
GT_LE_INTERVAL,
CLOSED_INTERVAL,
GT_SEMI_INTERVAL,
GE_SEMI_INTERVAL,
LT_SEMI_INTERVAL,
LE_SEMI_INTERVAL,
UNBOUNDED )
OPEN_INTERVAL denotes the bounded open interval (�, �).
GE_LT_INTERVAL denotes the bounded interval [�, �).
GT_LE_INTERVAL denotes the bounded interval (�, �].
CLOSED_INTERVAL denotes the bounded interval [�, �].
GT_SEMI_INTERVAL denotes the unbounded interval (�, +∞).
GE_SEMI_INTERVAL denotes the unbounded interval [�, +∞).
LT_SEMI_INTERVAL denotes the unbounded interval (−∞, �).
LE_SEMI_INTERVAL denotes the unbounded interval (−∞, �].
UNBOUNDED denotes all values (−∞, +∞).
For angular values, the terms “+∞” and “−∞” denote the most extreme valid values for the coordinate-
component.
EXAMPLE 1 In the latitude coordinate-component interval of type GE_SEMI_INTERVAL with value [0.0, +∞), “+∞”
denotes +�/2 radians.
EXAMPLE 2 In the longitude coordinate-component interval of type LT_SEMI_INTERVAL with value (−∞, 0.0), “−∞”
denotes −� radians.
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.6.6 SRF_Region_Status
This data type represents coordinate location with respect to the applicable region and/or extended region
305 © ISO/IEC 2025 – All rights reserved

(see 8.3.2.4) of an SRF. For backward compatibility, the enumerated values below use “SRF_REGION” as
equivalent to applicable region.
SRF_Region_Status ::= ( IN_SRF_REGION,
IN_EXTENDED_REGION_OUTSIDE_SRF_REGION,
OUTSIDE_BOTH_SRF_REGION_AND_EXTENDED_REGION )
IN_SRF_REGION denotes a coordinate that is contained within the applicable region.
IN_EXTENDED_REGION_OUTSIDE_SRF_REGION denotes a coordinate that is contained within the extended
region, but is not contained within the applicable region.
OUTSIDE_BOTH_SRF_REGION_AND_EXTENDED_REGION denotes a coordinate that is contained within the CS
domain, but is not contained within either the applicable region or the extended region.
11.2.6.7 SRF_Region_Type
This data type is used to indicate whether an applicable region or extended region is represented in terms of
the coordinate system of the SRF or in terms of the geodetic coordinate system of the Celestiodetic SRF for
that ORM.
SRF_Region_Type ::= ( COORDINATE_REGION,
GEODETIC_REGION )
COORDINATE_REGION denotes an applicable region or extended region that is represented in terms of the
coordinate system of the SRF.
GEODETIC_REGION denotes an applicable region or extended region that is represented in terms of the
geodetic coordinate system of the Celestiodetic SRF for that ORM.
11.2.7 Selection data types
11.2.7.1 Overview
Selection data types are similar to enumerated data types but form a set of entries that may be extended through
registration. Selection data types are defined to be distinct sub-data types of the numeric data type Integer,
but with specific meanings attached to each value. Selection data types are otherwise processed in the same
manner as enumerated data types. The integer codes are unique within each selection data type, but not
between data types.
In each selection data type the valid values are 0 and greater. Negative code values are implementation
dependent and non-conforming. In each selection data type, the value 0 (UNSPECIFIED) is reserved. Some
API methods and functions allow 0 (UNSPECIFIED) as an input code value and/or an output 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 selection 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 selection 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.
306 © ISO/IEC 2025 – All rights reserved

11.2.7.4 ORM_Code
The selection 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).
11.2.7.5 ORMT_Code
The selection data type ORMT_Code specifies an ORM Template code defined in Clause 7 or by registration.
Table 7.30 is a directory of ORMT specifications, each of which includes a code value and a corresponding
label.
11.2.7.6 Profile_Code
The selection data type Profile_Code specifies a profile of the SRM by its code as defined in Clause 12 or
by registration. Each profile specification includes a code value and a corresponding label.
11.2.7.7 RT_Code
The selection data type RT_Code specifies a reference transformation � . Each RT_Code is specified in
R←S
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. An RT_Code is valid for an ORM only if it has been specified for that ORM. Some API methods also allow
the RT_Code value 0 (UNSPECIFIED) to be used.
API methods or functions that require the RT_Code data type shall also require its associated ORM_Code.
11.2.
...

Bibliography
The following documents provide additional information, which may be of use to users of this document.
NOTE 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 field is grey when a reference is an International Standard.

Identifier Reference
ISO 3166-1:2020, Codes for the representation of names of countries and their subdivisions —

Part 1: Country codes.
ISO/IEC 18023-1:2006, Information technology — SEDRIS — Part 1: Functional specification.
ISO/IEC 18025:2014, Information technology — Environmental Data Coding Specification

(EDCS).
ISO 19111:2019, Geographic information — Referencing by coordinates.
US National Geospatial-Intelligence Agency (NGA). The Universal Grids: Universal Transverse
83582 Mercator (UTM) and Universal Polar Stereographic (UPS). 1st ed. Washington: NGA, 1989.
Technical manual TM 8358.2.
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, 1975.
ALSP
Available from: https://alisondb.legislature.state.al.us/alison/codeofalabama/1975/35-2-1.htm
[viewed 2023-05-12].
Berner, Paul, et al. Orientation, Rotation, Velocity and Acceleration, and the SRM. Online. Ver.
BERN 2.0. Orlando (Florida): The SEDRIS Organization, 2008. Available from:
https://www.sedris.org/srm_desc.htm#papers [viewed 2024-02-21].
Bhavnani, K. H. and Vancour, R. P. Coordinate Systems for Space and Geophysical
Applications. Online. Hanscom Air Force Base (Massachusetts): US Air Force Phillips
BHAV
Laboratory, 1991. Scientific report no. 9, PL-TR-91-2296. Available from:
https://apps.dtic.mil/sti/pdfs/ADA247550.pdf [viewed 2023-05-10].
Bureau International des Poids et Mesures. BIPM technical services: Time Metrology. Online.
BIPM
Available from: https://www.bipm.org/en/time-metrology [viewed 2023-07-19].
Birkel, Paul A., et al. Pushing the Envelope: The Worldwide Low-Resolution Terrain Database.
Online. Proceedings of the SISO 1999 Spring Simulation Interoperability Workshop. Orlando
BIRK
(Florida): SISO, 1999. Available from: https://www.sisostds.org/ [viewed 2023-05-05]. Paper
no. 99S-SIW-016, filename DOC_2455.pdf.
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. Online. Survey
Review, vol. 23, no. 181, p. 323-327. Bristol (UK): Commonwealth Association for Surveying
BOWR
and Land Economy, 1976. Available from:
https://www.scribd.com/document/496093299/bowring1976 [viewed 2024-12-31].
© ISO/IEC 2025 – All rights reserved 691

Identifier Reference
Featherstone, W. E. A comparison of existing co-ordinate transformation models and
parameters in Australia. Online. Journal of Spatial Science (formerly Cartography), vol. 26, no.
CECT
1, p. 13-26. East Perth WA (Australia): Mapping Sciences Institute, 1997. Available from:
https://espace.curtin.edu.au/handle/20.500.11937/34218 [viewed 2023-05-10].
Russell, C. T. Cosmic Electrodynamics. No. 2. Dordrecht (Netherlands): D. Reidel Publishing,
CRUS
1971.
Space Environment Information System (SPENVIS). Dipole approximations of the
DAGF
geomagnetic field. Online. Belgium: SPENVIS, 2018. Available from:
https://www.spenvis.oma.be/help/background/magfield/cd.html [viewed 2023-05-05].
Defence Geospatial Information Working Group (DGIWG). Digital Geographic Information
DIGEST Exchange Standard (DIGEST), Part 3: Codes and Parameters. Online. Ed. 2.1. Washington:
DGIWG, 2000. Available from: https://portal.dgiwg.org/files/3909 [viewed 2023-05-07].
IEEE 1278.1-2012. IEEE Standard for Distributed Interactive Simulation — Application
DIS2012
Protocols.
Dozier, Jeff. Improved Algorithm for Calculation of UTM and Geodetic Coordinates, NOAA
technical report NESS 81. Online. Washington: US National Oceanic and Atmospheric
DOZI
Administration, 1980. Available from: https://repository.library.noaa.gov/view/noaa/30862
[viewed 2023-05-12].
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.
Ito, K. (editor). Encyclopedic Dictionary of Mathematics. 2nd ed. Cambridge (Massachusetts):
EDM
MIT Press, 1993. ISBN 978-0-262-59020-4.
Einstein, Albert. The Meaning of Relativity. 5th ed. Princeton (New Jersey): Princeton
EINS
University Press, 1988.
International Association of Oil & Gas Producers (OGP). EPSG Geodetic Parameter Dataset.
EPSG Online. Ver. 10.066. London: OGP, 2022. Available from: https://epsg.org/archives.html
[viewed 2023-05-03].
Hembree, L. A. Earth Radii used in Numerical Weather Models. Monterey (California): Naval
ERNWM
Research Laboratory, 2005. NRL memorandum report NRL/MR/7543-05-8888.
Fukushima, T. Fast transform from geocentric to geodetic coordinates. Online. Journal of
Geodesy, vol. 73, no. 11, p. 603-610. Heidelberg (Germany): Springer-Verlag Heidelberg,
FUKU
1999. Available from: https://link.springer.com/article/10.1007/s001900050271 [viewed 2023-
05-10].
US National Geospatial-Intelligence Agency (NGA). Geographic Translator (GEOTRANS).
GEOTRANS Online. Ver. 3.9. Bethesda (Maryland): NGA, 2022. Available from: https://earth-info.nga.mil
[viewed 2023-05-26].
International Association of Oil & Gas Producers (OGP), Coordinate Conversions and
GN72 Transformations including Formulas. Guidance Note number 7, part 2. Online. London: OGP,
2022. Available from: https://epsg.org/guidance-notes.html [viewed 2023-05-03].
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.
Lide, D. R. (editor). CRC Handbook of Chemistry and Physics. 81st ed. Boca Raton (Florida):
HCP
CRC Press, 2000. ISBN 978-0-8493-0481-1.
692 © ISO/IEC 2025 – All rights reserved

Identifier Reference
Heikkinen, M. Geschlossene formeln zur berechnung raumlicher geodatischer korinaten aus
HEIK rechtwinkligen korrdinaten. Zeitschrift fur Vermessungswesen, vol. 5, p. 207-211. Germany:
publisher unknown, 1982.
NATO Helmert Datum Transformation Parameters. Online. Available from:
HELM
https://www.sedris.org/srm_desc.htm#transformations [viewed 2024-02-21].
US Department of Defense, US Army Corps of Engineers (Army Geospatial Center).
Handbook for transformation of datums, projections, grids and common coordinate systems.
HTDP
Online. Alexandria (Virginia), 1996. TEC handbook TEC-SR-7. Available from: https://erdc-
library.erdc.dren.mil/jspui/bitstream/11681/11310/1/TEC-SR-7.pdf [viewed 2023-05-12].
Aiken, P., et al. International Geomagnetic Reference Field: the thirteenth generation. Online.
IAGA
Earth, Planets and Space, (2021) 73:49. Available from: https://doi.org/10.1186/s40623-020-
01288-x [viewed 2023-05-12].
Petit, Gerard and Luzum, Brian (editors). IERS Technical Note No. 36. Online. International
Earth Rotation and Reference Systems Service (IERS) Conventions (2010). Frankfurt: IERS,
IERS36
2010. Available from: https://www.iers.org/IERS/EN/Publications/TechnicalNotes/tn36.html
[viewed 2023-05-04].
International Earth Rotation and Reference Systems Service (IERS). IERS - Glossary -
IERSUT1 Coordinated Universal Time. Online. Available from:
https://www.iers.org/IERS/EN/Service/Glossary/ut1.html [viewed 2023-07-19].
International Earth Rotation and Reference Systems Service (IERS). IERS - Glossary -
IERSUTC Universal Time. Online. Available from:
https://www.iers.org/IERS/EN/Service/Glossary/utc.html [viewed 2023-07-19].
Coordinating Committee, Great Lakes Basic Hydraulic and Hydrologic Data (BHHD).
IGLD79 Establishment of International Great Lakes Datum (1955). 2nd ed. Chicago (Illinois): Great
Lakes BHHD, 1979.
Canadian Hydrographic Service (CHS), Department of Fisheries and Oceans.
IGLD85 ESTABLISHMENT OF INTERNATIONAL GREAT LAKES DATUM (1985). Burlington
(Ontario): CHS, 1995.
Ordnance Survey of Ireland (OSi). The Irish Grid: A Description of the Co-ordinate Reference
IGRID
System used in Ireland. Dublin: OSi, 1996.
ISO/IEC Directives, Part 2 — Principles and rules for the structure
...

4 Concepts
4.1 Overview
The SRM provides an integrated framework and precise terminology for describing spatial concepts and
operations on spatial information. 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 of positions, directions, vector quantities, and orientations for physical and abstract
objects,
c) spatial operations and transformations on positions, directions, vector quantities, and orientations,
including coordinate conversions and transformations, and calculations of distances and other
geometric quantities,
d) an application program interface for performing the defined spatial operations,
e) codes and labels to support the encoding and exchange of spatial data,
f) an extensible framework that supports the registration of additional instances of SRM concepts, and
g) profiles to allow subsets of the SRM to be defined to conform to the specific requirements of an
application or an application domain.
This document is based on the following set of foundational and unifying core concepts, which are addressed
in greater detail in the remainder of this clause and subsequent clauses:

a) Spatial points are identified by coordinates in a spatial reference frame associated with a spatial object
of interest, such as the Earth or an engineering model. An object-space is the collection of points
associated with a spatial object of interest (see 4.2.3).
b) Position-space is the Euclidean vector space of dimension � = 1, 2 or 3 that serves as a mathematical
abstraction of object-space of matching dimension. In both position-space and object-spaces,
orthonormal frames are defined by the selection of an origin point and a set of mutually perpendicular
basis vectors. A normal embedding is a length-preserving function that maps positions in position-space
to points in an object-space of the same dimension. There are infinitely many possible normal
embeddings of an �-dimensional position-space for a given object-space (see 4.2.2).
c) An abstract coordinate system assigns a unique coordinate �-tuple defined in a coordinate-space to
each point in a subset of position-space of dimension � or greater. An abstract coordinate system has
a generating function that assigns a coordinate in coordinate-space to a corresponding point in position-
space (see 4.3.1).
d) A spatial coordinate system assigns a unique coordinate in coordinate-space to each point in a region
of object-space. A spatial coordinate system assigns a coordinate in coordinate-space to a unique point
in object-space using a spatial generating function that is the functional composition of an abstract
coordinate system generating function with a normal embedding. Different normal embeddings produce
different spatial coordinate systems (see 4.3.2).
e) A temporal coordinate system is a Euclidean 1D coordinate system that assigns a one-to-one
relationship between temporal coordinate values and instants in time. Temporal coordinate systems are
used when spatial coordinate values are time-dependent to associate unique instants in time with
events or references (see 4.3.3).
f) Orientation is the rotational relationship between a rigid object of interest and a reference. Orientation
is specified in terms of the angular displacement, or attitude, of the object's orthonormal frame with
respect to an orthonormal reference frame (see 4.4).
© ISO/IEC 2025 – All rights reserved 13

g) A reference datum is a geometric primitive, such as a point, directed curve, or oriented surface in
position-space, whose determining characteristics are bound to a measured or conceptual geometric
aspect of a spatial object in an object-space (see 4.5).
h) An object reference model is a set of bound reference datums that implicitly defines a unique normal
embedding of position-space into object-space. An object reference model is a generalised abstraction
of the geodesy notion of a datum (see 4.6).
i) A spatial reference frame is a means of specifying a spatial coordinate system for an object-space. A
spatial reference frame specification includes (1) an object reference model, (2) a compatible abstract
coordinate system, and (3) the binding of object reference model parameters to corresponding abstract
coordinate system parameters (if any). The normal embedding implicitly defined by the object reference
model is then functionally composed with the abstract coordinate system to produce a spatial coordinate
system for the object-space (see 4.7).
j) Vertical offset surfaces are introduced to define heights with respect to equipotential or other complex
surfaces (see 4.8).
Diagrams that illustrate SRM concepts and their relationships can be found in Annex C.
The relationships among some of these concepts are depicted in Figure 4.1. In this figure, spherical coordinate
tuples are defined in a coordinate-space. An abstract spherical coordinate system is then defined by its
generating function, which uniquely assigns spherical coordinate tuples to each point in 3D position-space,
based on its canonical orthonormal frame. A normal embedding implicitly defined by an object reference model
of the Earth is used to map the position-space orthonormal frame to a corresponding orthonormal frame
embedded in the Earth’s object-space. A spatial coordinate system based on this embedded frame allows points
in the Earth’s object-space to be located, and various spatial operations to be performed.

Figure 4.1 — Coordinate-space, position-space, and object-space relationships
The concepts introduced in this subclause are discussed in greater detail in the remainder of this clause. This
document 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 mathematical
concepts, including specialized concepts, and notational conventions used in this document.
In this document, the unit of length is the metre and the unit of angular measure is the radian (see ISO 80000-
3) unless explicitly identified otherwise. Some angular values are specified in the units of either arc degree or
arc second, to support common usage or to prevent loss of precision in data specification.
An application or an exchange format using the data storage structures specified in this document (see 11.5)
may use equivalent units of measure, provided those units are identified. For a unit not defined in ISO 80000-
3, the conversion factor to metre or radian, as appropriate, shall be explicitly stated. One suitable mechanism
for accomplishing the identification of a unit is to use unit and unit scale identifiers as specified in Clause 7 of
ISO/IEC 18025.
When interfacing with the methods and/or functions of the SRM (see 4.10), applications shall use the units of
metre and radian, as appropriate. All length and angular data shall be converted to the units of metre or radian,
as appropriate, before the data is provided as input to an SRM method or function.
14 © ISO/IEC 2025 – All rights reserved

When measures of computational accuracy are being determined, such measurements shall be expressed in
the units of metre and radian, where applicable.
4.2 Coordinate-space, position-space, and object-space
4.2.1 Coordinate-space
A coordinate is an ordered �-tuple (1 � � � 3). A coordinate-component is an individual component of a
coordinate �-tuple. A coordinate-space specifies a set of coordinate �-tuples that forms a Euclidean vector
space (see A.2). The domain of a coordinate system is a replete subset of coordinate space. Such coordinate
�-tuples include, but are not restricted to, Cartesian (�, �, �), polar (�, �), cylindrical (�, �, ℎ), and geodetic
(�, �, ℎ).
Figure 4.2 — A coordinate-space (for spherical coordinates)
Figure 4.2 illustrates the structure of a coordinate-space for 3D spherical coordinate tuples of the form (�, �, �).
The coordinate-components of these tuples are:
�: longitude in radians, such that �� � � � �,
� �
�: spherical latitude in radians, such that � � � � , and
� �
2 2
�: radius in metres, such that 0 � �.
Coordinate-space is further defined in 5.2.1.
4.2.2 Position-space and orthonormal frames
�
Position-space of dimension �, (1 � � � � � 3), is the Cartesian vector space ℝ (see A.2), which serves as
a mathematical abstraction of an object-space. Position-space allows abstract coordinate systems to be applied
to object-spaces for many different types of spatial objects of interest.
An ordered set of � mutually perpendicular unit position vectors forms a canonical Cartesian basis for position-
space, which allows positions, directions, vector quantities, and distance measurements in position-space to be
quantified.
The origin and Cartesian basis vectors together define an orthonormal frame. Every point in position-space is
uniquely represented by a linear combination of the orthonormal frame’s basis vectors represented by a
corresponding �-tuple of scalars in the basis order. An orthonormal frame is right-handed if the vertices of the
triangle formed by its basis unit vectors are in clockwise order when viewed from the origin, as defined in ISO
80000-2.
© ISO/IEC 2025 – All rights reserved 15

Figure 4.3 — 3D position-space and its canonical Cartesian basis
Figure 4.3 illustrates 3D position-space, showing its origin, and the unit vectors that form its canonical Cartesian
basis.
Orthonormal frames and position-space are further defined in 5.2.2 and 5.2.3, respectively.
The position of a point is the directional displacement of that point with respect to a designated point, called the
origin. The position of a point is represented in terms of a position vector. The position of an object is typically
expressed in terms of the position of a representative point within the object.
A direction is represented by a unit vector with respect to an orthonormal frame. Vector quantities, such as
velocity and acceleration, combine a direction vector with a magnitude.
4.2.3 Object-space and normal embeddings
An object-space is the collection of points that is fixed to a designated spatial object of interest. Object-space
provides the application domain context for spatial concepts including positions, directions, vector quantities,
and orientations.
Figure 4.4 — Object-spaces for the Earth and for a CAD model
16 © ISO/IEC 2025 – All rights reserved

The spatial objects of interest in this document include physical and abstract objects. Physical objects are real-
world objects, such as Earth or a building. Abstract objects are conceptual objects including engineering,
mathematical, and virtual models. Figure 4.4 illustrates two object-spaces: one for a physical object (i.e., the
Earth), and one for an abstract object (i.e., a CAD model).
A normal embedding is a distance-preserving function mapping vectors in position-space to points in an object-
space of the same dimension. Position-space together with a normal embedding provides a specific algebraic
model of an object-space by determining an orthonormal frame embedded in the object space. There are
infinitely many normal embeddings of an n-dimensional position-space for a given object-space, depending on
the placement of the origin and direction of the axes. The method of specifying a normal embedding varies
across disciplines and application domains. This document encapsulates these methods within the concepts of
reference datum (see 4.5) and object reference model (see 4.6).
Object-space and normal embeddings are further defined in 5.2.4 and 5.2.5, respectively.
4.3 Coordinate systems
4.3.1 Abstract coordinate systems
An abstract coordinate system assigns a unique coordinate n-tuple to each point in a subset of m-dimensional
position-space (1 � � � � � 3). An abstract coordinate system is comprised of a domain, a range, and a
generating function. The generating function is a smooth, one-to-one function from the domain in �-dimensional
coordinate-space onto the range that is a set of positions in �-dimensional position-space. The generating
function may be parameterized by coordinate system parameters. The domain can be a proper subset of
coordinate-space.
Figure 4.5 illustrates these components for the Equatorial Spherical abstract coordinate system.

Figure 4.5 — Abstract equatorial spherical coordinate system example
In this document, the term “coordinate system”, if not otherwise qualified, means “abstract coordinate system.”
A coordinate system is linear if its generating function is an affine function. Otherwise, it is curvilinear. The
Geodetic 3D coordinate system and all map projection coordinate systems are curvilinear. A linear coordinate
system is orthogonal if its axes are pairwise perpendicular. A Cartesian coordinate system is a linear coordinate
system that is also orthogonal. A three-dimensional coordinate system is right-handed if the vertices of the
triangle formed by its basis unit vectors are in clockwise order when viewed from the origin, as defined in ISO
80000-2.
© ISO/IEC 2025 – All rights reserved 17

The coordinate-space and position-space dimensions characterize a coordinate system type as in Table 4.1.
Table 4.1 — Coordinate system types
Coordinate Dimension of Dimension of
system type coordinate-space position-space
3D 3 3
surface 2 3
curve 1 3
2D 2 2
plane curve 1 2
1D 1 1
Many applications need to perform operations involving multiple related coordinate systems. The relationships
between coordinate systems used in an application often reflect corresponding relationships among the objects
of interest within the application context. Such abstract coordinate system relationships are the foundation for
corresponding spatial coordinate system and spatial reference frame relationships in object-space. This
document provides a set of parameterized localization operators for defining local coordinate systems relative
to base coordinate systems and specifies several standard localized coordinate systems.
It is also useful in some applications to reduce the dimensionality of a coordinate system by fixing the values of
one or more of its coordinate-components. The resulting coordinate-component surfaces and curves are
particularly useful when dealing with curvilinear coordinate systems. Thus, f
...

14 Conformance
14.1 Overview
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 document (14.6).
Functional implementation and exchange format conformance are based on profiles. Profiles are defined in
Clause 12. Conformance of an application to a profile is defined in 14.5.
14.2 Functional implementation conformance
14.2.1 Functional accuracy
The computational accuracies of SRF operations are required in determining the (degree of) conformance of
functional implementations of the SRM. This clause addresses the computational accuracy requirements for
SRF operations.
Computational accuracy requirements are specified as the maximum computational error for an implementation
of an SRF operation over a subset of the CS domain of an SRF, termed an accuracy domain. Annex I presents
methods used to compute various types of errors. The default profile 12.3 specifies the maximum computational
error for three categories of computational error: position, direction, and ratio, as well as accuracy domains for
various sets of SRFs included in the profile. The computational accuracy requirement does not apply to 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 document. Annex B presents advisory guidelines for
implementation efficiency and error control. This clause does not define the application requirements or dictate
the functional content of applications that use SRM implementations.
An accuracy domain is a set of constraints that specify:
a) a subset of the CS domain for an SRF,
b) the parameter values that realise the CS domain for the SRFs that can be instantiated from an SRFT,
c) the parameter values that are common to a collection of SRFTs.
To be conformant, the computational accuracy requirements need only to be satisfied for coordinates in the
accuracy domain. The CS domain subset specified by an accuracy domain shall be non-empty and both closed
and bounded (see A.3).
When an accuracy domain is defined for an SRF, it can be specified in one or more of the following ways:
a) constraints on coordinate-component values for one or more coordinate-components,
b) constraints that specify a region of the CS range, which indirectly constrains coordinate-component
values to those that have CS generating function values in that region,
1) the CS range region can also be specified in terms of other functions on the CS domain, such as
Euclidean distance,
© ISO/IEC 2025 – All rights reserved 437

2) for map projections, the CS range region can be specified in terms of one or more constraints on
3D geodetic CS coordinate-component values,
EXAMPLE 1 For an EQUATORIAL_SPHERICAL SRF an accuracy domain is specified with a value constraint on the
radius coordinate component using a closed bounded interval: 0,01m ≤ � ≤ 1 000 000 000m.
EXAMPLE 2 For a LOCOCENTRIC _EUCLIDEAN_3D SRF an accuracy domain is specified by restricting the CS range
� � � �
to the region satisfying the restriction: � ��, 0,0,0 � ≤ 1 000 000 000m for all � in the CS domain where � ��, 0,0,0 � is the
� �
Euclidean distance function (see 10.6).
� ⁄ �
EXAMPLE 3 For a TRANSVERSE_MERCATOR SRF with longitude of origin � = 14,4 � 180 , an accuracy domain
origin
is specified by restricting the CS range to the region bounded by geodetic constraints:
−3,5��⁄180� ≤ � − 14,4��⁄180� ≤ 3,5��⁄180�,
� ⁄ � � ⁄ �
−89,5 � 180 ≤ � ≤ 89,5 � 180 ,  and
−50 000m ≤ ℎ ≤ +1 000 000m.
When an accuracy domain is defined for an SRFT, it applies to any SRF that can be instantiated from that
SRFT. In that case, an accuracy domain can specify constraints that depend on SRFT parameter values (if
any), as well as on CS coordinate-component values. Individual constraints can include any combination of CS
coordinate-component values and/or SRFT parameter values. Constraints including only SRFT parameter
values are commonly used to constrain the ORM RDs that can be used by an SRFT.
When an accuracy domain is defined for a collection of SRFTs, the SRFTs in the collection shall share common
CS coordinate-components and/or SRFT parameters:
a) each coordinate-component used in a constraint shall be common to all the SRFTs in the collection,
b) each SRFT parameter used in a constraint shall be common to all the SRFTs in the collection.
EXAMPLE 4 For SRFT TRANSVERSE_MERCATOR, an accuracy domain is specified with:
� ⁄ � � ⁄ �
−3,5 � 180 ≤ � − � ≤ 3,5 � 180 , (using the SRFT parameter � )
origin origin
� ≤ 6 400 000m and � ≤ 1/150, and (using SRFT parameters � and �)
0,01m ≤ � (using SRFT parameter � )
� �
The error criteria for operations on SRFs derived from a given SRFT are determined by an accuracy domain
specification together with a set of error bounds. Operations on the SRFs derived from the SRFT satisfy the
error criteria if the error at any coordinate in the accuracy domain, determined by the accuracy domain, is less
than the error bounds for those operations.
A computational accuracy requirement of a profile consists of the error
...

5 Coordinate systems
5.1 Overview
Coordinate systems provide the mathematical underpinnings for spatial operations in multidimensional space.
A coordinate system assigns coordinates to points in space and/or time. This document defines coordinate
systems within the scope of three conceptual spaces: coordinate-space, position-space, and object-space.
Coordinate-spaces specify the sets of coordinate �-tuples that form the domains of coordinate systems.
Position-spaces are abstract Euclidean vector spaces that provide the mathematical and geometric foundation
needed to define spatial operations. Object-spaces are Euclidean vector spaces associated with specific spatial
objects of interest, such as the Earth, a building, or a vehicle. Coordinate-spaces, position-spaces, and object-
spaces, and the relationships among them, are normatively defined in 5.2.
An abstract coordinate system specifies a function, termed a generating function, which assigns unique �-tuples
� �
in a domain in coordinate-space to points in an �-dimensional position-space 1 ≤ � ≤ � ≤ 3 . Abstract
coordinate systems are normatively defined, and many types of abstract coordinate systems are specified, in
5.3.
A spatial coordinate system extends the assignment of unique coordinate �--tuples from points in a position-
space to points in an object-space. The assignment function combines an abstract coordinate system generating
function with a normal embedding that maps the orthonormal frame within position-space to a corresponding
orthonormal frame within object-space. Spatial coordinate systems are normatively defined in 5.4. The
relationships among coordinate-space, position-space, abstract coordinate systems, object-space, and spatial
coordinate systems are shown in Figure 5.23.
The ability of a spatial coordinate system to assign a unique coordinate to a point in an object-space assumes
that the position of the point in object-space is static. In a dynamic system, that assumption may not hold unless
the spatial coordinate system is associated with a particular moment in time. Temporal coordinate systems
provide a standard way of associating time with a spatial coordinate system. Temporal coordinate systems are
normatively defined in 5.5.
5.2 Coordinate-space, position-space, and object-space
5.2.1 Coordinate-space
2 3
A coordinate is an ordered �-tuple �1 ≤ � ≤ 3�. A coordinate-component is an individual element of a
th th
coordinate �-tuple. The k coordinate-component �1 ≤ � ≤ 3� is the � component of a coordinate �-tuple. A
coordinate system may optionally specify coordinate-component names and symbols in a specified order. In 3D
coordinate systems, the 3rd coordinate-component may be identified as the vertical coordinate-component.
A coordinate-space specifies a set of coordinate �-tuples that forms the domain of a coordinate system. Such
coordinate �-tuples include Cartesian ��, �, ��, polar ��, ��, cylindrical ��, �, ℎ�, and geodetic ��, �, ℎ�. A
coordinate-space may include constraints on coordinate �-tuple components in such domains.

The ISO 19111 term for this concept is “coordinate tuple”.
The ISO 19111 term for this concept is “coordinate”.
© ISO/IEC 2025 – All rights reserved 31

Figure 5.1 — A coordinate-space (including the domain for spherical coordinate n-tuples)
Figure 5.1 illustrates the structure of a coordinate-space for 3D spherical coordinate tuples of the form ��, �, ��.
The coordinate-components of these tuples are:
�: longitude in radians, such that �� � � ≤ �,
� �
�: spherical latitude in radians, such that � � � � , and
� �
2 2
�: radius in metres, such that 0 � �.
This coordinate-space defines the domain for a spherical coordinate system (see 5.3.8.4) as a subset
(highlighted in grey) of the coordinate-space.
5.2.2 Orthonormal frames
An orthonormal frame within a Euclidean vector space, in 2 or 3 dimensions, consists of an origin � and an
ordered set of mutually perpendicular unit basis vectors � , � , and, in the 3D case, � . Orthonormal frames
� � �
provide uniform references for measuring distances and angles in both position-space and object-space and
are the foundation upon which coordinate systems are constructed. The 3D case is depicted in Figure 5.2.

Figure 5.2 — A right-handed orthonormal frame
A 3D orthonormal frame is termed right-handed if the vertices of the triangle formed by its basis unit vectors are
in clockwise order when viewed from the origin, as defined in ISO 80000-2, and shown in Figure 5.3. In this
document, all 3D orthonormal frames shall be right-handed.
32 © ISO/IEC 2025 – All rights reserved

5.2.3 Position-space
�
Position-space of dimension �, �1 ≤ � ≤ � ≤ 3�, is the Euclidean vector space ℝ as defined in A.2.
� �
Mathematical concepts of ℝ as a vector space, the point-set topology of ℝ , the theory of real-valued functions
�
on ℝ , and algebraic and analytic geometry, including the concepts of point, line, and plane, are all assumed
and hold.
Position-space serves as a mathematical abstraction of object-spaces so that the methods of linear algebra and
multivariate calculus can be applied to spatial concepts, including abstract coordinate systems and the
computational aspects of spatial operations. The purpose of position-space is to provide flexibility in applying
different types of coordinate systems to object-spaces for many different types of spatial objects of interest.
The position of a point is the displacement of that point with respect to a designated reference point, called the
origin. Each point in Euclidean vector space is associated with the position vector that extends from the origin
to that point with length equal to the Euclidean distance between the origin and that point. Thus, points in
Euclidean space and position vectors with respect to the origin are equivalent concepts. The position of an
object is typically expressed in terms of the position of a representative point within the object.
A direction in a Euclidean vector space is represented by a unit vector. A vector quantity, expressing a physical
measurement such as velocity or acceleration (at a given instant in time), is represented by a direction vector
combined with a magnitude. Velocity is a vector quantity that expresses the rate of change of position.
Acceleration is a vector quantity that expresses the rate of change of velocity.
The orthonormal frame that is inherent to position-space forms a canonical Cartesian basis. This Cartesian
basis allows positions, directions, vector quantities, and distance measurements in position-space to be
quantified.
Figure 5.3 — 3D position-space, its orthonormal frame, and its canonical Cartesian basis
Figure 5.3 illustrates 3D position-space, showing its origin, its inherent orthonormal frame, and its canonical
Cartesian basis. The axes of the Cartesian basis are aligned with the basis vectors of the orthonormal frame.
�
�
� �
Position vectors in two and three dimensions are denoted as ��, �� ≡ � � and ��, �, �� ≡ ���, respectively (see
�
�
A.2). These components, unless otherwise indicated, are specified with respect to the canonical Cartesian basis
and origin.
© ISO/IEC 2025 – All rights reserved 33

� � �
The canonical origin for ℝ is the zero vector � � �0,0� . The canonical Cartesian basis vectors for ℝ are � �
�
� �
�1,0� , � � �0,1� .
�
� � �
The canonical origin for ℝ is the zero vector � � �0,0,0� . The canonical Cartesian basis vectors for ℝ are � �
�
� � �
� � � � � �
1,0,0 ,  � � 0,1,0 ,  � � 0,0,1 .
� �
5.2.4 Object-space
Object-space is the Euclidean vector space (a universe ) that is fixed to a designated spatial object of interest.
Object-space provides the application domain context for spatial concepts including positions, directions, vector
quantities, and orientations.
Figure 5.4 — Object-spaces for the Earth and for a CAD model
The spatial objects of concern in this document include physical and abstract objects, as illustrated in Figure
5.4. Physical objects are real-world objects, such as Earth or a building. The length of one metre has intrinsic
meaning in the object-space of a physical object. Abstract objects are conceptual objects including engineering,
mathematical, and virtual models. A length of one metre does not have intrinsic meaning in the object-spaces
of abstract objects. Thus, to relate abstract object-spaces to other (physical or abstract) object-spaces, each
abstract object-space is required to have a designated length scale.
At any given instance in time, the position of a point in object-space is fixed with respect to the spatial object of
interest. This is done either by a time-invariant constant or a time-dependent function. If points and the spatial
object of interest have a time-dependent relationship, the positions of the points shall be qualified by a time
value. Thus, at a specified time, the points and the spatial object of interest have a fixed spatial relationship.
EXAMPLE 1 The Sun and the Earth are both physical objects. In the object-space of the Sun, the Sun is the spatial
object of interest and is fixed and the Earth moves according to a time dependent function. In the object-space of the Earth,
the Earth is the spatial object of interest and is fixed and the Sun moves according to a different time dependent function.
EXAMPLE 2 At any given time the International Space Station (ISS) has a unique and unambiguous position in the
object-space of the Earth.
The set of all continuations of a spatial object is termed the universe of the object. In physics, this is termed “the space of
the object”. [EINS]
34 © ISO/IEC 2025 – All rights reserved

EXAMPLE 3 At any given time each component of the ISS has a fixed position in the object-space of the ISS.
EXAMPLE 4 A solar collector component of the ISS was manufactured in compliance with an engineering model. The
engineering model was designed in the object-space of an abstract CAD/CAM model. The physical solar collector was
constructed in its own physical object-space.
An object-space is a Euclidian space. In general, however, an object-space is not a vector space. Once a point
in object-space is designated as an origin point, it becomes a vector space with respect to that origin and all
points in the object-space are vectors, each with length and direction given as the distance and direction of the
point from the origin.
5.2.5 Normal embeddings
A normal embedding is a distance-preserving function mapping vectors in position-space to points in an object-
space of the same dimension. A function � from position-space to object-space is distance-preserving if for any
two positions � and � in position-space, the Euclidean distance ���, �� is equal to the measured distance in
� � � �
object-space from � � to � � in metres. The distance-preserving property implies that a normal embedding
is one-to-one and continuous. Normal embeddings also preserve angles and areas.

Figure 5.5 — A normal embedding that maps position-space to an object-space
Position-space together with a normal embedding provides a specific algebraic model of an object-space by
determining an orthonormal frame within the object space. This frame is termed the embedded frame and is
determined as follows. In the 3-dimentional case, as shown in Figure 5.5, the position-space orthonormal frame
is formed by the origin 0 and unit basis vectors � , � , and � . The normal embedding � forms an orthonormal
� � �
frame within object-space with origin ���� and basis vectors ��� �, ��� �, and ��� �. Since � is distance
� � �
preserving, these vectors are orthogonal unit vectors, thus an embedded frame is an orthonormal frame and �
is then an isomorphism between position-space and object-space. A normal embedding of a 3D position-space
is right-handed if this frame is a right-handed frame. Normal embeddings for 2-dimensional object-space form
orthonormal frames in a similar way.
The point ���� is termed the origin of the normal embedding �. The point ��� � is the � -axis unit point of the
� �
normal embedding �. Depending on the dimension of position-space, ��� � is the � -axis unit point and ��� �
� � �
is the � -axis unit point. Normal embeddings are used to relate abstract coordinate systems for position-space
�
to spatial coordinate systems for an object-space (see 5.4).
There are infinitely many normal embeddings of an �-dimensional position-space for a given object-space,
depending on placement of the origin and direction of the axes.
© ISO/IEC 2025 – All rights reserved 35

There are infinitely many ways to select the origin of the embedding in the object-space. The origin can be
located at any point within the spatial object of interest, at any point on its surface, or at any point nearby in
space. Common selections include the centre of mass of the object, its geometric centre, or a corner of the
object (assuming it has corners) or its bounding volume such that the object is completely within the first octant.
Given a selected origin, there are infinitely many ways to orient the axes. If the object is a celestial body, the
axes could be aligned with its rotational axis, its magnetic field axis, or the direction of the closest star (such as
the Sun). If the object is a vehicle, the axes could be aligned based on its direction of forward motion or other
common reference orientations. If the object is located on, or near, the surface of the Earth, common selections
include east-north-up (ENU) and north-east-down (NED).

Figure 5.6 — Two distinct normal embeddings that map position-space to an object-space
Figure 5.6 illustrates two distinct normal embeddings for a given object-space, each determining a different
embedded frame. Each embedding assigns the origin ��� to different points on the spatial object of interest
(� ��� and � ���, respectively), and assigning the basis vectors (� , � , � ) to different directions
� � � � �
� � � � � � � � � � � �
(� �� , � �� , � �� and � �� , � �� , � �� , respectively)) relative to the object, providing two distinct
� � � � � �
algebraic models of that object-space. In the figure, the two embedded frames are depicted in two different
colours. In the object space, � and � refer to the same point � ≡ � �� �� ≡ � �� � on the object, expressed in
� � � � � �
each of the two embedded frames.
A similarity transformation is used to express the relationship between one embedded frame wit
...

International
Standard
ISO/IEC 18026
Third edition
Information technology — Spatial
reference model (SRM)
2025-07
Technologies de l'information — Modèle de référence spatial (SRM)
Reference number
© ISO/IEC 2025
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
the internet or an intranet, without prior written permission. Permission can be
...

9 Designated spatial surfaces and vertical offsets
9.1 Overview
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 document, 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 the vertical offset surface and the RD surface
is termed 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 that 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) approximations of mean sea level surfaces based on sounding and tidal data.
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.
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.
An equipotential surface is an implicitly defined surface given by ���, �, �� − � = 0, where � is a potential function
defined in (a portion of) position-space and � is a value in the range of �.
If � 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 2025 – All rights reserved 271

NOTE The geoid cannot be measured directly. Current models of the Earth’s gravity potential are usually realised 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 (see 8.4.3).
The vertical coordinate-component zero surface is the set of points for which the vertical coordinate-component
value is zero (see 5.2.1). Given a point pp on the vertical coordinate-component zero surface that is in the region
pp
of a VOS, the vertical offset at � is the value of the vertical coordinate-component at the intersection of the VOS
� �
with the vertical coordinate-component curve that contains �. The vertical offset at � is denoted � � . If � is not
in the region of a VOS or if a VOS has not been specified, the vertical offset at � 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 �
� � � �
on the oblate ellipsoid (or sphere) with surface geodetic coordinate �, � is denoted by � �, � .
In many cases, the values ���, �� are not known or the values are approximately known at specific locations.
When a DSS has a DSS model, the ���, �� values may be computed. If a DSS is a VOS for two SRFs, SRF
A
� �
and SRF , and if the vertical offset function for SRF � �, � is known, then the vertical offset function for SRF
B A B
�
� ��, �� may be computed from � as follows:
� �
′ ′ ′
Each SRF coordinate of the form � = ��, �, � ��, ��� lies on the VOS. If � = �� , � , ℎ � is the corresponding
A
� � �
′ ′ ′
coordinate representation in SRFB, then � �� , � � = ℎ .
�
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.

Figure 9.1 — Vertical offset surface for ellipsoidal height
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, ���, �� 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).
272 © ISO/IEC 2025 – All rights reserved

Figure 9.2 — Vertical offset surface tangent plane
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 � in the
plane is the distance from � to the VOS along a line normal to the plane (see Figure 9.2).
9.4 Geoidal separation
� � � �
If the VOS is a geoid, � �, � is termed 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.

Figure 9.3 — Geoidal separation
NOTE The geoidal separation is often published as a table of values of ���, ��.
9.5 Vertical offset height and elevation
Given a VOS with respect to an SRF with vertical coordinate-component ℎ, the vertical offset height ℎ at point
�
� is defined as ℎ = ℎ − ����.
�
If the VOS is a geoid, then ℎ is termed the elevation of � with respect to the geoid.
�
EXAMPLE If the SRF is derived from SRFT CELESTIODETIC and the coordinate of � is ��, �, ℎ�, then ℎ = ℎ − ���, ��
�
(see Figure 9.4).
© ISO/IEC 2025 – All rights reserved 273

Figure 9.4 — Vertical coordinate-component with respect to a vertical offset surface
NOTE 1 ℎ is an approximation of the distance from � to the VOS. In general, the vertical coordinate-component curve
�
intersection with the VOS is not perpendicular to the VOS. When the intersection is not perpendicular, ℎ does not equal 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.
9.6 Use of vertical offset height in spatial referencing
If a DSS is a VOS for a 3D SRF, and � = �� , � � is a surface coordinate in the induced surface SRF, then �
� �
together with vertical offset height ℎ represents a unique location in object-space. If ���� is known, then the
�
SRF 3D coordinate of that location is �� , � , ℎ � �����. In this case, the 3D coordinate may be changed to other
� � �
SRF coordinate representati
...

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.
The procedures used to develop this document and those intended for its further maintenance are described in
the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the different types of
documents should be noted. This document was drafted in accordance with the editorial rules of the ISO/IEC
Directives, Part 2 (see www.iso.org/directives or www.iec.ch/members_experts/refdocs).
ISO and IEC draw attention to the possibility that the implementation of this document may involve the use of
(a) patent(s). ISO and IEC take no position concerning the evidence, validity or applicability of any claimed
patent rights in respect thereof. As of the date of publication of this document, ISO and IEC had not received
notice of (a) patent(s) which may be required to implement this document. However, implementers are cautioned
that this may not represent the latest information, which may be obtained from the patent database available at
www.iso.org/patents and patents.iec.ch. ISO and IEC shall not be held responsible for identifying any or all such
patent rights.
Any trade name used in this document is information given for the convenience of users and does not constit
...

Index
ε-neighbourhood . 442 celestiocentric SRFT . 222
2D spatial reference frame . 211 celestiodetic SRFT . 224
3D spatial reference frame . 211 celestiomagnetic OBRS . 204
celestiomagnetic SRFT . 234
A
central scale . 59
abstract coordinate system . 37
change of basis . 121
abstract object . 34
Clairaut constant . 298
accuracy domain . 437
class . 301
affine . 443
class instance . 301
angle between two curves . 446
closed curve . 446
applicable object reference model to a
spatial reference frame template . 221 closed set . 442
applicable region . 211 closure of a set . 442
description. 212 closure point . 442
specification . 212 common error conditions . 309
approximation error. 460 compatible normal embedding . 180
arc length . 448 component function . 442
arctan2 function . 448 composition of functions . 443
Aries true of date . 196 computational accuracy requirement . 438
augmented equidistant cylindrical CS . 93 computational error . 460
augmented Lambert conformal conic CS . 89 conformal map projection . 53
augmented map projection . 60 conformance . 437
augmented Mercator CS . 80 of a functional implementation . 438
augmented oblique Mercator spherical CS . 82 of a language binding . 439
augmented polar stereographic CS . 91 of an application . 439
augmented transverse Mercator CS . 85 of an exchange format . 439
azimuth of C at p . 446 conic classification . 58
azimuthal CS . 106 conic projection function . 452
azimuthal cylindrical CS . 113 connected . 447
azimuthal spherical CS . 70 continued normal vector . 447
convergence of the meridian . 55
B
coordinate . 31
backward azimuth . 296
coordinate of a position. 38
basic data type . 301
coordinate system domain . 37
binding constraint . 182
coordinate system localization . 45
bound reference datum . 160
coordinate system parameters . 38
C
coordinate system range . 37
canonical basis . 441
© ISO/IEC 2025 – All rights reserved 697

coordinate system type . 38 elevation . 273
coordinate-component . 31 ellipse, implicitly defined . 448
coordinate-component curve . 42 ellipse, parametrically specified . 445
coordinate-component surface . 41 ellipsoid of revolution . 444
coordinated universal time . 119 embedded frame . 35
coordinate-region . 212 enumerated data type . 303
coordinate-space . 31 epoch . 118
correction . 638 equator . 43
cross product . 442 equatorial inertial OBRS . 196
curve generating function. 447 equatorial inertial SRFT . 235
curvilinear coordinate system . 43 equatorial plane. 5
curvilinear spatial reference frame . 211 equatorial spherical CS . 67
cylindrical classification . 57 equidistant cylindrical CS . 93
cylindrical CS . 77 equidistant cylindrical SRFT . 244
cylindrical projection function . 451 equinox . 196
equipotential surface . 271
D
error criteria for operations on SRFs. 438
deprecation . 638
Euclidean 1D CS . 112
designated spatial surface . 271
Euclidean 2D CS . 103
digitization error . 460
Euclidean 3D CS . 64
dimension of an object reference model . 210
Euclidean distance . 295, 441
directed curve . 445
Euclidean metric. 441
direction. 33
extended region . 211
direction at c . 218
extended region specification . 212
direction cosine matrix . 124
directional point distortion . 53 F
display coordinate . 54 false easting . 59
distance-preserving function . 35 false northing . 59
dot-product . 441 first derivative . 443
DSS model . 271 first point of Aries . 196
dynamic temporal coordinate system . 118 flattening . 444
forward azimuth. 296
E
Earth gravitational model . 5 G
Earth reference model . 182 general rotate-scale-translate 2D STT . 173
easting. 51 general rotate-scale-translate 3D STT . 172
eccentricity . 444 generalized Helmert STT (CFR) . 176
ecliptic longitude of the Sun . 199 generalized Helmert STT (PVR) . 175
ecliptic plane . 5 generating function . 37
698 © ISO/IEC 2025 – All rights reserved

generating projection . 51 inertial direction . 196
geocentric solar magnetospheric SRFT . 237 inner product . 441
geocentric SRFT . 223 integrated temporal coordinate system . 118
geodesic . 295, 448 interior of a set . 442
destination operation . 297 interior point . 442
direct problem . 297 international atomic time . 119
distance . 295 inverse generating function . 38
distance operation . 297
J
indirect problem . 297
Jacobian determinant . 443
on an oblate ellipsoid . 448
Jacobian elliptic functions . 449
geodetic 3D CS . 73
Jacobian matrix . 443
geodetic azimuth . 54
K
geodetic datum . 5
th
k coordinate-component . 31
geodetic SRFT . 224
th
k -axis . 43
geodetic-region . 212
geoid . 271 L
geoidal separation . 273
Lambert conformal conic CS . 89
geomagnetic SRFT . 234 lambert conformal conic SRFT . 242
geomagnetic z-y rotate STT . 179
latitude of origin . 59
global model . 182 latitude of true scale . 59
gradient . 442
latitudinal point distortion . 53
Greenwich sidereal hour angle . 197 linear coordinate system . 43
linear function . 443
H
linear spatial reference frame . 211
heliocentric Aries ecliptic OBRS . 201
local model . 182
heliocentric planet ecliptic OBRS . 202
local space azimuthal 2D SRFT . 246
heliocentric planet equatorial OBRS . 203
local space polar 2D SRFT . 247
heliospheric Aries ecliptic SRFT . 238
local space rectangular 2D SRFT . 245
heliospheric Earth ecliptic SRFT . 238
local space rectangular 3D SRFT . 223
heliospheric Earth equatorial SRFT . 239
local tangent frame . 48, 217
homogeneous matrix 3x3 2D STT . 174
local tangent space azimuthal spherical
homogeneous matrix 4x4 3D STT . 174
SRFT. 228
horizontal datum shift. 285
local tangent space cylindrical SRFT . 231
I local tangent space Euclidean SRFT . 226
identity 2D STT . 167 local tangent vectors . 48
identity 3D STT . 167 localization operator . 45
implicit surface . 443 localization parameters . 45
induced surface coordinate system . 41 localized coordinate system. 45
© ISO/IEC 2025 – All rights reserved 699

localized frame . 47 northing . 51
lococentre . 45 n-tuple of real numbers . 441
lococentric azimuthal CS . 107 null object . 303
lococentric azimuthal cylindrical CS . 114
O
lococentric azimuthal spherical CS . 72
object binding rule . 195
lococentric coordinate system . 45
object binding rule set . 194
lococentric cylindrical CS . 79
object life cycle . 327
lococentric equatorial spherical CS . 68
object reference model . 180
lococentric Euclidean 2D CS . 104
object_reference . 303
Lococentric Euclidean 3D CS . 65
object-dynamic embedding . 181
lococentric Euclidean 3D SRFT .
...

0 Introduction
0.1 Purpose
Spatial information processing requires a robust capability to describe geometric properties such as position,
direction, orientation, and distance. Information is sometimes spatially referenced to local structures (Example:
interior walls and doorways within a building) or local regions (Example: streets and buildings within a city), or
to the Earth as a whole (Example: global weather). Information is sometimes spatially referenced to other
celestial bodies (Examples: astronomical, orbital, and geomagnetic observations). Information is also
sometimes 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 are sometimes specified relative to moving
objects (Examples: planets and spacecraft), and therefore provide spatial 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 document defines the conceptual model and the methodologies that allow the description, and
tr
...

10 Operations
10.1 Overview
This document specifies operations on SRF coordinates and, in the case of 3D object-spaces, on SRF spatial
directions, vectors and orientations. All SRFs rely on their respective embedded frames in object-space to
provide a reference orthonormal frame for such operations. Underlying some of these operations are the
similarity transformations relating two ORMs (two SRFs with the same ORM is treated as a special case).
Similarity transformations are treated first in 10.3. The general case of changing the coordinate of a position in
one SRF to its corresponding coordinate in another SRF is specified in 10.4, followed by important special
cases. The specification of a spatial direction, vector, or orientation in the context of an SRF is defined, and
operations for changing these representations from one SRF to their corresponding representations in another
SRF are specified in 10.5.
Euclidean distance in 2D and 3D object-space is specified in 10.6. Geodesic distance and azimuth on the
surface of an oblate ellipsoid (or sphere) are specified in 10.7.
10.2 Symbols and terminology
An important category of spatial operations is changing the representation of spatial information in one SRF to
the representation in a second SRF. For these SRF 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 symbols in Table 10.1 are used throughout this clause.
Table 10.1 — Symbols
Symbol Definition
CS spatial coordinate system of SRF
S S
ORM object reference model of SRF
S S
ORM reference ORM for a given spatial object
R
SRF source spatial reference frame
S
SRF target spatial reference frame
T
� coordinate of a position in SRF
S
S
� () Euclidean distance
�
� () geodesic distance
�
� normal embedding
� extended region of SRF
S
S
� embedded frame of SRFS
S
� spatial generating function of CSS
S
Dom�� � domain of the generating function �
S S
Rng�� � range of the generating function �
S S
� similarity transformation from frame S to frame T

T←S
� identity matrix (or operator)
� localized orthonormal frame
� localization operator (3D)
3D
© ISO/IEC 2025 – All rights reserved 279

Symbol Definition
� rotation matrix from frame S to frame T
T←S
� direction vector in SRFS
S
� mapping equations for SRFS
S
� position vector
� inverse mapping equations for SRF
S
S
�, �, �, � localization parameters
� rotation operator
� applicable region of SRFS
S
� vector quantity in SRF
S
S
� world 3x3 transformation matrix
�
�
� � 3D position vector components in SRF
S
�
S
��⃗
displacement vector from the origin of frame T to the origin of frame S
Δ
T←S
Δ�
���
origin displacement vector components in SRFS
Δ�
S
� �
� , � , ℎ geodetic coordinate tuple for a position in SRFS
S S S
σ scale factor from frame S to frame T
T←S
� change of basis operator from frame S to frame T
T←S
10.3 ORM operations
10.3.1 Overview
The similarity transformation (see 7.3.2) � between two object reference models, source ORM and target
S
T←S
ORM underlies the coordinate operations in 10.4. There are two cases, depending on whether ORM and
T S
ORMT represent the same object, or represent two different objects.
The case where ORMS and ORMT represent the same object is addressed in 10.3.2. Although objects are often
represented by only a single object reference model, some objects, such as the Earth, are represented by many
different object reference models (see Annex E). Given a set of � object reference models for an object, there
are ��� − 1� possible source and target ORM pairs. Instead of specifying all possible similarity transformations
among these object reference models, this document reduces the requirement to specifying the reference
transformation � from each source ORM for the object, ORM to the designated reference ORM for the
S
R←S
object, ORMR.
The more general case where ORM and ORM represent two different objects is addressed in 10.3.3. This
S T
includes subcases where one or both objects are represented by multiple object reference models, and where
ORM and/or ORM are not the reference object reference models for their respective objects. It also includes
S T
subcases with different types of relationships between the two objects (see 8.4).
10.3.2 Relating different ORMs for the same object
If ORMS and ORMT are different object reference models that represent the same object, and therefore share
the same reference ORM, ORM , the similarity transformation � is the composition of their reference
R
T←S
transformations � and � , the inverse of � as shown in Figure 10.1. This is the common datum
R←S T←R R←T
transformation operation.
280 © ISO/IEC 2025 – All rights reserved

� � � ∘ � (10.1)
T←S T←R R←S
Figure 10.1 — Composed transformations for a single object
If ORMS is the reference ORM for the object, � reduces to the identity �. Similarly, if ORMT is the reference
R←S
ORM for the object, � reduces to the identity �.
T←R
If ORMS and ORMT are identical, the similarity transformation � reduces to the identity � (see 10.4.3 and
T←S
10.4.4). This subcase includes the relationship between a regional SRF and another SRF used as a reference
(see 8.4.2).
If ORMS is an object-fixed ORM, its reference transformation � is a type of similarity transformation. Any 3D
R←S
or 2D similarity transformation may be represented with the STT ROTATE_SCALE_TRANSLATE in the 3D case
or STT ROTATE_SCALE_TRANSLATE_2D in the 2D case. Thus, using the notation of the STT formulation,
� may be represented as:
R←S
� � �
��⃗
��� � � ���� � ≡ Δ � σ � ���
(10.2)
R←S R←S R←S R←S
� � �
R S S
NOTE For the Earth, the processes by which object reference models are established are based on physical
measurements. These measurements are subject to error, and therefore introduce various types of relative
distortions between object reference models. The scale factor σ in Equation 10.2 should equal 1,0 since each
R←S
ORM is for the same object-space. However, values very close to 1,0 are allowed to account for small distortions
(see 7.3.2). The reference transformation � from ORM to the reference ORM is also a similarity
T R
R←T
transformation.
The similarity transformation � is:
T←R
� � �
�� ��
��⃗
� � �
� �� � � � � �� � � � � � �� �� � − Δ �
T←R R←T � R←T R←T
R←T
� � �
R R R
�
��
��⃗
� Δ � � � �� ���
T←R � R←T
R←T
�
R
� ��
Because the matrix � is a rotation matrix, its transpose � is also its inverse � . The inverse of �
R←T R←T R←T R←T
is also the matrix � corresponding to the reverse rotations of ORM with respect to ORM . In particular:
T R
T←R
�� �
� � � � �
T←R R←T R←T
and
� �
��⃗
� ���� � � Δ � � � �� ��� .
T←R T←R � T←R
R←T
� �
R R
© ISO/IEC 2025 – All rights reserved 281

The composite operation � � � ∘ � reduces to:
T←S T←R R←S
� � �
σ
R←S
��⃗
� ���� � � � ∘ � ���� � � Δ � � � �� ���
T←S T←R R←S T←S � T←S
R←T
� � �
S S S
(10.3)
where:
��⃗ ��⃗ ��⃗
� � � � , and Δ � Δ � � � �� Δ
T←S T←R R←S T←S T←R � T←R R←S
R←T
If the rotations � and � are equal, then � is the identity matrix, and if σ � � , � simplifies
R←S R←T T←S R←S R←T T←S
to a translation of the origin:
�
�
��⃗
� �� � � � Δ � ��� .
�
T←S T←S
�
� S
S
Equation 10.1 and Figure 10.1 also apply to the 2D case.
If the source ORMS is a time-dependent ORM for a spatial object, ORMS��� shall denote the source ORMS at
� � � �
time �, and � � shall denote the similarity transformation from ORMS � to the object-fixed reference ORMR.
R←S
For a fixed value of time � , Equation 10.1 and Figure 10.1 generalize to � �� � � � ∘ � �� �. The
� T←S � T←R R←S �
generalization to a time-dependent target ORM ��� is � �� � � � �� � ∘ � . The generalization when
T
T←S � T←R � R←S
both ORMs are time-dependent at time � is � �� � � � �� � ∘ � �� �.
� T←S � T←R � R←S �
EXAMPLE ORMS(�) is the ORM EARTH_INERTIAL_J2000r0 at time �. ORMR is the Earth reference ORM WGS_1984.
Because ORM ��� and ORM share the same embedding origin, the � ��� transformation is a (rotation) matrix
S R
R←S
multiplication operation (without translation). The matrix coefficients for selected values of � account for polar motion, Earth
rotation, nutation, and precession. Predicted values for these coefficients are computed and updated weekly by the
International Earth Rotation and Reference Systems Service (IERS) [IERS36]. See 7.5 for other examples of dynamic ORM
reference transformations.
10.3.3 Relating ORMs for different objects
If ORM and ORM are different object reference models that represent two different objects, a source object S
S T
and a target object T, the similarity transformation � is the composition of the reference transformation for
T←S
ORMS, � , the similarity transformation between the reference object reference models of the two objects,
R ←S
S
� , and the inverse reference transformation for ORMT, � , as shown in Figure 10.2.
R ←R T←R
T
T S
� � � ∘ � ∘ �
(10.4)
T←S T←R R ←R R ←S
T T S S
Figure 10.2 — Composed transformations for two different objects
282 © ISO/IEC 2025 – All rights reserved

The similarity transformations � and � are the same as the corresponding transformations � and
R ←S T←R R←S
T
S
� in 10.3.2. If ORM is the reference ORM for the source object, � reduces to the identity �. Similarly,
S
T←R R ←S
S
if ORMT is the reference ORM for the target object, � reduces to the identity �.
T←R
T
Given that the two objects are fixed with respect to each other, the similarity transformation between their
reference object reference models, � , depends on the relationship between the objects and their object-
R ←R
T S
spaces. If one of the objects represents an assembly that includes the other object as a component, the object-
space of the component object can be considered to be nested within the object-space of the assembly object,
as discussed in 8.4.2. In that case, the common object-space shown in Figure 10.2 represents the assembly
object-space, and the similarity transformation � can be derived from the known displacement and
R ←R
T S
orientation relationships between the object reference models of the component and assembly objects.
If the two objects are independent of each other, it still may be possible to derive the similarity transformation
� if the displacement and orientation relationships between the two objects can be determined. As
R ←R
T S
discussed in 8.4.2. it may be possible to consider one object as operating within the object-space of the other
object. In that case, the ORM of the second object provides a reference for the ORM of the first object.
Alternatively, it may be possible to consider both objects as operating within the object-space of a third object.
In that case, the ORM of the third object provides a reference for both objects. In these last two cases, the
common object-space shown in Figure 10.2 represents the object-space of the reference object,
If any ORM involved in the transformation � is time-dependent, ORM(t) shall denote that ORM at time t. Any
T←S
similarity transformations involving that ORM are also time-dependent, and shall be denoted � ���. If the
T←S
relationship between the object reference models can be determined at a fixed value of time t0, the similarity
transformations generalize in the manner described in 10.3.2.
EXAMPLE ORMS is the reference ORM for the space shuttle (as source object S). ORMT is the reference ORM
WGS_1984 for the Earth (as spatial object T). When in orbit, the object-space of the space shuttle can be considered to be
nested within the object-space of the Earth. At time �, the position and orientation of ORMS with respect to ORMT are known.
� ��� can be determined and used to transform positions with respect to ORM to positions with respect to ORM .
S T
T←S
10.4 Position operations
10.4.1 Overview
Given a coordinate � representing a position in a source SRF, SRFS, the operation that computes the
S
corresponding coordinate � of that position in a given target SRF, SRFT, is termed a change of SRF operation.
T
This is a generalization of the change of basis operation defined in 6.2.
The general case of the change of SRF operation is addressed in 10.4.2. The general case depends on the
existence of a similarity transformation � (see 10.3) from the embedded frame determined by ORM , the
S
T←S
ORM component of SRFS, to the embedded frame determined by ORMT, the ORM component of SRFT. The
general case also depends on CS , the spatial coordinate system component of SRF , and CS , the spatial
S S T
coordinate system component of SRFT.
Special cases allow for simplifications that result in computational shortcuts to the general case. The case of
matched normal embeddings is addressed in 10.4.3. Further specializations arise from combinations of specific
coordinate systems. Subclause 10.4.4 treats combinations of celestiodetic with a map projection.
Cases where CS and CS are based on the same abstract coordinate system, but ORM and ORM differ ,
S T S T
do not generally produce computational simplifications. However, if SRFS and SRFT are based on the
LOCOCENTRIC_EUCLIDEAN_3D CS, a simplification is possible. This simplification, presented in 10.4.5, is

ISO 19111 defines this case as a coordinate operation.
ISO 19111 defines this case as a coordinate transformation.
© ISO/IEC 2025 – All rights reserved 283

important for operations on directions and vector quantities (see 10.5). This simplification also applies to other
SRFs that are based on 3D CSs with the Cartesian property (see 5.3.5.3).
Another important special case occurs when the source object space is an abstract 3D object space. This special
case is treated in 10.4.6.
10.4.2 General case
In the general case of the change of SRF operation, the source SRF, SRF , and the target SRF, SRF , are each
S T
based on a spatial coordinate system, CSS and CST. SRFS and SRFT are also each based on an object reference
model, ORM and ORM . SRF and SRF can be associated with different objects or with the same object. If
S T S T
SRFS and SRFT are associated with the same object, they can be based on different object reference models
for that object, or on the same ORM. Relationships between SRFs are discussed in 8.4.2.
Given two object-fixed SRFs, SRFS and SRFT, and a point in an object-space � that is within the applicable
regions of both SRFs, the most general form of the change of SRF operation is:
-1
� � (10.5)
...

6 Orientation – change of basis and rotation
6.1 Overview
Orientation, change of basis operations, and rotation operations are closely related concepts that are important
in many different application domains. Unfortunately, the terminology and notation used to describe these
concepts is diverse, and often inconsistent, causing confusion and errors.
A change of basis operation inputs a position-vector expressed in one orthonormal frame and outputs a position-
vector for the same position expressed in a different orthonormal frame. Change of basis operations are the
foundation of coordinate conversion and transformation computations (see Clause 10). Change of basis
operations are normatively defined in 6.2.
The orientation of a rigid spatial object describes its angular displacement, or attitude, with respect to a
reference, and is part of its state, along with its position and other spatial characteristics. The orientation of one
orthonormal frame with respect to a second orthonormal frame is the directed angular relationship between
them, with the second orthonormal frame serving as the reference. The specification of an orientation is
important in many application domains including graphical rendering, interpretation of imagery, analysis of
directional sensor data, robotics, vehicle aspect tracking, and the computations of direction and trajectory.
Orientation is normatively defined and related to both change of basis and rotation operations in 6.3.
A rotation operation inputs a position-vector expressed in an orthonormal frame and outputs a position-vector
for a different position that is rotated about a specified axis by a specified angle, expressed in the same
orthonormal frame. Rotation operations are critical to the representation of motion, force, and dynamics in many
application domains, including mechanics, aviation, and astronomy. Rotation can be interpreted in terms of the
physical movement of objects, abstract geometry, or mathematical operations including change of basis
operations. Rotation operations are normatively defined in 6.4.
Change of basis and rotation operators are summarized in 6.5. Rotations and orientations are commonly
expressed in various forms, including axis-angle, matrices, Euler angles, and quaternions. These forms are
normatively defined in 6.6. Conversions between these forms are normatively defined in 6.7.
6.2 Change of basis
6.2.1 Overview
Within a Euclidean vector space, change of basis operations allow a vector expressed in terms of a given basis
to be re-expressed in terms of a different basis. Change of basis operations are used in many types of matrix
computations. In this document, change of basis operations are used to express position-vectors, directions,
and vector quantities in terms of different orthonormal frames.
6.2.2 Change of basis operations
A change of basis operation acts on a position-vector expressed in one orthonormal frame and produces the
equivalent position-vector expressed in terms of a different orthonormal frame. In general, a change of basis
operation can include an angular component and, when the frame origins differ, a positional displacement
component. In some contexts, a change of basis operation can also include a scaling component (see 7.3.2).
� and � are two right-handed 3D orthonormal frames with respective basis vectors specified as �, �, � and
�, �, �. There is interest in computing the coordinate of a position-vector provided in one frame in terms of the
other frame. When the origins of the two frames are different, denote the respective frame origins by � and
�
�����������⃗
� . The vector from the origin of frame � to the origin of frame � is � � , which is the origin of frame F expressed
� � �
�����������⃗
in terms of frame �. The inverse vector from the origin of frame � to the origin of frame � is � � , which is the
� �
origin of frame � expressed in terms of frame �.
© ISO/IEC 2025 – All rights reserved
Figure 6.1 — Change of basis relationships
��������⃗
As Figure 6.1 illustrates, the position-vector � can be expressed with respect to the origin of frame � as � �,
�
As Figure 6.1 further illustrates, � can also be expressed with respect to the origin of frame � as the vector sum
��������⃗ �����������⃗ ��������⃗
� � � � � � � �. Thus, � can be expressed with respect to the origin of frame � as:
� � � �
��������⃗ ��������⃗ �����������⃗
� �. � � � � � �
� � � �
�����������⃗
or, reversing the direction of � � :
� �
��������⃗ �����������⃗ ��������⃗
� �. � � � � � �
� � � �
��������⃗
The position-vector � represented in terms of frame � and denoted by � , is the same vector as � �. Similarly,
� �
��������⃗
the position-vector � represented in terms of frame � and denoted by � , is the same vector as � �. The
� �
transformation operation that re-expresses � in terms of frame � is:
�
�����������⃗
� � � � � � � ,
� � � �←� �
�����������⃗
where � � denotes the positional displacement component and � denotes the angular displacement
� � �←�
component. The direction of the positional displacement vector is from the origin of the target frame to the origin
of the source frame. The inverse transformation operation that re-expresses � in terms of frame � is:
�
�����������⃗
� � � � � � � .
� � � �←� �
If frames � and � have a common origin, there is no positional displacement component, and thus � can be
�
re-expressed in terms of frame � using only the angular displacement component:
� � � � .
� �←� �
© ISO/IEC 2025 – All rights reserved
The inverse transformation is:
� � � � .
� �←� �
Throughout the remainder of this clause, unless otherwise specified, a common origin for both frames is
assumed. Thus, the phrase change of basis is used to refer to only the angular displacement component of the
operation, denoted by � with appropriate subscripts.
For a position-vector �, the frame � coordinate for � with respect to the common origin is �� , � , � � , where
� � �
�
each scalar value is the dot product of the position-vector with one of the basis vectors of the orthonormal frame:
� � � • �, � � � • �, � � � • �.
� � �
� �
Similarly, the frame � coordinate for � is � , � , � , where
� � � �
� � � • �, � � � • �, � � � • �.
� � �
The linear combination with respect to frame � can be written as:
� � � � � � � � � �.
� � �
Using this expression for �, the � frame coordinate components of � become:
� � � • � � �� � � � � � � �� • � � � � • � � � � • � � � � • �
� � � � � � �
� � � • � � �� � � � � � � �� • � � � � • � � � � • � � � � • �
� � � � � � �
� � � • � � �� � � � � � � �� • � � � � • � � � � • � � � � • �
� � � � � � �
The matrix form of this system of linear equations is:
� � • � � • � � • � �
� �
� � • � � • � � • � �
� � � � � � � �� , or
� � • � � • � � • � �
� �
� �
� �
� �
� �
� � � � � � , or
� �
�←�
� �
� �
� �
� � � �
� �←� �
This matrix multiplication operation � is equivalent to the change of basis operation � :
�←� �←�
� � � � .
� �←� �
Since both frames are orthonormal and have a common origin, the relationship also represents the projection
of the basis vectors of one frame onto the basis vectors of the other frame. The columns of � are the �, �, �
�←�
basis vectors in terms of �, �, � coordinate-components while the rows (or columns of the transpose matrix
� ) are the �, �, � basis vectors in terms of �, �, � coordinate-components.
�←�
� • � � • � � • �
��
� • � � • � � • �
� = � = � � = �
�←� �←�
�←�
� • � � • � � • �
(6.1)
� • � � • � � • �
��
� = � = �� • � � • � � • �� = �
�←� �←�
�←�
� • � � • � � • �
These operators define the change of basis relationship between the two frames � and �, allowing position-
vector representations to be converted from one to the other, in either direction.
© ISO/IEC 2025 – All rights reserved
6.2.3 Direction cosine matrix
Expressing the basis vectors of one frame in terms of the other frame provides the relationship between the two
frames. One way to express the relationship is based on the cosine of the angle between each basis vector of
a frame and all basis vectors of the other frame. Since basis vectors are unit vectors, each dot product in
Equation 6.1 is the cosine of the angle (�) between the two indicated vectors (see A.2). A total of nine cosine
values are required to describe the full relationship between two 3D frames. Arranged as a matrix, for frames �
and � the nine cosine values are represented as:
���(� ) ���(� ) ���(� )
�� �� ��
��
���(� ) ���(� ) ���(� )
� = � = � �� �� �� �
�←� �←�
���(� ) ���(� ) ���(� )
�� �� ��
���(� ) ���(� ) ���(� )
�� �� ��
��
���(� ) ���(� ) ���(� )
� = � = � �
�� �� ��
�←�
�←�
���(� ) ���(� ) ���(� )
�� �� ��
The first matrix expresses the basis vectors of frame � in terms of frame �. The second matrix is the inverse
and expresses the unit vectors of � in terms of �. Each of these two matrices are often referred to as a direction
cosine matrix. It is noted that the sum of the square of the values in each column is one.
6.2.4 Consecutive change of basis
Given three right-handed orthonormal frames �, �, and � with a common origin and the change of basis
operators � and � and their inverses � and � , the change of basis operators � and � are
�←� �←� �←� �←� �←� �←�
the compositions:
� = � ∘ �
�←� �←� �←�
� = � ∘ �
�←� �←� �←�
This result generalizes to a chain of orthonormal frames with different origins. For a chain of length N, denote
th
����������⃗
the n frame by � , its origin by � and the displacement vector from the � origin to the � origin by � � for
� � � � � �
1 ≤ �, � ≤ �. For any 1 ≤ � < � < �, the change of basis operator, along with positional components, from frame
����������⃗
� to frame � is denoted by � � � � .
� � � � �←�
For a chain of frames from � to � , the composition of the consecutive chain of operations is:
� �
����������⃗ ������������⃗ ����������⃗ ����������⃗
� � + � = �� � + ⋯ + � � � + �� ∘ … ∘ � � = � � + �� ∘ … ∘ � �.,
� � �←� � � � � �←� �←� � � �←� �←�
������������⃗ ����������⃗ ����������⃗
since the vector sum of the chain of vectors �� � + ⋯ + � � � is equivalent to the single vector � � .
� � � � � �
6.2.5 Equivalence of change of basis and rotation operators
The common origin of the right-handed orthonormal frames � and F is a fixed point of the operator � . Euler’s
�←�
rotation theorem states that any length-preserving transformation of 3D space that has at least one point fixed
under the transformation is equivalent to a single rotation about an axis that passes through the fixed point. This
implies that � is equivalent to a rotation operator � 〈�〉 (see 6.4.2.1), where � is the axis of rotation passing
�←� �
�
〈 〉
through the origin and � is the rotation angle. This operator rotates a position-vector � to � = � � (�). The
�
〈 〉
equivalence of � and � � is shown in A.12.
�←� �
Applying � 〈�〉 to the basis vectors x, y, z of frame � yields the basis vectors u, v, w of frame �:
�
� = � 〈�〉(�)
�
〈 〉
� = � � (�)
�
© ISO/IEC 2025 – All rights reserved
� = � 〈�〉(�)
�
The rotation operation � 〈�〉 can also be designated as � . Hence, the orientation of object-frame � with
� �→�
respect to reference-frame � is realised by both the change of basis operator � and the rotation operator
�←�
� . Thus, the change of basis operator � and the rotation operation � are equivalent to each other:
�→� �←� �→�
� = �
�←� �→�
The difference between operators � and � is in the interpretation of the output of the operation as either
�←� �→�
the change of basis for any position-vector in terms of the bases of � and � or as the rotation of that position
vector about axis n though angle �. Applying this rotation to each of the basis vectors of frame � yields the basis
vectors of frame �, in effect rotating frame � away from alignment with frame �.
The direction cosine matrix that corresponds to the change of basis operator � and the rotation matrix that
�←�
corresponds to the rotation operator � are therefore also equivalent:
�→�
���(� ) ���(� ) ���(� )
� • � � • � � • �
�� �� ��
���(� ) ���(� ) ���(� )
� • � � • � � • �
� � = � �
�� �� ��
� • � � • � � • �
���(� ) ���(� ) ���(� )
�� �� ��
6.2.6 Change of basis and orientation
The change of basis operators � and � express the bidirectional angular relationship between the two
�←� �←�
orthonormal frames � and �. This bidirectional relationship is expressed in terms of the angles between each
pair of basis vectors in the direction cosine matrices. Thus, the orientation of orthonormal frame � with respect
to orthonormal frame � is represented by the direction cosine matrix that corresponds to the change of basis
operator � . Similarly, the orientation of orthonormal frame � with respect to orthonormal frame � is
�←�
represented by the direction cosine matrix that corresponds to the change of basis operator � .
�←�
6.3 Orientation
6.3.1 Overview
The orientation of a rigid object describes its angular displacement, or attitude, with respect to a reference.
When the object is represented by an orthonormal frame attached to the object, the orientation of the object is
represented by the angular displacement of the object’s frame with respect to an orthonormal reference frame.
This angular displacement can be specified in terms of either: 1) a change of basis that converts a coordinate
from the object's frame to the reference frame, or 2) a rotation of the object’s frame away from alignment with
the reference frame.
Specification of and computations with orientations are defined with respect to orthonormal frames (see 5.2.2).
An orthonormal frame serving in the role of an orientation reference is termed a reference-frame. An orthonormal
frame that is, conceptually or physically, rigidly attached to an object of interest is termed an object-frame.
Object-frame attachment choices have significant effects on computational results and will affect interoperability
if not clearly specified. An object-frame can be attached to an object in many ways. The choice of object-frame
origin attachment point and alignment of axis directions is highly dependent on the application domain and is
not addressed in this document.
There are infinitely many ways to attach the origin of an orthonormal frame to an object. The origin can be
located at any point within the spatial object of interest, at any point on its surface, or at any point nearby in
space. Common selections include the centre of mass of the object, its geometric centre, a corner of the object
(assuming it has corners), or it
...

12 Profiles
12.1 Overview
A profile identifies a subset of this document that has been specified to meet the needs of a specific application
area. Only those subsets that can define, represent and/or process positions in at least one SRF shall be
allowed. The core of a profile is a specified set of SRFTs, along with an applicable set of ORMs, and sets of
SRFs and/or SRF sets that can be specified using these SRFTs and ORMs. A profile definition also may include
computational accuracy requirements for conformance (see Clause 14) of any functional implementations of
operations that apply to the SRFs included in the profile. The default profile requires support for all SRFTs and
ORMs specified in this document. Additional profiles may be specified by registration in accordance with Clause
13.
An SRM profile specification includes:
a) a description of the profile (see 13.2.4),
b) a specification of a non-empty subset of standardized and registered ORMs, such that each ORM in
the set shall be applicable to at least one SRFT specified in c,
c) a specification of a non-empty subset of the set of standardized and registered SRFTs such that for
each SRFT in the set, there is at least one ORM specified in b that is applicable to that SRFT,
d) specifications of subsets of standardized and registered SRFs and SRF sets based on SRFTs specified
in c, and applicable ORMs in b; these subsets shall not both be empty,
e) a (possibly empty) subset of the set of standardized and registered DSSs, and
f) optional specifications of computational accuracy requirements, consisting of an accuracy domain and
positional, directional, and ratio error bounds, for SRFTs specified in c.
Accuracy domains and computational accuracy requirements are defined in 14.2.1. The “default” profile is
specified in 12.3. Guidelines for registering profiles are in 13.3.13. The proposal format for profile registration is
provided in H.14. Conformance requirements are specified in 14.2.
12.2 Profile specification
The elements of a profile specification are defined in Table 12.1.
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).
The edition number of the SRM standard from which the entries in the profile
Standard edition used
are obtained.
A list of all associated amendment numbers from which the entries in the profile
Amendment(s) used
are obtained, or "0" if no amendments are used.
© ISO/IEC 2025 – All rights reserved 417

Element Definition
Registered concept(s) "Yes" or "No", indicating whether any registered entries from the International
included Register of Items are included in the profile.
A non-empty subset of standardized and registered ORMs, such that each ORM
ORM(s)
in the subset shall be applicable to at least one SRFT in the profile.
A non-empty subset of standardized and registered SRFTs, such that for each
SRFT(s) SRFT in the subset, there is at least one ORM in the profile that is applicable to
that SRFT.
A subset of the standardized and registered SRFs that are derived from an
SRF(s) SRFT in the profile SRFT(s) element and specifying an ORM in the profile
ORM(s) element.
A subset of the standardized and registered SRF sets that are derived from an
SRF set(s) SRFT in the profile SRFT(s) element, and such that at least one ORM specified
in the profile ORM(s) element satisfies the ORM constraint of the SRF set.
A subset of the standardized and registered DSSs.
DSS(s)
This optional element may be repeated for single SRFTs or groups of SRFTs in
the profile. An SRFT in the profile shall appear in at most one of these
elements.
SRFT The label(s) of one or more SRFTs in the profile.
label(s)
Computational
� : the positional error bound in metres,
�
accuracy
� : the directional error bound in radians, and
�
requirements
Error � : the ratio error bound.
�
bounds Optionally, separate error bounds for one or more subsets of the
ORMs associated with the listed SRFTs in the SRFT label(s)
element.
Accuracy A set of constraints that specify: a subset of the CS domain;
domain and/or SRFT parameter value ranges (see 14.2.1).
The non-empty subsets of ORMs, SRFTs, SRFs, SRF sets and DSSs may be explicit or may be expressed in
a clear and unambiguous short-hand form that, when expanded, ensures the intended subset is produced.
EXAMPLE 1 "All standardized ORMs".
EXAMPLE 2 "All standardized SRFs".
EXAMPLE 3 "All object-fixed ERMs".
EXAMPLE 4 "All standardized ORMs in the profile SRM_3_0_MARS_PROJECT_PROFILE", where
SRM_3_0_MARS_PROJECT_PROFILE is the label of an existing profile.
As specified in 4.1, the unit of length is the metre, and the unit of angular measure is the radian.
An implementation conforms to the computational accuracy requirement of a profile if for every SRF that is
included in the profile or is a member of an SRF set that is included in the profile, positional, directional and ratio
errors for operations on SRF coordinates in the accuracy domain shall not exceed the positional, directional and
ratio error bounds (if any) specified in the computational accuracy requirements element applicabl
...

7 Reference datums, embeddings, and object reference models
7.1 Overview
This document 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 including Earth are specified in Annex D.
A normal embedding is a distance-preserving function from position-space to object-space. A normal embedding
establishes a model of position-space in object-space by defining an orthonormal frame, termed the embedded
frame, in object-space (see 5.2.4). 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 with properly constrained relationships can be selected so as to be compatible
with one and only one normal embedding. Such a constrained set of bound reference datums is termed an
object reference model. Thus, an object reference model specifies a unique normal embedding. Object
reference models generalize the notion of geodesy datums. 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. A reference
transformation is a type of similarity transformation (see 7.3.2). Similarity transformation templates are defined
in 7.3.3 to facilitate the specification of reference transformations. Similarity transformations in general and
reference transformations in particular may have time-dependent parameters. Thus, these transformations may
be termed time-independent (static) or time-dependent (dynamic). Time-independent reference transformations
for celestial object reference models are also specified in Annex E.
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 Overview
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 document, the reference datum concept is defined for 1D,
2D, and 3D position-spaces. In the 2D and 3D cases, this document specifies a small set of reference datums
for use in its own specifications. This set is not intended to be exhaustive. Additional RDs may be specified by
registration in accordance with Clause 13.
7.2.2 Reference datum categories
In this document, 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 termed 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 2025 – All rights reserved 155

Table 7.1 — RD categories
Position-space representation
Object-space
RD category
representation
1D 2D 3D
Point ��� ��, �� ��, �, �� a point in the object-space
real � real �, � real �, �, �
Directed � � � � a curve in the object-space
� = � � , � = � � ,
� �
curve � is smooth, ℝ valued � is smooth, ℝ valued with a designation of direction
� �
with domain � ⊆ ℝ . with domain � ⊆ ℝ . along the curve

� �
Direction at � = � � is
� � � �
Direction at � = � � is
� �
��
��
� = �� �.
�
� = �� �.
�
��
��
Oriented Implicit definition: a surface in the object-space
surface with a designation of one side
���� = 0.
as positive
�
� is smooth, ℝ valued for
� in position-space.
Positive side of surface
(orientation):
���� > 0.
This document 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).
RD code The code for the RD (see 13.2.3). Code 0 (UNSPECIFIED) is 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
156 © ISO/IEC 2025 – All rights reserved

Table 7.4 — 2D RDs of category point
RD label RD code Description Position-space representation
1 Origin in 2D
ORIGIN_2D �0,0�
2 x-axis unit point in 2D
X_UNIT_POINT_2D � �
1,0
3 y-axis unit point in 2D
Y_UNIT_POINT_2D �0,1�
Table 7.5 — 3D RDs of category point
RD label RD code Description Position-space representation
4 Origin in 3D
ORIGIN_3D
�0,0,0�
5 x-axis unit point in 3D
X_UNIT_POINT_3D � �
1,0,0
6 y-axis unit point in 3D
Y_UNIT_POINT_3D
�0,1,0�
7 z-axis unit point in 3D
Z_UNIT_POINT_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
�-axis in 2D ���� ≡ ��, 0�
Y_AXIS_2D 9
� � � �
�-axis in 2D � � ≡ 0, �
Table 7.7 — 3D RDs of category directed curve
RD label RD code Description Position-space representation
X_AXIS_3D 10
�-axis in 3D ���� ≡ ��, 0, 0�
Y_AXIS_3D 11
�-axis in 3D ���� ≡ �0, �, 0�
Z_AXIS_3D 12
� � � �
�-axis in 3D � � ≡ 0, 0, �
Table 7.8 — 3D RDs of category oriented surface
RD label RD code Description Position-space representation
XY_PLANE_3D
��-plane 0 = ���, �, �� ≡ �
XZ_PLANE_3D
��-plane 0 = ���, �, �� ≡ �
YZ_PLANE_3D ��-plane 0 = ���, �, �� ≡ �
7.2.3 Ellipsoidal RDs
The RDs specified in this document include RDs based on oblate ellipsoids, prolate ellipsoids, and tri-axial
ellipsoids. These RDs are 3D and of RD oriented surface category. These RDs are specified based upon certain
geometrically defined parameters (see A.6.2). The position-space representations of oblate and prolate ellipsoid
RDs are expressed in the form:
© ISO/IEC 2025 – All rights reserved 157

� � �
� � �
(7.1)
���, �, �� = � � � 1 = 0 where � � 0 � �.
� � �
� � �
When � � �, 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, where appropriate. If � = �, an oblate
ellipsoid RD may be termed a sphere RD. In this case, the value � = � = � is the radius of the sphere RD.
NOTE  In general usage, spheres are a limiting case of oblate, prolate, and tri-axial ellipsoids.
When � � �, an RD of this form is a prolate ellipsoid RD with major semi-axis � and minor semi-axis �, as
illustrated in Figure 7.1.
Instead of specifying the parameters of an oblate ellipsoid RD as the major semi-axis � and the minor semi-axis
�, it is both equivalent and sometimes convenient to use the major semi-axis � and the flattening � as defined
in Equation 7.2. The minor semi-axis � may be expressed in terms of the major semi-axis � and the flattening �
� �
as in Equation 7.3. The flattening of a sphere RD is zero � = 0 .

���
(7.2)
flattening definition: � ≡
�
minor semi-axis relationship: � = � � �� (7.3)
The position-space representation of a tri-axial ellipsoid RD is expressed in the form:

� � �
� � �
(7.4)
� �
� �, �, � = � � � 1 = 0.
� � �
� � �
The semi-axes �, �, and � shall be positive non-zero and � � � � � � �.

Figure 7.1 — Oblate and prolate ellipsoids
158 © ISO/IEC 2025 – All rights reserved

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 of the physical object as published or as
commonly known.
Oblate ellipsoid case Major semi-axis, �
Flattening, �
Sphere case Radius, �
Prolate ellipsoid case Minor semi-axis, �
Major semi-axis, �
Tri-axial ellipsoid case x-semi-axis, �
y-semi-axis, �
z-semi-axis, �
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
Parameters
one of the following forms:
a) error estimate: unknown
b) error estimate: assumed precise
c) error estimate (1�): :
d) error interval: ±
��
EXAMPLE error estimate (1�): �: 1 250, � : 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 �
��
or for � may be substituted in place of an error estimate for �.
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.
© ISO/IEC 2025 – All rights reserved 159

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
EXAMPLE An ellipsoid reference datum with major semi-axis � and minor semi-axis � is the surface implicitly defined
by:
� � �
� � �
� �
� �, �, � = � � � 1 = 0
� � �
� � �
and is illustrated in Figure 7.2. The WGS_1984 ellipsoid reference datum has major semi-axis � = 6 378 137 metres and
flattening � = 1/298,257 223 563, resulting in a minor semi-axis � = � � �� = 6 356 752 metres.

Figure 7.2 — An ellipsoid reference datum
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 document, 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.
160 © ISO/IEC 2025 – All rights reserved

If the constructed entity of an RD binding is fixed with respect to object-space, then the RD binding shall be
termed an object-fixed RD binding. This definition assumes that the constructed entity does not move over time
by an amount significant for the accuracy and time scale of an application.
Figure 7.3 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.

Figure 7.3 — Two RDs bound to an abstract object and to a physical object
In some application domains, bound reference datums are used to model a significant aspect of the problem
domain. In geodesy, oblate ellipsoids are used to model the figure of the Earth or a subset thereof.
EXAMPLE Semi-axis values � and �, � � �, are selected to specify an oblate ellipsoid reference datum. The following
steps (see Figure 7.4) illustrate one way to bind an ellipsoid reference datum specified by semi-axis values � and � to a
conceptual
...

2 Normative references
The following documents are referred to in the text in such a way that some or all their content constitutes
requirements 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 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, Data elements and interchange formats — Information interchange —

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

environmental data representation — Procedures for registration of items.
ISO/IEC/IEEE 60559, Information technology — Microprocessor Systems — Floating-Point

arithmetic.
ISO 80000-2, Quantities and units — Part 2: Mathematical signs and symbols
...

13 Registration
13.1 Overview
This clause specifies the rules and guidelines that have been used in the specification of the concepts in this
document and 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. Additional guidelines applicable to specific SRM
concepts are specified in 13.3.
ISO/IEC 9973 allows for previously registered items to be added to this document, when amended. When
previously registered SRM concept instances are added to this document, all abbreviated terms used (in labels,
description text, etc.) in those instances that are not already included in Table 3.3 and/or Table F.1 shall be
added, as appropriate. Additionally, all associated references (see 13.2.5) not already included in Clause 2 or
the Bibliography shall be added, as appropriate.
13.2 Specification elements for SRM registered items
13.2.1 Overview
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 assigned by the maintenance agency to denote the registered item, and
c) other concept-dependent information that may include the following elements:
1) a description, and
2) references.
In specifying an SRF set, assigning labels to the set members is optional (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 document may include the name or names for the
registered item.
Each label in this document 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.

Uniqueness is only within the set of instances of each SRM concept, for example: RDs or ORMs.
© ISO/IEC 2025 – All rights reserved 423

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.
Labels shall be presented, in this document or in other documents, such that it is clear which SRM concept is
represented. This is achieved by preceding the label with the concept abbreviated form, which identifies the
concept context.
EXAMPLE 2 The label TRANSVERSE_MERCATOR is used as both an SRFT and a CS label. Each of these shall be
presented as shown below.
SRFT TRANSVERSE_MERCATOR
CS TRANSVERSE_MERCATOR
The labels of standardized SRM concept instances in this document were created by applying the following
guidelines. Labels for proposed SRM 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).
e) Labels shall not contain spaces.
f) Labels may be a single word or abbreviated form (see 3.2 and Annex F), or may be composed of a
series of components, each of which is a word or an abbreviated form.
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 and should be unique within the first
thirty-one (31) 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 document or in previously registered SRM concept instances.
b) When abbreviating, if a word or phrase to be abbreviated appears in Annex F or Table 3.3, the given
abbreviated form 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 or Table 3.3, the
proposed abbreviated form should, if possible, be consistent with those specified in Annex F and Table
3.3.
Recognized abbreviated forms for words or phrases may be used as components of a label based on the
following guidelines:
a) Each abbreviated form shall uniquely represent a single word or phrase.
b) If a word or phrase is abbreviated in one label, it is not required to be abbreviated in other labels.
c) Jargon shall not be used.
424 © ISO/IEC 2025 – All rights reserved

d) An abbreviated form in a label shall not be, by itself, a word with a different meaning than that of the
word/phrase that it replaces.
EXAMPLE 3 The abbreviated form DATUM should not be used for the phrase "Dartmouth Arc Transit Universal
Meridian" as this would violate guideline (d).
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 maintenance agency for this document when a
registration proposal is accepted. Therefore, codes are not included in registration proposals.
Each code in this document shall:
a) uniquely denote a specific instance within the set of instances of a given SRM concept,
b) be represented as an integer, and
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 SRF set shall be considered as a separate and distinct set from the set of members of a
different SRF set.
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 document, but they
may be used in a non-conforming implementation for experimentation. The code value zero is reserved for use
in the API (see 11.2.7.1).
All codes for SRM standardized concept instances that are not assigned in this document are reserved for future
standardization or for registration. Codes shall be assigned by the maintence agency for this document
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 document 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 document.
c) The maintenance agency for this document 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 maintenance agency for this document shall coordinate the assignment of codes with future
revisions of this document 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, and/or essential qualities of the concept instance.
The descriptions of standardized SRM concept instances in this document were created by applying the
following guidelines. Descriptions for proposed SRM 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.
© ISO/IEC 2025 – All rights reserved 425

b) Descriptions shall be clear and concise, containing only the content necessary to summarize the
concept instance.
c) Jargon shall not be used.
d) When abbreviating, if a word or phrase to be abbreviated appears in Table 3.3, the given abbreviated
form for that word or phrase shall be used.
e) When abbreviating, if a word or phrase to be abbreviated does not appear in Table 3.3, the proposed
abbreviated form should, if possible, be consistent with those specified in Table 3.3.
13.2.5 References
13.2.5.1 Overview
Two types of references are recognized in International Standards. The first type of reference is a normative
reference (see ISO/IEC Directives, Part 2). 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 (see ISO/IEC Directives, Part 2).
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 ISO/IEC Directives,
Part 2. 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  [NGA36, App. A-1, "HO"] and [RIIC15, Table 4, "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 the constraints
on how those parameters interrelate.
e) The coordinate-component 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-components and other CS parameters.
426 © ISO/IEC 2025 – All rights reserved

g) The CS generating function or mapping equations shall be specified in terms of the coordinate-
components and other CS parameters. In the case of an oblate ellipsoid, common parameters and
functions from Table 5.6 shall be used if possible.
h) The domain of the inverse of the CS generating function or mapping equations shall be specified in
terms of the coordinate-components and other CS parameters.
i) The inverse of the CS generating function or mapping equations shall be specified in terms of the
coordinate-components and other CS parameters. In the case of an oblate ellipsoid common
parameters and functions from Table 5.6 shall be used.
j) If the CS is a map projection, the convergence of the meridian function shall be specified in terms of the
coordinate-components, other CS parameters, and or functions from Table 5.6.
k) If the CS is a map projection, the point distortion function(s) shall be specified in terms of the coordinate-
components, other CS parameters, and or functions from Table 5.6.
l) Supplementary geometric figures may be provided that explain the roles of the CS parameters and
illustrate the CS.
m) Additional, non-normative information concerning the CS may be supplied in the form of notes.
EXAMPLE 1 Guideline d:
CS parameters:  “�: major semi-axis length, and �: minor semi-axis length” and
CS parameter constraints: “� > �”.
� �
EXAMPLE 2 Guidelines f and h: “− � < � < � , −� ≤ � < �, and −� < ℎ”.
2 2
EXAMPLE 3 Guideline m note: “The generating function is the composition of the generating function for azimuthal
spherical with the 3D localization operator.”
13.3.2 Guideline for registration of temporal CSs
Temporal CSs shall be registered according to the additional guideline that the description of the temporal CS,
including any common name, shall be specified.
13.3.3 Guidelines for registration of RDs
RDs shall be registered according to the following additional guidelines:
a) The name of the physical object, if any, shall be specified.
b) If the RD is not based on an ellipsoid, the analytic formulation of the RD in position-space shall be
specified.
c) If the RD is based on an ellipsoid, the parameter values sh
...

INTERNATIONAL STANDARD
Information technology — Spatial Reference Model (SRM)
1 Scope
This document 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, direction, orientation, 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 document 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 SRM specifies an application program interface (API) that supports the re
...

8 Spatial reference frames
8.1 Overview
A spatial reference frame is a means of specifying a spatial coordinate system for a region of an object-space.
The relationship between a spatial reference frame and the corresponding spatial coordinate system is
discussed in 8.2. Spatial reference frame specifications are discussed in 8.3.
Many applications need to perform operations involving multiple spatial reference frames. Relationships among
spatial reference frames are commonly derived from corresponding relationships among the spatial objects of
interest within the application domain. Spatial reference frame relationships are discussed in 8.4.
A spatial reference frame template provides an abstraction of spatial reference frames that share common
elements. Spatial reference frame templates are used to realise instances of spatial reference frames. This
document defines a collection of spatial reference frame templates in 8.5. This document also defines a
collection of standardized spatial reference frames in 8.6.
Spatial reference frames may be organized into specified sets to form an atlas for a large region. This document
defines a collection of standardized spatial reference frame sets, as well as the members of those sets, in 8.7.
8.2 Spatial reference frame structure
A spatial reference frame uses a spatial coordinate system (see 5.4) to assign a unique coordinate �-tuple to
each point in a region of an object-space. A spatial coordinate system is defined as the functional composition
of an abstract coordinate system generating function and a normal embedding. The abstract coordinate system
generating function � associates coordinates in coordinate-space to positions in position-space. A normal
embedding � maps those positions in position-space to points in object-space. Different normal embeddings
produce different spatial coordinate systems. If � is a coordinate for the coordinate system, then � identifies the
object-space point � � � ∘ ����.
A spatial reference frame uses an object reference model (see 7.4) to determine a unique normal embedding �
to map the position-space orthonormal frame to a corresponding orthonormal frame embedded in the object-
space of the spatial object that it models (see 5.2.5). All spatial reference frames rely on their respective
embedded frame in object-space to provide a reference for measurements and computations. The object
reference model is a set of reference datums that bind geometric primitives (points, directed curves, or oriented
surfaces) in position-space to corresponding geometrics aspects of the spatial object in object-space.

Figure 8.1 — The components of a spatial reference frame
Figure 8.1 illustrates a spatial reference frame in which a spherical spatial coordinate system is derived from a
spherical abstract coordinate system and a normal embedding determined by an object reference model of the
� � � �
Earth. In this illustration, a coordinate �, �, � in coordinate-space is assigned to a position-vector �, �, � in the
orthonormal frame of position-space. That position is mapped to a location in the object-space of the Earth via
© ISO/IEC 2025 – All rights reserved 209

the unique normal embedding that is determined by the object reference model and its associated reference
datums. This embedding provides an embedded frame in object-space that serves as the uniform reference for
measurements.
8.3 Spatial reference frame specification
8.3.1 SRF definition
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 (including time-dependent
positions) with respect to the spatial object of the ORM. A specification of an SRF includes:
a) an ORM,
b) an abstract CS compatible with the ORM,
c) a binding of all parameters of the CS,
th
d) (optionally) � coordinate-component names,
e) (optionally) a description or specification of the region of object-space to which the SRF applies,
expressed in terms of geographic name(s) and/or restrictions on the coordinate domain, and
f) (optionally) a coordinate-component of a CS of type 3D may be identified as the vertical coordinate-
component (see 5.2.1).
An SRF specifies a spatial CS defined by the functional composition of the abstract CS generating function and
the normal embedding associated with the ORM. All SRFs rely on the embedded frame, which provides a
uniform reference for measuring distances and angles in object-space.
Spatial CS compatibility and the other elements of the specification of an SRF are defined in the following
subclauses.
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
Surface CS
3D
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.
210 © ISO/IEC 2025 – All rights reserved

The standardized surface CSs that are based on an oblate ellipsoid (or sphere) are:
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. 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. For all SRFs, the normal
embedding determined by the ORM provides an embedded frame with an inherent Cartesian basis that
establishes a uniform reference from which distances and angles for the coordinate-components of the SRF are
measured and specified in object-space. Every 3D SRF in this document is a right-handed SRF in consequence
to the CS handedness restriction imposed in 5.2.3.
8.3.2.2 CS parameter binding
All CS parameter values shall 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.3.8) includes the coordinate-component symbols with common names (if any). A
th
specification of an SRF may optionally assign SRF-specific names to the � 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 � coordinate-components
of “right ascension” for �, “declination” for �, and “radius” for �.
8.3.2.4 Applicable region
A CS specification (see 5.3.8) 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. An applicable region is a restriction of the CS domain as used in an SRF. An extended region is a
second region that contains the applicable 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 object-
space.
© ISO/IEC 2025 – All rights reserved 211

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.3.7.3.3).
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 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 applicable region will necessarily be true in the extended region. A
distortion error bound that holds in the applicable region may not hold in the extended region.
Applicable regions and extended regions may be described and/or specified. An applicable region description
is a statement that describes the spatial extent of the region such as in terms of named geographic areas or
political entities.
EXAMPLE 1 “The German state of Baden-Wurttemberg” and “The Baltic Sea” are applicable region descriptions.
An applicable region specification consists of a set of constraints that specifies the spatial extent of the region.
The spatial extent of the region may always be specified in terms of coordinate-component value ranges in the
coordinate system of the SRF. Such a specification is termed to be of type coordinate-region.
If the ORM of the SRF is based on an oblate ellipsoid (or sphere), the spatial extent of the region may
alternatively be specified in terms of coordinate-component value ranges in the geodetic coordinate system of
the Celestiodetic SRF for that ORM (see 8.5.4). When the coordinate-component value ranges are specified in
terms of geodetic coordinates in this way, the specification is termed to be of type geodetic-region. To avoid
loss of precision, such geodetic coordinate values may be specified in arc degrees. Applicable region
specifications of type geodetic-region may be useful for local Euclidean or map projection-based SRFs.
Each coordinate-component value range may be fully bounded, with both upper and lower bounds specified,
semi-bounded, with only one (either upper or lower) bound specified, or unbounded, with no bounds specified.
Together, the coordinate-component value ranges specify a full or partial bounding box, in terms of either the
coordinate system of the SRF (type coordinate-region), or in terms of geodetic coordinates of the Celestiodetic
SRF for that ORM (type geodetic-region).
If an applicable region has been specified, an extended region specification of the same type (type coordinate-
region or type geodetic-region) may also be specified. The ranges specified for an extended region shall contain
the corresponding applicable region ranges.
A coordinate is within the applicable region if it is contained in the CS domain of the SRF and satisfies all
constraints in the applicable region specification. In the case of an applicable region specification of type
geodetic-region, the coordinate is considered to be within the applicable region if the corresponding
Celestiodetic SRF coordinate satisfies all geodetic constraints in the applicable region specification.
A coordinate is within the extended region if it is contained in the CS domain of the SRF and satisfies the
constraints in the extended region specification. In the case of an extended region specification of type geodetic-
region, the coordinate is considered to be within the extended region if the corresponding Celestiodetic SRF
coordinate satisfies all geodetic constraints in the extended region specification.
EXAMPLE 2 The SRF is based on a transverse Mercator map projection (see SRF Template Transverse Mercator).
Applicable region specification of type coordinate-region: 167 000 ≤ � ≤ 833 000, 0 ≤ � ≤ 9 500 000
Extended region specification of type coordinate-region: 0 < �, −100 < �
Note that the extended region is partially bounded.
212 © ISO/IEC 2025 – All rights reserved

EXAMPLE 3 The SRF is based on a transverse Mercator map projection (see SRF Template Transverse Mercator).
Applicable region specification of type geodetic-region: −78° ≤ � < −72°, 0° ≤ � < 84°
Extended region specification of type geodetic-region: −78,5° ≤ � < −71,5°
Note that the extended region is partially bounded since no constraint on � is specified.
8.4 SRF relationships
8.4.1 Overview
Many applications need to perform operations involving multiple SRFs. These SRFs can be related to one
another in several different ways. In general, the relationships involve at least one SRF acting as the reference
SRF for one or more other SRFs. Usually, SRF relationships are based on the mathematical relationships
between specific SRFs or reflect corresponding relationships among the spatial objects of interest within the
application domain. The SRFs can be in the same object-space or in different object-spaces. Such SRF
relationships are discussed in 8.4.2.
In some applications dealing with curvilinear 3D SRFs, it is useful to reduce the dimensionality of the coordinate
system of an SRF by fixing the values of one or more of its coordinate-components to induce a new SRF.
Instances of such relationships include surface SRFs that are induced from corresponding 3D SRFs when one
coordinate-component is fixed. This type of SRF relationship is discussed in 8.4.3.
In some applications, it is necessary to emplace an SRF at a convenient location within the object-space to
measure or specify positions of interest to the application. Such SRFs can be instanced at the desired location,
the lococentre, with the position of the lococentre and the orientation of the SRF specified using localization
methods. These methods provide a local orthonormal frame. When the lococentre is on a coordinate surface,
and the horizontal axes are tangent to that surface at that point, the orthonormal frame is termed a local tangent
frame. Such lococentric SRFs are discussed in 8.4.4.
Operations on directions and vector quantities require a Cartesian coordinate system. When an SRF does not
provide such a coordinate system, this requirement can be met by a lococentric SRF t
...

3 Terms, definitions, symbols, and abbreviated terms
3.1 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
• ISO Online browsing platform: available at https://www.iso.org/obp
• IEC Electropedia: available at https://www.electropedia.org
3.1.1
Earth gravitational model
spherical harmonic expansion of the gravitational field potential
Note 1 to entry: Gravity includes rotational effects; however, such rotational effects are not included in this model.
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 perpendicular to the rotational axis of the object
3.1.4
geodetic datum
datum (or reference frame) describing the relationship of a 2- or 3-dimensional coordinate system to the Earth
Note 1 to entry: ISO 19111:2019 uses the term geodetic reference frame.
Note 2 to entry: In most cases, the geodetic datum includes an ellipsoid definition.
[SOURCE: ISO 19111:2019, 3.1.34]
3.1.5
north pole
that pole of rotation that lies on the north side of the invariable plane of the solar system
Note 1 to entry: Some planets have retrograde rotation with respect to this definition.
Note 2 to entry: Map north (see 5.3.7.1) may be unrelated to this direction.
Note 3 to entry: The north side of the invariable plane of the solar system is the side facing in the direction of Polaris.
[SOURCE: RIIC15]
3.1.6
replete set
connected subset of a Euclidean space with non-empty interior such that all its points belong to either its interior
or to the topological closure of its interior
Note 1 to entry: 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.
© ISO/IEC 2025 – All rights reserved 5

3.1.7
spatial object
physical or virtual object to which spatial information applies
3.1.8
spatial operation
mathematical function that re-expresses coordinates, directions, and/or orientations expressed in one spatial
reference frame in terms of a different spatial reference frame; or mathematical function for distance or other
geometric quantities within a single spatial reference frame
3.2 Notation, symbols, and abbreviated terms
In this document, dates that are included in an element of a concept instance specification shall conform to the
notation and formats of ISO 8601.
Table 3.1 lists mathematical notation conventions commonly used in this document.
Table 3.1 — Mathematical notation
Style Use Examples
lower case, bold, italic points, vectors x, p
lower case, italic variables, scalars, scalar-valued a, b, f, x-axis
functions, axes of a linear coordinate
system
upper case, bold, italic vector-valued functions, matrices, F, G, M
orthogonal frames
upper case, italic sets S, T
Upper case italic letter symbols are also used for scalar-valued functions that are customarily capitalized.
Table 3.2 lists the symbols used in this document.
Table 3.2 — Symbols
Symbol Definition
CSS spatial coordinate system of SRFS
ORMS object reference model of SRFS
ORMR reference ORM for a given spatial object
SRFS source spatial reference frame
SRFT target spatial reference frame
� origin of an orthonormal frame
� major semi-axis length of an oblate ellipsoid
� minor semi-axis length of an oblate ellipsoid
th
� ���( ) i coordinate-component curve at a point
�
� coordinate of a position in SRFS

S
� ( ) Euclidean distance function
�
� ( ) geodesic distance function
�
6 © ISO/IEC 2025 – All rights reserved

Symbol Definition
E computational error
� embedded orthonormal frame; normal embedding
� extended region of SRF
S
S
� embedded frame of SRF
S
S
�( ) embedding function
(� , � , � ) set of Cartesian basis vectors of an orthonormal frame
� � �
(� , � , � , � ) quaternion in 4-tuple form
� � � �
(� , �) quaternion in scalar vector form
�
� flattening of an oblate ellipsoid
� generating function of a coordinate system
� generating function of a localized coordinate system
�
� spatial generating function of CS
S
S
Dom(� ) domain of the generating function �
S S
( )
Rng � range of the generating function �
S S
� similarity transformation from frame E to frame F

�←�
ℎ ellipsoidal height
ℎ ellipsoidal height at the CS origin
�
ℎ elevation with respect to the geoid
�
ℎ orthometric height
�
� identity matrix (or operator)
� identity transformation from frame E to frame F
�←�
� central scale
�
� point scale
������
�, �, � number of dimensions, 1
�, �, �
3
k( ) point distortion function
� localized orthonormal frame
� localization operator (3D)
3D
� rotation matrix from frame E to frame F
�←�
ℳ(�) radius of curvature in the meridian at latitude φ
( )
� � radius of curvature in the prime vertical at latitude φ
� direction vector in SRFS
S
(� , � , � , �) rotation representation in terms of axis unit vector components and rotation angle
� � �
� origin of the embedded orthonormal frame E
�
�����������⃗
vector from the origin of frame E to the origin of frame F
� �
� �
��������⃗
vector from the origin of frame E to the position �
� �
�
© ISO/IEC 2025 – All rights reserved 7

Symbol Definition
� generating projection
� mapping equations for SRF
S
S
�, �� position vector
� coordinate of position � expressed in terms of frame E
�
�� , � , � �
coordinate-components of position � in terms of frame E
� � �
�
� inverse generating projection
� inverse mapping equations for SRFS
S
�, �, �, � localization parameters
� rotation operator
�
ℝ vector space of m-tuples
� 〈�〉 rotation through angle θ about the axis n
�
� | �
non-origin-fixed rotation through angle � about the directed axis � + �� � ∈ ℝ passing
� 〈�〉
�,�
through the position vector � and parallel to the unit vector �
� orientation of frame F with respect to frame E
�→�
th
� �
� � ( ) i coordinate-component surface at a point
�
�(�) meridional distance from latitude φ to the equator
� false easting
�
�
� �
�, � 2D pos
...

Contents Page
Foreword . xxiii

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

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

4 Concepts . 13
4.1 Overview . 13
4.2 Coordinate-space, position-space, and object-space . 15
4.2.1 Coordinate-space . 15
4.2.2 Position-space and orthonormal frames . 15
4.2.3 Object-space and normal embeddings . 16
4.3 Coordinate systems. 17
4.3.1 Abstract coordinate systems . 17
4.3.2 Spatial coordinate systems . 19
4.3.3 Temporal coordinate systems . 19
4.4 Orientation . 20
4.5 Reference datums . 20
4.6 Object reference models . 23
4.7 Spatial reference frames . 25
4.8 Designated spatial surfaces and vertical offset surfaces . 26
4.9 Spatial operations. 27
4.10 Application program interface . 28
4.11 Profiles . 28
4.12 Registration . 28
4.13 Conformance . 29

5 Coordinate systems. 31
5.1 Overview . 31
5.2 Coordinate-space, position-space, and object-space . 31
5.2.1 Coordinate-space . 31
5.2.2 Orthonormal frames . 32
5.2.3 Position-space . 33
5.2.4 Object-space . 34
5.2.5 Normal embeddings . 35
5.3 Abstract coordinate systems . 37
5.3.1 Overview . 37
5.3.2 Definition . 37
5.3.3 Coordinate system types . 38
5.3.4 Coordinate-component surfaces and curves . 41
5.3.4.1 Overview . 41
5.3.4.2 Coordinate-component surfaces and induced surface CSs . 41
5.3.4.3 Coordinate-component curves . 42
5.3.5 CS properties . 43
5.3.5.1 Linearity . 43
© ISO/IEC 2025 – All rights reserved iii

5.3.5.2 Orthogonality . 43
5.3.5.3 Linear CS properties: Cartesian, and orthogonal . 43
5.3.5.4 CS right-handedness and coordinate-component ordering . 44
5.3.6 CS localization . 44
5.3.6.1 Overview . 44
5.3.6.2 Localization operators . 45
5.3.6.3 Localized frame and local tangent frame at a coordinate . 47
5.3.6.4 Vectors, directions, and localized frames . 50
5.3.7 Map projection coordinate systems . 51
5.3.7.1 Map projections . 51
5.3.7.2 Map projection as a surface CS . 51
5.3.7.3 Map projection geometry . 52
5.3.7.4 Relationship to projection functions . 56
5.3.7.5 Map projection CS common parameters . 59
5.3.7.6 Augmented map projections . 60
5.3.8 CS specifications . 61
5.3.8.1 Specification table elements and common functions and parameters . 61
5.3.8.2 Euclidean 3D CS specification . 64
5.3.8.3 Lococentric Euclidean 3D CS specification . 65
5.3.8.4 Equatorial Spherical CS specification . 67
5.3.8.5 Lococentric Equatorial Spherical CS specification . 68
5.3.8.6 Azimuthal Spherical CS specification . 70
5.3.8.7 Lococentric Azimuthal Spherical CS specification . 72
5.3.8.8 Geodetic 3D CS specification . 73
5.3.8.9 Planetodetic 3D specification . 76
5.3.8.10 Cylindrical CS specification . 77
5.3.8.11 Lococentric Cylindrical CS specification. 79
5.3.8.12 Mercator CS specification. 80
5.3.8.13 Oblique Mercator Spherical CS specification . 82
5.3.8.14 Transverse Mercator CS specification . 85
5.3.8.15 Lambert Conformal Conic CS specification . 89
5.3.8.16 Polar Stereographic CS specification . 91
5.3.8.17 Equidistant Cylindrical CS specification . 93
5.3.8.18 Surface Geodetic CS specification . 95
5.3.8.19 Surface Planetodetic CS specification . 96
5.3.8.20 Lococentric Surface Euclidean CS specification . 98
5.3.8.21 Lococentric Surface Azimuthal CS specification . 100
5.3.8.22 Lococentric Surface Polar CS specification . 101
5.3.8.23 Euclidean 2D CS specification . 103
5.3.8.24 Lococentric Euclidean 2D CS specification . 104
5.3.8.25 Azimuthal CS specification . 106
5.3.8.26 Lococentric Azimuthal CS specification . 107
5.3.8.27 Polar CS specification . 109
5.3.8.28 Lococentric Polar CS specification . 110
5.3.8.29 Euclidean 1D CS specification . 112
5.3.8.30 Azimuthal Cylindrical CS specification . 113
5.3.8.31 Lococentric Azimuthal Cylindrical CS specification . 114
5.4 Spatial coordinate systems . 116
5.4.1 Overview . 116
5.4.2 Definition . 116
5.5 Temporal coordinate systems . 118
5.5.1 Overview . 118
5.5.2 Universal time . 119
5.5.3 International atomic time . 119
5.5.4 Coordinated universal time .
...