ISO/IEC 18026:2025

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 is small (or zero) and the interest in these regions
is primarily academic. For an Earth referenced application there are several regions of practical interest:
a) For aircraft, an appropriate region in terms of ellipsoidal height is −200 metres to 35 000 metres for all
latitudes and longitudes. This covers the region where air-breathing vehicles can operate.
462 © ISO/IEC 2025 – All rights reserved

b) For sub-surface operations an appropriate region is −12 000 metres to +200 metres for all latitudes and
longitudes. This region covers the lowest bathymetric point of the Earth (Marianas Trench) to slightly
above the ocean’s surface.
c) Space operations may require a region extending above 35 kilometres to beyond the orbit of the moon.
All regions may be further divided into sub-regions for particular applications in order to simplify formulations or
for computational efficiency. Usually, the latitude domain in this application is [−
/2,
/2] and the longitude
domain is (−
,
]. On occasion, a particular application may be restricted to a smaller latitude/longitude region
in order to simplify formulations, and in the case of map projections to reduce distortions.
B.4.4 Define a meaningful error measure
In many situations involving spatial operations computation, the resulting variables are not exact due to
approximations made in the computational formulations. An error measure is needed to determine the
approximation error. If the target variables are in terms of distance in a Euclidean coordinate system, a Euclidean
metric can be used to measure the approximation error. Such an error measure is termed position error. Often
the maximum error in the absolute value of the difference between the true values and the approximate values
of each coordinate-component is used.
The average value of the magnitude of the differences of each coordinate-component of position error has also
been used as an error measure. This practice makes the approximation errors appear to be much smaller than
the maximum errors and depends on where the samples for the average are collected. This approach is
misleading and should not be used.
Sometimes the target variables contain angular errors along with distance errors. In this case the angular error
could be converted to distance so that a Euclidean error measure can be applied. For some spatial operations
involving angular error, the conformance criteria can be directly specified in terms of angular error. Some
variables, such as point distortion, are unit-less, and the resulting computational error is unit-less.
B.4.5 Avoid excessive computational accuracy
The literature on methods for spatial operations processing contains many algorithms that are excessively
accurate. One paper on geocentric to geodetic coordinate conversion develops a procedure where the
−20
approximation error is 10 metres, an accuracy far exceeding any practical use. Many iterative procedures can
achieve such accuracies provided that a computational environment is available with sufficiently high precision
arithmetic. However, it is important not to waste computer cycles to attain superfluous accuracy.
−8
EXAMPLE  A method, A, with maximum error 10 m is sometimes declared superior to a method, B, which has a
−6
maximal error of 10 m. If method A takes more processing time than method B, it is not superior. In fact, it is quite likely
−4
that both methods are too accurate. Suppose there is a method C with maximum error less than 10 metres but takes less
co
...

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

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) _1924 D.8, "SHB"]
astronomic)
Easter Island INTERNATIONAL- [NGA36, App.
EASTER_1967 60 Easter Island WGS_1984 1967 OBLATE_ELLIPSOID
(Ecuador) _1924 D.10, "EAS"]
BESSEL_1841- [NGA36, App.
ESTONIA_1937 64 Estonia WGS_1984 1937 Estonia OBLATE_ELLIPSOID
_ETHIOPIA D.5, "EST"]
OBLATE_ELLIPSOID- [HELM,
ETRF 65 ETRF WGS_1984 1989 Europe GRS_1980
_ORIGIN "EUT"]
INTERNATIONAL- [NGA36, App.
EUROPE_1950 67 European WGS_1984 1950 Europe OBLATE_ELLIPSOID
_1924 D.5, "EUR"]
INTERNATIONAL- [NGA36, App.
EUROPE_1979 68 European WGS_1984 1979 Europe OBLATE_ELLIPSOID
_1924 D.5, "EUS"]
© ISO/IEC 2025 – All rights reserved
ORM Published Reference Binding RD
ORM label Region ORMT label References
code name ORM information parameterization
[NGA36, App.
FAHUD_1987 69 Fahud WGS_1984 1987 Oman OBLATE_ELLIPSOID CLARKE_1880
D.3, "FAH"]
INTERNATIONAL- [NGA36, App.
FIJI_1956 306 Fiji WGS_1984 1956 Fiji OBLATE_ELLIPSOID
_1924 D.10, "FJI"]
St. Kitts, Nevis
[NGA36, App.
FORT_THOMAS_1955 70 Fort Thomas WGS_1984 1955 and Leeward OBLATE_ELLIPSOID CLARKE_1880
D.8, "FOT"]
Islands
Republic of INTERNATIONAL- [NGA36, App.
GAN_1970 72 Gan WGS_1984 1970 OBLATE_ELLIPSOID
Maldives _1924 D.9, "GAA"]
OBLATE_ELLIPSOID- [HELM,
GDA_1994 75 GDA WGS_1984 1994 Australia GRS_1980
_ORIGIN "GDS"]
GEODETIC_DATUM- Geodetic INTERNATIONAL- [NGA36, App.
76 WGS_1984 1949 New Zealand OBLATE_ELLIPSOID
_1949 Datum _1924 D.10, "GEO"]
[DIGEST,
GGRS87 274 GGRS 1987 WGS_1984 1987 Greece OBLATE_ELLIPSOID GRS_1980 Table 6.2,
"GRX"]
Faial, Graciosa,
Pico, Sao Jorge
GRACIOSA_BASE- Graciosa and Terceira INTERNATIONAL- [NGA36, App.
89 WGS_1984 1948 OBLATE_ELLIPSOID
_SW_1948 Base SW Islands (Central _1924 D.8, "GRA"]
Azores,
Portugal))
© ISO/IEC 2025 – All rights reserved
ORM Published Reference Binding RD
ORM label Region ORMT label References
code name ORM information parameterization
[NGA36, App.
GUAM_1963 90 Guam WGS_1984 1963 Guam OBLATE_ELLIPSOID CLARKE_1866
D.10, "GUA"]
Kalimantan
GUNONG_SEGARA- Gunung BESSEL_1841- [NGA36, App.
91 WGS_1984 1987 Island OBLATE_ELLIPSOID
_1987 Segara _ETHIOPIA E.2, "GSE"]
(Indonesia)
Guadalcanal
GUX1 INTERNATIONAL- [NGA36, App.
GUX_1_1987 92 WGS_1984 1987 Island (Solomon OBLATE_ELLIPSOID
(astronomic) _1924 D.10, "DOB"]
Islands)
HARTEBEESTHOEK- Hartebees- [EPSG, Code
275 WGS_1984 1994 South Africa OBLATE_ELLIPSOID GRS_1980
_1994 thoek 1994 6148]
HELSINKI_KALLIO- Helsinki Kallio INTERNATIONAL- [HELM, "HEL-
276 WGS_1984 2001 Finland OBLATE_ELLIPSOID
_CHURCH Church _1924 7"]
INTERNATIONAL- [NGA36, App.
HERAT_NORTH_1987 98 Herat North WGS_1984 1987 Afghanistan OBLATE_ELLIPSOID
_1924 E.2, "HEN"]
Yugoslavia
(prior to 1990),
HERMANNSKOGEL- Hermanns- Bosnia and BESSEL_1841- [NGA36, App.
99 WGS_1984 1871 OBLATE_ELLIPSOID
_1871 kogel Herzegovina, _ETHIOPIA E.2, "HER"]
Croatia, Serbia,
and Slovenia
INTERNATIONAL- [NGA36, App.
HJORSEY_1955 100 Hjorsey WGS_1984 1955 Iceland OBLATE_ELLIPSOID
_1924 D.5, "HJO"]
© ISO/IEC 2025 – All rights reserved
ORM Published Reference Binding RD
ORM label Region ORMT label References
code name ORM information parameterization
INTERNATIONAL- [NGA36, App.
HONG_KONG_1963 101 Hong Kong WGS_1984 1963 Hong Kong OBLATE_ELLIPSOID
_1924 D.3, "HKD"]
Hong Kong INTERNATIONAL- [HELM,
HONG_KONG_1980 277 WGS_1984 1980 Hong Kong OBLATE_ELLIPSOID
1980 _1924 "HKE"]
INTERNATIONAL- [NGA36, App.
HU_TZU_SHAN_1991 102 Hu-Tzu-Shan WGS_1984 1991 Taiwan OBLATE_ELLIPSOID
_1924 D.3, "HTN"]
[DIGEST,
HUNGARIAN_DATUM- Hungarian
278 WGS_1984 1972 Hungary OBLATE_ELLIPSOID GRS_1967 Table 6.2,
_1972 Datum 1972
"HUY"]
EVEREST_ADJ- [NGA36, App.
INDIAN_1916 105 Indian WGS_1984 1991 Bangladesh OBLATE_ELLIPSOID
_1937 D.3, "IND-B"]
EVEREST_ADJ- [NGA36, App.
INDIAN_1954 106 Indian WGS_1984 1954 Thailand OBLATE_ELLIPSOID
_1937 D.3, "INF"]
[NGA36, App.
INDIAN_1956 107 Indian WGS_1984 1991 India and Nepal OBLATE_ELLIPSOID EVEREST_1956
D.3, "IND-I"]
EVEREST_ADJ- [NGA36, App.
INDIAN_1960 108 Indian WGS_1984 1960 Vietnam OBLATE_ELLIPSOID
_1937 D.3, "ING"]
EVEREST- [NGA36, App.
INDIAN_1962 109 Indian WGS_1984 1962 Pakistan OBLATE_ELLIPSOID
_REVISED_1962 E.2, "IND-P"]
EVEREST_ADJ- [NGA36, App.
INDIAN_1975 110 Indian WGS_1984 1975 Thailand OBLATE_ELLIPSOID
_1937 D.3, "INH"]
© ISO/IEC 2025 – All rights reserved
ORM Published Reference Binding RD
ORM label Region ORMT label References
code name ORM information parameterization
INDONESIAN- [NGA36, App.
INDONESIAN_1974 111 Indonesian WGS_1984 1974 Indonesia OBLATE_ELLIPSOID
_1974 D.3, "IDN"]
Iraq-Kuwait
IRAQ_KUWAIT- [EPSG, Code
279 Boundary WGS_1984 1992 Iraq and Kuwait OBLATE_ELLIPSOID GRS_1980
_BOUNDARY_1992 6667]
Datum 1992
MODIFIED_AIRY- [NGA36, App.
IRELAND_1965 113 Ireland 1965 WGS_1984 1965 Ireland OBLATE_ELLIPSOID
_1849 D.5, "IRL"]
International
Satellite
Triangulation South Georgia INTERNATIONAL- [NGA36, App.
ISTS_061_1968 114 WGS_1984 1968 OBLATE_ELLIPSOID
Station Island (UK) _1924 D.8, "ISG"]
(ISTS) 061
(astronomic)
International
Satellite
Triangulation Diego Garcia INTERNATIONAL- [NGA36, App.
ISTS_073_1969 115 WGS_1984 1969 OBLATE_ELLIPSOID
Station (UK) _1924 D.9, "IST"]
(ISTS) 073
(astronomic)
© ISO/IEC 2025 – All rights reserved
ORM Published Reference Binding RD
ORM label Region ORMT label References
code name ORM information parameterization
Representa-
tive of
International
realisations
Terrestrial [ITRF],
ITRF 280 WGS_1984 1992, 1993, Global (Earth) OBLATE_ELLIPSOID GRS_1980
Reference [IERS36]
1994, 1996,
Frame
1997, 2000,
2005, and
2008.
Japanese
Geodetic OBLATE_ELLIPSOID- [ISOGR,
JGD_2000 117 WGS_1984 2000 Japan GRS_1980
Datum 2000 _ORIGIN Identifier 111]
(JGD2000)
Japanese
Geodetic OBLATE_ELLIPSOID- [ISOGR,
JGD_2011 299 WGS_1984 2011 Japan GRS_1980
Datum 2011 _ORIGIN Identifier 138
(JGD2011)
Johnston Island INTERNATIONAL- [NGA36, App.
JOHNSTON_1961 118 Johnston WGS_1984 1961 OBLATE_ELLIPSOID
(US) _1924 D.10, "JOH"]
EVEREST_ADJ- [NGA36, App.
KANDAWALA_1987 127 Kandawala WGS_1984 1987 Sri Lanka OBLATE_ELLIPSOID
_1937 D.3, "KAN"]
Kerguelen Island INTERNATIONAL- [NGA36, App.
KERGUELEN_1949 128 Kerguelen WGS_1984 1949 OBLATE_ELLIPSOID
(France) _1924 D.9, "KEG"]
West Malaysia [NGA36, App.
KERTAU_1948 129 Kertau WGS_1984 1948 OBLATE_ELLIPSOID EVEREST_1948
and Singapore D.3, "KEA"]
© ISO/IEC 2025 – All rights reserved
ORM Published Reference Binding RD
ORM label Region ORMT label References
code name ORM information parameterization
[DIGEST,
INTERNATIONAL-
KKJ 281 KKJ WGS_1984 1966 Finland OBLATE_ELLIPSOID Table 6.2,
_1924
"KKX"]
Korean
KOREAN_GEODETIC- [NGA36, App.
130 Geodetic WGS_1984 1995 South Korea OBLATE_ELLIPSOID WGS_1984
_1995 D.3, "KGS"]
System
Caroline Islands
Kusaie 1951 (Federated INTERNATIONAL- [NGA36, App.
KUSAIE_1951 131 WGS_1984 1951 OBLATE_ELLIPSOID
(astronomic) States of _1924 D.10, "KUS"]
Micronesia)
Cayman Brac
LC5 [NGA36, App.
LC5_1961 133 WGS_1984 1961 Island (Cayman OBLATE_ELLIPSOID CLARKE_1866
(astronomic) D.8, "LCF"]
Islands)
[NGA36, App.
LEIGON_1991 134 Leigon WGS_1984 1991 Ghana OBLATE_ELLIPSOID CLARKE_1880
D.2, "LEH"]
[NGA36, App.
LIBERIA_1964 135 Liberia WGS_1984 1964 Liberia OBLATE_ELLIPSOID CLARKE_1880
D.2, "LIB"]
Lisbon
(Castelo di INTERNATIONAL- [NGA36, App.
LISBON_D73 282 WGS_1984 1937 Portugal OBLATE_ELLIPSOID
Sao Jorge) _1924 D.5, "LIS"]
D73
Lithuania
[EPSG, Code
LKS94 283 1994 WGS_1984 1994 Lithuania OBLATE_ELLIPSOID GRS_1980
6126]
(ETRS89)
© ISO/IEC 2025 – All rights reserved
ORM Published Reference Binding RD
ORM label Region ORMT label References
code name ORM information parameterization
Luxembourg INTERNATIONAL-
LUXEMBOURG_NT 284 WGS_1984 2006 Luxembourg OBLATE_ELLIPSOID [HELM, ""]
NT _1924
[NGA36, App.
LUZON_1987 136 Luzon WGS_1984 1987 Philippines OBLATE_ELLIPSOID CLARKE_1866
D.10, "LUZ"]
[NGA36, App.
M_PORALOKO_1991 137 M'Poraloko WGS_1984 1991 Gabon OBLATE_ELLIPSOID CLARKE_1880
D.2, "MPO"]
Mahe Island [NGA36, App.
MAHE_1971 138 Mahe WGS_1984 1971 OBLATE_ELLIPSOID CLARKE_1880
(Seychelles) D.9, "MIK"]
Marcus
MARCUS_STATION- Marcus Island INTERNATIONAL- [NGA36, App.
139 Station WGS_1984 1952 OBLATE_ELLIPSOID
_1952 (Japan) _1924 D.10, "ASQ"]
(astronomic)
Mesoscale
Atmospheric [ERNWM,
MASS_1999 143 Simulation WGS_1984 1999 Global (Earth) SPHERE_ORIGIN MASS_1999 Table 1,
System "MASS"]
(MASS)
Eritrea and BESSEL_1841- [NGA36, App.
MASSAWA_1987 144 Massawa WGS_1984 1987 OBLATE_ELLIPSOID
Ethiopia _ETHIOPIA D.2, "MAS"]
MAYOTTE_COMBANI- Mayotte INTERNATIONAL- [NGA36, App.
307 WGS_1984 1950 Mayotte (France) OBLATE_ELLIPSOID
_1950 Combani _1924 E.2, "MCX"]
[NGA36, App.
MERCHICH_1987 145 Merchich WGS_1984 1987 Morocco OBLATE_ELLIPSOID CLARKE_1880
D.2, "MER"]
© ISO/IEC 2025 – All rights reserved
ORM Published Reference Binding RD
ORM label Region ORMT label References
code name ORM information parameterization
MGI [DIGEST,
MGI_DATUM- BESSEL_1841-
285 Datum/Her- WGS_1984 1901 Austria OBLATE_ELLIPSOID Table 6.2,
_HERMANNSKOGEL _ETHIOPIA
mannskogel "HER"]
Midway 1961 Midway Islands INTERNATIONAL- [NGA36, App.
MIDWAY_1961 149 WGS_1984 1961 OBLATE_ELLIPSOID
(astronomic) (US) _1924 D.10, "MID"]
Cameroon and [NGA36, App.
MINNA_1991 151 Minna WGS_1984 1991 OBLATE_ELLIPSOID CLARKE_1880
Nigeria D.2, "MIN"]
[ERNWM,
Table 1,
MM5_1997 153 MM5 (AFWA) WGS_1984 1997 Global (Earth) SPHERE_ORIGIN MM5_1997
"MM5
(AFWA)"]
[ERNWM,
MODTRAN- Northern MODTRAN-
Table 1,
_MIDLATITUDE_N- 154 MODTRAN WGS_1984 1989 midlatitude SPHERE_ORIGIN _MIDLATITUDE-
"MODTRAN,
_1989 regions (Earth) _1989
Midlatitude"]
[ERNWM,
MODTRAN- Southern MODTRAN-
Table 1,
_MIDLATITUDE_S- 155 MODTRAN WGS_1984 1989 midlatitude SPHERE_ORIGIN _MIDLATITUDE-
"MODTRAN,
_1989 regions (Earth) _1989
Midlatitude"]
[ERNWM,
Northern MODTRAN-
MODTRAN- Table 1,
156 MODTRAN WGS_1984 1989 subarctic regions SPHERE_ORIGIN _SUBARCTIC-
_SUBARCTIC_N_1989 "MODTRAN,
(Earth) _1989
Subarctic"]
© ISO/IEC 2025 – All rights reserved
ORM Published Reference Binding RD
ORM label Region ORMT label References
code name ORM information parameterization
[ERNWM,
Southern MODTRAN-
MODTRAN- Table 1,
157 MODTRAN WGS_1984 1989 subarctic regions SPHERE_ORIGIN _SUBARCTIC-
_SUBARCTIC_S_1989 "MODTRAN,
(Earth) _1989
Subarctic"]
[ERNWM,
MODTRAN- Tropical regions MODTRAN- Table 1,
158 MODTRAN WGS_1984 1989 SPHERE_ORIGIN
_TROPICAL_1989 (Earth) _TROPICAL_1989 "MODTRAN,
Tropical"]
Montserrat and
Montserrat [NGA36, App.
MONTSERRAT_1958 159 WGS_1984 1958 Leeward Islands OBLATE_ELLIPSOID CLARKE_1880
(astronomic) D.8, "ASM"]
(UK)
MULTIGEN_FLAT- Multigen flat MULTIGEN_FLAT-
161 WGS_1984 1989 Global (Earth) SPHERE_ORIGIN [MFCG]
_EARTH_1989 Earth _EARTH_1989
North [NGA36, App.
N_AM_1927 162 WGS_1984 1927 North America OBLATE_ELLIPSOID CLARKE_1866
American D.6, "NAS"]
[NGA36, App.
North
N_AM_1983 163 WGS_1984 1983 North America OBLATE_ELLIPSOID GRS_1980 D.6, "NAR"],
American
[NAD83]
[NGA36, App.
N_SAHARA_1959 164 North Sahara WGS_1984 1959 Algeria OBLATE_ELLIPSOID CLARKE_1880
D.2, "NSD"]
Oman, Saudi
Arabia, and the [NGA36, App.
NAHRWAN_1987 165 Nahrwan WGS_1984 1987 OBLATE_ELLIPSOID CLARKE_1880
United Arab D.3, "NAH"]
Emirates
© ISO/IEC 2025 – All rights reserved
ORM Published Reference Binding RD
ORM label Region ORMT label References
code name ORM information parameterization
Naparima,
Trinidad and INTERNATIONAL- [NGA36, App.
NAPARIMA_1991 167 British West WGS_1984 1991 OBLATE_ELLIPSOID
Tobago _1924 D.8, "NAP"]
Indies (BWI)
BESSEL- [HELM,
NGO_1948 286 NGO 1948 WGS_1984 1948 Norway OBLATE_ELLIPSOID
_MODIFIED "NGO-7"]
[ERNWM,
NOGAPS_1988 171 NOGAPS WGS_1984 1988 Global (Earth) SPHERE_ORIGIN NOGAPS_1988 Table 1,
"NOGAPS"]
New
Triangulation CLARKE_1880- [NGA36, App.
NTF_1896 172 WGS_1984 1896 France OBLATE_ELLIPSOID
of France _IGN E.2, "NTF"]
(NTF)
New The
Triangulation x-positive
of France xz-half-plane
CLARKE_1880- [NGA36, App.
NTF_1896_PM_PARIS 173 (NTF) (with WGS_1984 contains France OBLATE_ELLIPSOID
_IGN E.2, "NTF"]
the Prime Paris, France
Meridian at (IGN 1936
Paris) determina-
tion).
Corvo and Flores
OBSERV_METEORO- Observatorio INTERNATIONAL- [NGA36, App.
175 WGS_1984 1939 Islands (Azores, OBLATE_ELLIPSOID
_1939 Meteorologico _1924 D.8, "FLO"]
Portugal)
© ISO/IEC 2025 – All rights reserved
ORM Published Reference Binding RD
ORM label Region ORMT label References
code name ORM information parameterization
Observatório
OBSERV_CAMPOS- Mozambique [NGA36, App.
287 Campos WGS_1984 1907 OBLATE_ELLIPSOID CLARKE_1866
_RODRIGUES_1907 South D.2, "CPR"]
Rodrigues
[NGA36, App.
OCOTEPEQUE_1935 308 Ocotepeque WGS_1984 1935 Costa Rica OBLATE_ELLIPSOID CLARKE_1866
E.2, "OCE"]
[NGA36, App.
OLD_EGYPTIAN_1907 176 Old Egyptian WGS_1984 1907 Egypt OBLATE_ELLIPSOID HELMERT_1906
D.2, "OEG"]
OLD_HAWAIIAN- Old Hawaiian [NGA36, App.
177 WGS_1984 1987 Hawaiian Islands OBLATE_ELLIPSOID CLARKE_1866
_CLARKE_1987 (Clarke) D.10, "OHA"]
OLD_HAWAIIAN- Old Hawaiian INTERNATIONAL- [NGA36, App.
178 WGS_1984 1987 Hawaiian Islands OBLATE_ELLIPSOID
_INT_1987 (International) _1924 D.10, "OHI"]
Ordnance
[NGA36, App.
OSGB_1936 180 Survey of WGS_1984 1936 Great Britain OBLATE_ELLIPSOID AIRY_1830
D.5, "OGB"]
Great Britain
[DIGEST,
Palestine CLARKE_1880-
PALESTINE_1928 288 WGS_1984 1928 Israel OBLATE_ELLIPSOID Table 6.2,
1928 _PALESTINE
"PAL"]
PICO_DE_LAS- Pico de las Canary Islands INTERNATIONAL- [NGA36, App.
185 WGS_1984 1987 OBLATE_ELLIPSOID
_NIEVES_1987 Nieves (Spain) _1924 D.8, "PLN"]
Pitcairn Pitcairn Island INTERNATIONAL- [NGA36, App.
PITCAIRN_1967 186 WGS_1984 1967 OBLATE_ELLIPSOID
(astronomic) (UK) _1924 D.10, "PIT"]
© ISO/IEC 2025 – All rights reserved
ORM Published Reference Binding RD
ORM label Region ORMT label References
code name ORM information parameterization
Burkina Faso and [NGA36, App.
POINT_58_1991 189 Point 58 WGS_1984 1991 OBLATE_ELLIPSOID CLARKE_1880
Niger D.2, "PTB"]
[NGA36, App.
POINTE_NOIRE_1948 190 Pointe Noire WGS_1984 1948 Congo OBLATE_ELLIPSOID CLARKE_1880
D.2, "PTN"]
Porto Santo and
INTERNATIONAL- [NGA36, App.
PORTO_SANTO_1936 192 Porto Santo WGS_1984 1936 Madeira Islands OBLATE_ELLIPSOID
_1924 D.8, "POS"]
(Portugal)
Provisional
INTERNATIONAL- [NGA36, App.
PROV_S_AM_1956 195 South WGS_1984 1956 South America OBLATE_ELLIPSOID
_1924 D.7, "PRP"]
American
Provisional
PROV_S_CHILEAN- INTERNATIONAL- [NGA36, App.
196 South Chilean WGS_1984 1963 South Chile OBLATE_ELLIPSOID
_1963 _1924 D.7, "HIT"]
(Hito XVIII)
Puerto Rico and
[NGA36, App.
PUERTO_RICO_1987 198 Puerto Rico WGS_1984 1987 Virgin Islands OBLATE_ELLIPSOID CLARKE_1866
D.8, "PUR"]
(US)
KRASSOVSKY- [NGA36, App.
PULKOVO_1942 199 Pulkovo WGS_1984 1942 Russia OBLATE_ELLIPSOID
_1940 E.2, "PUK"]
Soviet [DIGEST,
SOVIET-
PZ90_GLONASS 289 Geodetic WGS_1984 1990 Russia OBLATE_ELLIPSOID Table 6.2,
_GEODETIC_1990
System 1990 "SGB"]
© ISO/IEC 2025 – All rights reserved
ORM Published Reference Binding RD
ORM label Region ORMT label References
code name ORM information parameterization
QATAR_NATIONAL- INTERNATIONAL- [NGA36, App.
200 Qatar National WGS_1984 1974 Qatar OBLATE_ELLIPSOID
_1974 _1924 D.3, "QAT"]
QATAR_NATIONAL- Qatar National INTERNATIONAL- [EPSG, Code
290 WGS_1984 1995 Qatar OBLATE_ELLIPSOID
_1995 Datum 1995 _1924 6614]
INTERNATIONAL- [NGA36, App.
QORNOQ_1987 201 Qornoq WGS_1984 1987 South Greenland OBLATE_ELLIPSOID
_1924 D.8, "QUO"]
Mascarene
Islands (Republic INTERNATIONAL- [NGA36, App.
REUNION_1947 202 Reunion WGS_1984 1947 OBLATE_ELLIPSOID
of Mauritius and _1924 D.9, "REU"]
Reunion)
Reseau
RGF_1993 203 Geodesique WGS_1984 1993 France OBLATE_ELLIPSOID GRS_1980 [RGF]
Francais
Rome (also Italy mainland,
INTERNATIONAL- [NGA36, App.
ROME_1940 205 known as WGS_1984 1940 Sardinia, and OBLATE_ELLIPSOID
_1924 D.5, "MOD"]
Monte Mario) Sicily
Rome (also
known as
The
Monte Mario) Italy mainland,
ROME_1940_PM- x-positive INTERNATIONAL- [NGA36, App.
206 (with the WGS_1984 Sardinia, and OBLATE_ELLIPSOID
xz-half-plane
_ROME _1924 D.5, "MOD"]
Prime Sicily
contains
Meridian at
Rome, Italy.
Rome)
© ISO/IEC 2025 – All rights reserved
ORM Published Reference Binding RD
ORM label Region ORMT label References
code name ORM information parameterization
RT90, [DIGEST,
BESSEL_1841-
RT90 291 Stockholm, WGS_1984 1990 Sweden OBLATE_ELLIPSOID Table 6.2,
_ETHIOPIA
Sweden "RTS"]
SOUTH-
South [NGA36, App.
S_AM_1969 208 WGS_1984 1969 South America OBLATE_ELLIPSOID _AMERICAN_196
American D.7, "SAN"]
MODIFIED- [NGA36, App.
S_ASIA_1987 209 South Asia WGS_1984 1987 Singapore OBLATE_ELLIPSOID
_FISCHER_1960 D.3, "SOA"]
Czechia and BESSEL_1841- [NGA36, App.
S_JTSK_1993 210 S-JTSK WGS_1984 1993 OBLATE_ELLIPSOID
Slovakia _ETHIOPIA D.5, "CCD"]
S-42 KRASSOVSKY- [NGA36, App.
S42_PULKOVO 211 WGS_1984 1942 Eastern Europe OBLATE_ELLIPSOID
(Pulkovo) _1940 D.5, "SPK"]
Espirito Santo INTERNATIONAL- [NGA36, App.
SANTO_DOS_1965 212 Santo (DOS) WGS_1984 1965 OBLATE_ELLIPSOID
Island (Vanuatu) _1924 D.10, "SAE"]
Sao Miguel and
Santa Maria INTERNATIONAL- [NGA36, App.
SAO_BRAZ_1987 213 Sao Braz WGS_1984 1987 OBLATE_ELLIPSOID
Islands (Azores, _1924 D.8, "SAO"]
Portugal)
East Falkland INTERNATIONAL- [NGA36, App.
SAPPER_HILL_1943 214 Sapper Hill WGS_1984 1943 OBLATE_ELLIPSOID
Islands _1924 D.8, "SAP"]
© ISO/IEC 2025 – All rights reserved
ORM Published Reference Binding RD
ORM label Region ORMT label References
code name ORM information parameterization
Sapper Hill
[DIGEST,
SAPPER_HILL_1943- 1943 INTERNATIONAL-
292 WGS_1984 2000 Falkland Islands OBLATE_ELLIPSOID Table 6.2,
_2000 (adjusted _1924
"SAP"]
2000)
BESSEL_1841- [NGA36, App.
SCHWARZECK_1991 218 Schwarzeck WGS_1984 1991 Namibia OBLATE_ELLIPSOID
_NAMIBIA D.2, "SCK"]
Salvage Islands,
SELVAGEM_GRANDE- Selvagem aka Selvagens INTERNATIONAL- [NGA36, App.
219 WGS_1984 1938 OBLATE_ELLIPSOID
_1938 Grande or; Savage _1924 D.8, "SGM"]
Islands (Portugal)
[NGA36, App.
SIERRA_LEONE_1960 220 Sierra Leone WGS_1984 1960 Sierra Leone OBLATE_ELLIPSOID CLARKE_1880
D.2, "SRL"]
OBLATE_ELLIPSOID- [NGA36, App.
SIRGAS_2000 221 SIRGAS WGS_1984 2000 South America GRS_1980
_ORIGIN D.7, "SIR"]
SOUTH_EAST- South East [NGA36, App.
293 WGS_1984 1943 Seychelles OBLATE_ELLIPSOID CLARKE_1880
_ISLAND Island D.9, "SEI"]
Soviet [DIGEST,
SOVIET_GEODETIC- SOVIET-
294 Geodetic WGS_1984 1985 Russia OBLATE_ELLIPSOID Table 6.2,
_SYSTEM_1985 _GEODETIC_1985
System 1985 "SGA"]
Saint Pierre and
ST_PIERRE- St. Pierre et [NGA36, App.
309 WGS_1984 1950 Miquelon OBLATE_ELLIPSOID CLARKE_1866
_MIQUELON Miquelon E.2, "SPX"]
(France)
© ISO/IEC 2025 – All rights reserved
ORM Published Reference Binding RD
ORM label Region ORMT label References
code name ORM information parameterization
TANANARIVE_OBS- Tananarive INTERNATIONAL- [NGA36, App.
223 WGS_1984 1925 Madagascar OBLATE_ELLIPSOID
_1925 Observatory _1924 D.9, "TAN"]
The
Tananarive
x-positive
Observatory
xz-half-plane
TANANARIVE_OBS- (with the INTERNATIONAL- [NGA36, App.
224 WGS_1984 contains Madagascar OBLATE_ELLIPSOID
_1925_PM_PARIS Prime _1924 D.9, "TAN"]
Paris, France
Meridian at
(IGN 1936
Paris)
determina-
tion).
Tern Island
Tern (French Frigate INTERNATIONAL- [NGA36, App.
TERN_1961 226 WGS_1984 1961 OBLATE_ELLIPSOID
(astronomic) Shoals, Hawaiian _1924 D.10, "TRN"]
Islands)
[NGA36, App.
TETE 295 Tete WGS_1984 1960 Mozambique OBLATE_ELLIPSOID CLARKE_1866
D.2, "TEC"]
TIMBALAI_BESSEL- Timbalai Brunei and East BESSEL_1841- [HELM, "TIV-
298 WGS_1984 1948 OBLATE_ELLIPSOID
_1948 (Bessel) Malaysia _ETHIOPIA 7"]
Timbalai 1968
adjustment
TIMBALAI_BESSEL- Brunei and East BESSEL_1841- [HELM, "TIM-
296 of 1948 with WGS_1984 1968 OBLATE_ELLIPSOID
_1948_1968 Malaysia _ETHIOPIA 7"]
Bessel
ellipsoid
© ISO/IEC 2025 – All rights reserved
ORM Published Reference Binding RD
ORM label Region ORMT label References
code name ORM information parameterization
Brunei and East
TIMBALAI_EVEREST- Timbalai EVEREST- [NGA36, App.
230 WGS_1984 1948 Malaysia (Sabah OBLATE_ELLIPSOID
_1948 (Everest) _BRUNEI_1967 D.3, "TIL"]
and Sarawak)
Timbalai 1968
adjustment
TIMBALAI_EVEREST- Brunei and East EVEREST- [NGA36, App.
297 of 1948 with WGS_1984 1968 OBLATE_ELLIPSOID
_1948_1968 Malaysia _BRUNEI_1967 D.3, "TIN"]
Everest
ellipsoid
Japan, Korea, BESSEL_1841- [NGA36, App.
TOKYO_1991 233 Tokyo WGS_1984 1991 OBLATE_ELLIPSOID
and Okinawa _ETHIOPIA D.3, "TOY"]
Tristan Tristan da Cunha INTERNATIONAL- [NGA36, App.
TRISTAN_1968 234 WGS_1984 1968 OBLATE_ELLIPSOID
(astronomic) (UK) _1924 D.8, "TDC"]
Viti Levu Island [NGA36, App.
VITI_LEVU_1916 242 Viti Levu WGS_1984 1916 OBLATE_ELLIPSOID CLARKE_1880
(Fiji Islands) D.10, "MVS"]
Algeria and [NGA36, App.
VOIROL_1874 243 Voirol WGS_1984 1874 OBLATE_ELLIPSOID CLARKE_1880
Tunisia E.2, "VOI"]
The
x-positive
Voirol (with
xz-half-plane
VOIROL_1874_PM- the Prime Algeria and [NGA36, App.
244 WGS_1984 contains OBLATE_ELLIPSOID CLARKE_1880
_PARIS Meridian at Tunisia E.2, "VOI"]
Paris, France
Paris)
(IGN 1936
determina-
tion).
© ISO/IEC 2025 – All rights reserved
ORM Published Reference Binding RD
ORM label Region ORMT label References
code name ORM information parameterization
Voirol - [NGA36, App.
VOIROL_1960 245 WGS_1984 1960 Algeria OBLATE_ELLIPSOID CLARKE_1880
Revised D.2, "VOR"]
The
Voirol - x-positive
Revised (with xz-half-plane
VOIROL_1960_PM- [NGA36, App.
246 the Prime WGS_1984 contains Algeria OBLATE_ELLIPSOID CLARKE_1880
_PARIS D.2, "VOR"]
Meridian at Paris, France
Paris) (IGN 1936
determina-
tion).
Wake Atoll (US
Wake INTERNATIONAL- [NGA36, App.
WAKE_1952 247 WGS_1984 1952 minor outlying OBLATE_ELLIPSOID
(astronomic) _1924 D.10, "WAK"]
islands)
WAKE_ENIWETOK- Wake- [NGA36, App.
248 WGS_1984 1960 Marshall Islands OBLATE_ELLIPSOID HOUGH_1960
_1960 Eniwetok D.10, "ENW"]
World
OBLATE_ELLIPSOID-
WGS_1972 249 Geodetic WGS_1984 1972 Global (Earth) WGS_1972 [WGS72]
_ORIGIN
System
© ISO/IEC 2025 – All rights reserved
ORM Published Reference Binding RD
ORM label Region ORMT label References
code name ORM information parameterization
1984 ellipsoid
centred at the
Earth centre
of mass, z-
axis points to
This is the the IERS
World
reference reference OBLATE_ELLIPSOID-
WGS_1984 250 Geodetic Global (Earth) WGS_1984 [NGA36]
ORM for pole, the x- _ORIGIN
System
Earth. axis points to
the IERS
reference
meridian
(Greenwich
meridian).
INTERNATIONAL- [NGA36, App.
YACARE_1987 251 Yacare WGS_1984 1987 Uruguay OBLATE_ELLIPSOID
_1924 E.2, "YAC"]
INTERNATIONAL- [NGA36, App.
ZANDERIJ_1987 252 Zanderij WGS_1984 1987 Suriname OBLATE_ELLIPSOID
_1924 D.7, "ZAN"]
© ISO/IEC 2025 – All rights reserved
NOTE 1: In Table E.6, when two references appear in the References element of an RT specification, the second reference, [GEOTRANS] or [EPSG], is the reference for the latitude
and longitude values in the RT region element. The first reference listed is the reference for all other elements of such an RT specification, including the region name(s) in the RT
region element.
NOTE 2: For non-Greenwich prime meridian RT specifications in Table E.6,, the RT region longitude values are offset by ω , when applicable, and the RT parameter value, ω , is
3 3
specified by this document.
NOTE 3: In Table E.6, the phrase "Cycle number:" followed by an integer is appended to the References element of an RT specification to identify the non-zero cycle number in the
reference from which the STT parameter values were obtained. When this phrase does not appear in the References element, cycle number zero is intended.
NOTE 4: In Table E.6 and the other RT tables, if the RT region is described as "Global", and the associated transformation is not IDENTITY, explicit spatial boundaries
for the RT region are provided with values −90° ≤φ≤  +90°; −180° ≤λ≤ +180°.
Table E.6 — Object-fixed ERM reference transformation specifications
RT STT label and Date
ORM label RT label RT region References
code parameter values published
TRANSLATE [NGA36, App.
Ghana;
Δx = −170 : σx = 3, D.2, "ACC"],
ACCRA ACCRA_GHANA 357 +4° ≤ φ ≤ +13°; 2012
Δy = 33  : σy = 4, [GEOTRANS,
−4° ≤ λ ≤ +3°
Δz = 326 : σz = 3. "ACC"]
TRANSLATE [NGA36, App.
Yemen;
Δx = −24, E.2, "ADN"],
ADEN_1925 ADEN_1925_YEMEN 420 +12° ≤ φ ≤ +19°; 2012
Δy = −203, [GEOTRANS,
+42° ≤ λ ≤ +47°
Δz = 268. "ADN"]
TRANSLATE [NGA36, App.
Burkina Faso;
ADINDAN_1991- Δx = −118 : σx = 25, D.2, "ADI-E"],
ADINDAN_1991 3 +4° ≤ φ ≤ +22°; 1991
Δy = −14 : σy = 25, [GEOTRANS,
_BURKINA_FASO
−12° ≤ λ ≤ +8°
Δz = 218 : σz = 25. "ADI-E"]
© ISO/IEC 2025 – All rights reserved
RT STT label and Date
ORM label RT label RT region References
code parameter values published
TRANSLATE [NGA36, App.
Cameroon;
Δx = −134 : σx = 25, D.2, "ADI-F"],
ADINDAN_1991_CAMEROON 4 −4° ≤ φ ≤ +19°; 1991
Δy = −2  : σy = 25, [GEOTRANS,
+3° ≤ λ ≤ +23°
Δz = 210 : σz = 25. "ADI-F"]
TRANSLATE [NGA36, App.
Ethiopia;
Δx = −165 : σx = 3, D.2, "ADI-A"],
ADINDAN_1991_ETHIOPIA 5 −3° ≤ φ ≤ +25°; 1991
Δy = −11 : σy = 3, [GEOTRANS,
+26° ≤ λ ≤ +50°
Δz = 206 : σz = 3. "ADI-A"]
TRANSLATE [NGA36, App.
Mali;
Δx = −123 : σx = 25, D.2, "ADI-C"],
ADINDAN_1991_MALI 6 +3° ≤ φ ≤ +31°; 1991
Δy = −20 : σy = 25, [GEOTRANS,
−20° ≤ λ ≤ +11°
Δz = 220 : σz = 25. "ADI-C"]
Mean Solution (Ethiopia TRANSLATE [NGA36, App.
ADINDAN_1991- and Sudan); Δx = −166 : σx = 5, D.2, "ADI-M"],
7 1991
_MEAN_SOLUTION −5° ≤ φ ≤ +31°; Δy = −15 : σy = 5, [GEOTRANS,
+15° ≤ λ ≤ +55° Δz = 204 : σz = 3. "ADI-M"]
TRANSLATE [NGA36, App.
Senegal;
Δx = −128 : σx = 25, D.2, "ADI-D"],
ADINDAN_1991_SENEGAL 8 +5° ≤ φ ≤ +23°; 1991
Δy = −18 : σy = 25, [GEOTRANS,
−24° ≤ λ ≤ −5°
Δz = 224 : σz = 25. "ADI-D"]
TRANSLATE [NGA36, App.
Sudan;
Δx = −161 : σx = 3, D.2, "ADI-B"],
ADINDAN_1991_SUDAN 9 −3° ≤ φ ≤ +31°; 1991
Δy = −14 : σy = 5, [GEOTRANS,
+15° ≤ λ ≤ +45°
Δz = 205 : σz = 3. "ADI-B"]
© ISO/IEC 2025 – All rights reserved
RT STT label and Date
ORM label RT label RT region References
code parameter values published
TRANSLATE [NGA36, App.
Somalia;
Δx = −43 : σx = 25, D.2," AFG"],
AFGOOYE_1987 AFGOOYE_1987_SOMALIA 11 −8° ≤ φ ≤ +19°; 1987
Δy = −163 : σy = 25, [GEOTRANS,
+35° ≤ λ ≤ +60°
Δz = 45  : σz = 25. "AFG"]
TRANSLATE [NGA36, App.
Bahrain Island;
AIN_EL_ABD_1970- Δx = −150 : σx = 25, D.3, "AIN-A"],
12 +24° ≤ φ ≤ +28°; 1991
_BAHRAIN_ISLAND Δy = −250 : σy = 25, [GEOTRANS,
+49° ≤ λ ≤ +53°
Δz = −1  : σz = 25. "AIN-A"]
AIN_EL_ABD_1970
TRANSLATE [NGA36, App.
Saudi Arabia;
AIN_EL_ABD_1970- Δx = −143 : σx = 10, D.3, "AIN-B"],
13 +8° ≤ φ ≤ +38°; 1991
_SAUDI_ARABIA Δy = −236 : σy = 10, [GEOTRANS,
+28° ≤ λ ≤ +62°
Δz = 7  : σz = 10. "AIN-B"]
TRANSLATE [NGA36, App.
AMERICAN_SAMOA_1962- American Samoa Islands;
AMERICAN_SAMOA- Δx = −115 : σx = 25, D.10, "AMA"],
_AMERICAN_SAMOA- 15 −19° ≤ φ ≤ −9°; 1993
_1962 Δy = 118 : σy = 25, [GEOTRANS,
_ISLANDS −174° ≤ λ ≤ −165°
Δz = 426 : σz = 25. "AMA"]
PV_7_PARAMETER
Δx = 565 : σx = 1,
Δy = 49,9 : σy = 1,
Netherlands; [HELM, "AME-7"],
AMERSFOORT_7- Δz = 465,8 : σz = 1,
+50,75° ≤ φ ≤ +55,77°; [EPSG, Code
AMERSFOORT 358 2001
_NETHERLANDS ω = −0,409″,
+2,53° ≤ λ ≤ +7,22° 1172]
ω2 = 0,36″,
ω = −1,869″,
−6
Δs = 4,08 x 10 .
© ISO/IEC 2025 – All rights reserved
RT STT label and Date
ORM label RT label RT region References
code parameter values published
TRANSLATE [NGA36, App.
Cocos Islands;
ANNA_1_1965_COCOS- Δx = −491 : σx = 25, D.9, "ANO"],
ANNA_1_1965 16 −14° ≤ φ ≤ −10°; 1987
_ISLANDS Δy = −22 : σy = 25, [GEOTRANS,
+94° ≤ λ ≤ +99°
Δz = 435 : σz = 25. "ANO"]
Antigua and Leeward TRANSLATE [NGA36, App.
ANTIGUA_1943_ANTIGUA- Islands; Δx = −270 : σx =
...

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 _ORIGIN_3D "DGRF
more accurate
epoch for the 5 year 1985"]
information in IAGA.
period 1985 to 1990.
Superseded by
OBRS [DAGF,
GEOMAGNETIC_1990-
GEOMAGNETIC DGRF CELESTIOMAGNETIC Vicinity BI_AXIS- Table I,
86 WGS_1984 n/a _IGRF13, based on
_1990 1990 Note: Object-fixed base of Earth _ORIGIN_3D "DGRF
more accurate
epoch for the 5 year 1990"]
information in IAGA.
period 1990 to 1995.
Superseded by
OBRS
[DAGF, GEOMAGNETIC_1995-
GEOMAGNETIC CELESTIOMAGNETIC Vicinity BI_AXIS-
87 IGRF 1995 WGS_1984 n/a Table I, _IGRF13, based on
_1995 Note: Object-fixed base of Earth _ORIGIN_3D
"IGRF 1995"] more accurate
epoch for the 5 year
information in IAGA.
period 1995 to 2000.
Superseded by
OBRS
[DAGF, GEOMAGNETIC_2000-
GEOMAGNETIC CELESTIOMAGNETIC Vicinity BI_AXIS-
88 IGRF 2000 WGS_1984 n/a Table I, _IGRF13, based on
_2000 Note: Object-fixed base of Earth _ORIGIN_3D
"IGRF 2000"] more accurate
epoch for the 5 year
information in IAGA.
period 2000 to 2005.
© ISO/IEC 2025 – All rights reserved
Table J.11 — Deprecated time-fixed instances of dynamic ERM RTs
Date
RT
ORM label RT label RT region STT label and parameter values publi References Notes
code
shed
PV_ZY_ROTATE Superseded by
[DAGF,
ω2 = 11,53°, GEOMAGNETIC_1945_IGRF13-
GEOMAGNETIC GEOMAGNETIC_1945- Table I,
105 Global (Earth) ω = −68,53°. 1945 _GLOBAL, based on more accurate
_1945 _DGRF "DGRF
Note: Centred dipole model northern information in IAGA.
1945"]
pole.
PV_ZY_ROTATE Superseded by
[DAGF,
ω2 = 11,53°, GEOMAGNETIC_1950_IGRF13-
GEOMAGNETIC GEOMAGNETIC_1950- Table I,
106 Global (Earth) ω = −68,85°. 1950 _GLOBAL, based on more accurate
_1950 _DGRF "DGRF
Note: Centred dipole model northern information in IAGA.
1950"]
pole.
PV_ZY_ROTATE Superseded by
[DAGF,
ω2 = 11,54°, GEOMAGNETIC_1955_IGRF13-
GEOMAGNETIC GEOMAGNETIC_1955- Table I,
107 Global (Earth) ω = −69,16°. 1955 _GLOBAL, based on more accurate
_1955 _DGRF "DGRF
Note: Centred dipole model northern information in IAGA.
1955"]
pole.
PV_ZY_ROTATE Superseded by
[DAGF,
ω2 = 11,49°, GEOMAGNETIC_1960_IGRF13-
GEOMAGNETIC GEOMAGNETIC_1960- Table I,
108 Global (Earth) ω = −69,47°. 1960 _GLOBAL, based on more accurate
_1960 _DGRF "DGRF
Note: Centred dipole model northern information in IAGA.
1960"]
pole.
PV_ZY_ROTATE Superseded by
[DAGF,
ω2 = 11,47°, GEOMAGNETIC_1965_IGRF13-
GEOMAGNETIC GEOMAGNETIC_1965- Table I,
109 Global (Earth) ω = −69,85°. 1965 _GLOBAL, based on more accurate
_1965 _DGRF "DGRF
Note: Centred dipole model northern information in IAGA.
1965"]
pole.
© ISO/IEC 2025 – All rights reserved
Date
RT
ORM label RT label RT region STT label and parameter values publi References Notes
code
shed
PV_ZY_ROTATE Superseded by
[DAGF,
ω2 = 11,41°, GEOMAGNETIC_1970_IGRF13-
GEOMAGNETIC GEOMAGNETIC_1970- Table I,
110 Global (Earth) ω = −70,18°. 1970 _GLOBAL, based on more accurate
_1970 _DGRF "DGRF
Note: Centred dipole model northern information in IAGA.
1970"]
pole.
PV_ZY_ROTATE
[DAGF, Superseded by
ω2 = 11,31°,
GEOMAGNETIC GEOMAGNETIC_1975- Table I, GEOMAGNETIC_1975_IGRF13-
111 Global (Earth) ω = −70,47°. 1975
_1975 _DGRF "DGRF _GLOBAL, based on more accurate
Note: Centred dipole model northern
1975"] information in IAGA.
pole.
PV_ZY_ROTATE Superseded by
[DAGF,
ω2 = 11,19°, GEOMAGNETIC_1980_IGRF13-
GEOMAGNETIC GEOMAGNETIC_1980- Table I,
112 Global (Earth) ω = −70,76°. 1980 _GLOBAL, based on more accurate
_1980 _DGRF "DGRF
Note: Centred dipole model northern information in IAGA.
1980"]
pole.
PV_ZY_ROTATE Superseded by
[DAGF,
ω2 = 11,03°, GEOMAGNETIC_1985_IGRF13-
GEOMAGNETIC GEOMAGNETIC_1985- Table I,
113 Global (Earth) ω = −70,9°. 1985 _GLOBAL, based on more accurate
_1985 _DGRF "DGRF
Note: Centred dipole model northern information in IAGA.
1985"]
pole.
PV_ZY_ROTATE Superseded by
[DAGF,
ω2 = 10,87°, GEOMAGNETIC_1990_IGRF13-
GEOMAGNETIC GEOMAGNETIC_1990- Table I,
114 Global (Earth) ω = −71,11°. 1990 _GLOBAL, based on more accurate
_1990 _DGRF "DGRF
Note: Centred dipole model northern information in IAGA.
1990"]
pole.
© ISO/IEC 2025 – All rights reserved
Date
RT
ORM label RT label RT region STT label and parameter values publi References Notes
code
shed
PV_ZY_ROTATE Superseded by
ω = 10,7°, [DAGF, GEOMAGNETIC_1995_IGRF13-
GEOMAGNETIC GEOMAGNETIC_1995-
115 Global (Earth) ω3 = −71,41°. 1995 Table I, _GLOBAL, based on more accurate
_1995 _IGRF
Note: Centred dipole model northern "IGRF 1995"] information in IAGA.
pole.
PV_ZY_ROTATE Superseded by
ω = 10,46°, [DAGF, GEOMAGNETIC_2000_IGRF13-
GEOMAGNETIC GEOMAGNETIC_2000-
116 Global (Earth) ω2 = −71,57°. 2000 Table I, _GLOBAL, based on more accurate
_2000 _IGRF
Note: Centred dipole model northern "IGRF 2000"] information in IAGA.
pole.
Table J.12 — Deprecated object-fixed planet (non-Earth) ORMs
ORM Published Reference Binding RD
ORM label Region ORMT label References Notes
code name ORM information parameterization
This is the The x-positive xz-half-
reference plane as determined by an Superseded by
Eros
ORM for Eros ephemeris as specified in Eros, [RIIC, Table EROS_2002, based on
EROS_2000 63 (asteroid SPHERE EROS_2000
(asteroid 433, {Table III, "Eros"}, with its Global III, "Eros"] more accurate
433)
a minor associated accuracy as information in RIIC15.
planet). specified in {Section 2,
paragraph 5}.
© ISO/IEC 2025 – All rights reserved
ORM Published Reference Binding RD
ORM label Region ORMT label References Notes
code name ORM information parameterization
The x-positive xz-half-
This is the
plane as determined by an Superseded by
reference
ephemeris as specified in Jupiter, OBLATE- [RIIC, Table JUPITER_2006, based
JUPITER_1988 120 Jupiter ORM for JUPITER_1988
{Table 1, "Jupiter"}, with its Global _ELLIPSOID I, "Jupiter"] on more accurate
Jupiter (a
associated accuracy as information in RIIC15.
planet).
specified in {Section 2,
paragraph 5}.
The x-positive xz-half-
plane as determined by an
Superseded by
This is the observable fixed surface
MERCURY_2015 and
reference feature and approximated
MERCURY- Mercury, [RIIC, Table MERCURY_SPHERE-
146 Mercury ORM for by an ephemeris as SPHERE MERCURY_1988
_1988 Global I, "Mercury"] _2015, based on more
Mercury (a specified in {Table I,
accurate information in
planet). "Mercury"}, with its
RIIC15.
associated accuracy as
specified in {Section 2,
paragraph 5}.
© ISO/IEC 2025 – All rights reserved
ORM Published Reference Binding RD
ORM label Region ORMT label References Notes
code name ORM information parameterization
The x-positive xz-half-
plane as determined by an
observable fixed surface
This is the Superseded by
feature and approximated
reference Pluto, [RIIC, Table PLUTO_2017, based on
PLUTO_1994 187 Pluto by an ephemeris as SPHERE PLUTO_1994
ORM for Pluto Global I, "Pluto"] more accurate
specified in {Table I,
(a planet). information in RIIC15.
"Pluto"}, with its
associated accuracy as
specified in {Section 2,
paragraph 5}.
Table J.13 — Deprecated object-fixed planet (non-Earth) RTs
Date
RT
ORM label RT label RT region STT label and parameter values publi References Notes
code
shed
Superseded by EROS_2002-
IDENTITY [RIIC, Table
EROS_2000 EROS_2000_IDENTITY 74 Global (Eros) 2000 _IDENTITY, based on more accurate
The reference ORM for object Eros. III, "Eros"]
information in RIIC15.
IDENTITY Superseded by JUPITER_2006-
JUPITER_1988- Global [RIIC, Table
JUPITER_1988 148 The reference ORM for object 1988 _IDENTITY, based on more accurate
_IDENTITY (Jupiter) I, "Jupiter"]
Jupiter. information in RIIC15.
Superseded by MERCURY_2015-
_IDENTITY and MERCURY-
MERCURY- MERCURY_1988- Global [RIIC, Table
170 IDENTITY 1988 _SPHERE_2015_IDENTITY, based
_1988 _IDENTITY (Mercury) I, "Mercury"]
on more accurate information in
RIIC15.
© ISO/IEC 2025 – All rights reserved
Date
RT
ORM label RT label RT region STT label and parameter values publi References Notes
code
shed
Superseded by PLUTO_2017-
[RIIC, Table
PLUTO_1994 PLUTO_1994_IDENTITY 249 Global (Pluto) IDENTITY 1994 _IDENTITY, based on more accurate
I, "Pluto"]
information in RIIC15.
© ISO/IEC 2025 – All rights reserved
ISO/IEC 18026:2023(E)
Table J.14 — Deprecated dynamic planet (non-Earth) ORMs
In this document, no dynamic planet (non-Earth) ORMs are deprecated, therefore the table is empty.
Table J.15 — Deprecated time-fixed instances of dynamic planet (non-Earth) OR
...

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.7.8 SRF_Code
The selection data type SRF_Code specifies an SRF by its code as defined in Table 8.31 or by registration.
Each SRF specification includes a code value and a corresponding label (see Clause 8).

11.2.7.9 SRFS_Code
The selection data type SRFS_Code specifies an SRF set by its code as listed in Table 8.48 or by registration.
Each SRF set specification includes a code value and a corresponding label (see Clause 8).
11.2.7.10 SRFS member types
11.2.7.10.1 Overview
The selection data types that specify the SRF set members associated with each of the SRF sets listed in Table
8.48.
11.2.7.10.2 Alabama_SPCS_Code
The selection data type Alabama_SPCS_Code specifies a member of the Alabama SPCS SRF set in Table
8.50 or by registration.
11.2.7.10.3 GTRS_Global_Coordinate_System_Code
The selection data type GTRS_Global_Coordinate_System_Code specifies a member of the GTRS Global
Coordinate System SRF set in Table 8.52 and Table 8.53 or by registration.
307 © ISO/IEC 2025 – All rights reserved

11.2.7.10.4 Japan_Rectangular_Plane_CS_Code
The selection data type Japan_Rectangular_Plane_CS_Code specifies a member of the Japan
Rectangular Plane CS SRF set in Table 8.55 or by registration.
11.2.7.10.5 Lambert_NTF_Code
The selection data type Lambert_NTF_Code specifies a member of the Lambert NTF SRF set in Table 8.57
or by registration.
11.2.7.10.6 Universal_Polar_Stereographic_Code
The selection data type Universal_Polar_Stereographic_Code specifies a member of the Universal
Polar Stereographic SRF set in Table 8.59 or by registration.
11.2.7.10.7 Universal_Transverse_Mercator_Code
The selection data type Universal_Transverse_Mercator_Code specifies a member of the Universal
Transverse Mercator SRF set in Table 8.61 or by registration.
11.2.7.10.8 Wisconsin_SPCS_Code
The selection data type Wisconsin_SPCS_Code specifies a member of the Wisconsin SPCS SRF set in Table
8.63 or by registration.
11.2.7.11 SRFT_Code
The selection data type SRFT_Code specifies an SRFT by its code as defined in Clause 8 or by registration.
Table 8.3 is a directory of SRFT specifications. Each SRFT specification includes a code value and a
corresponding label.
11.2.7.12 Status_Code
The Status_Code selection data type specifies the status codes associated with the execution of stand-alone
functions or class instance methods specified in this document.
This selection data type may be extended in language binding specifications. Values in the range 33-100 are
reserved for the future use of this API, while values greater than 100 are reserved for use by language bindings.
Status_Code ::= ( 0: UNSPECIFIED,
1: SUCCESS,
2: INVALID_SRF*,
3: INVALID_SOURCE_SRF,
4: INVALID_COORDINATE,
5: INVALID_SOURCE_COORDINATE,
6: INVALID_TARGET_COORDINATE,
7: INVALID_POINT1_COORDINATE,
8: INVALID_POINT2_COORDINATE,
9: OPERATION_UNSUPPORTED,
10: OPERATION_NOT_IMPLEMENTED,
11: INVALID_DIRECTION,
12: INVALID_SOURCE_DIRECTION,
13: INVALID_TARGET_DIRECTION,
14: INVALID_PRIMARY_AXIS_DIRECTION,
15: INVALID_SECONDARY_AXIS_DIRECTION,
308 © ISO/IEC 2025 – All rights reserved

16: INVALID_ORIENTATION,
17: INVALID_VECTOR,
18: INVALID_PARAMETERS,
19: INVALID_CODE,
20: UNDEFINED_CODE,
21: INCOMPATIBLE_CODE,
22: INVALID_INPUT,
23: INCOMPATIBLE_INPUTS,
24: DESTRUCTION_FAILURE,
25: FLOATING_OVERFLOW*,
26: FLOATING_UNDERFLOW*,
27: FLOATING_POINT_ERROR*,
28: MEMORY_ALLOCATION_ERROR*,
29: INVALID_ROTATION,
30: INVALID_SOURCE_VECTOR,
31: INVALID_TARGET_VECTOR,
32: OTHER_RUNTIME_ERROR* )
The values marked with an asterisk (“*”) refer to common error conditions that can occur during the execution
of most functions and methods, and therefore they are not included in the "Error conditions" element of individual
functions or methods. The meanings of the status codes are described in the following paragraphs, although
the meanings of the status codes may vary according to the function or method being specified (see 11.3.2).
SUCCESS indicates that the function or method was successfully executed.
INVALID_SRF indicates that the SRF instance invoking the method was not successfully created by the API or
is otherwise not a valid SRF instance. This condition does not apply to create methods.
INVALID_SOURCE_SRF indicates that the SRF instance passed to the method was not successfully created by
the API or is otherwise not a valid SRF instance.
INVALID_COORDINATE indicates that the coordinate passed to the function or method was either not
associated with the specified SRF or was not within the accuracy domain of the specified SRF.
INVALID_SOURCE_COORDINATE indicates that the coordinate passed to the function or method was either not
associated with the source SRF or was not within the accuracy domain of the source SRF.
INVALID_TARGET_COORDINATE indicates that the coordinate passed to or returned by the function or method
was either not associated with the target SRF or was not within the accuracy domain of the target SRF.
INVALID_POINT1_COORDINATE indicates that the first coordinate passed to the function or method was either
not associated with the specified SRF or was not within the accuracy domain of the specified SRF.
INVALID_POINT2_COORDINATE indicates that the second coordinate passed to the function or method was
either not associated with the specified SRF or was not within the accuracy domain of the specified SRF.
OPERATION_UNSUPPORTED indicates that the operation associated with the function or method cannot be
performed using the specified input parameters.
OPERATION_NOT_IMPLEMENTED indicates that the operation associated with the function or method has not
yet been implemented.
INVALID_DIRECTION indicates that the direction passed to the function or method was either not a valid
Direction instance, or that its reference coordinate was not associated with the specified SRF, or that its
reference coordinate was not within the accuracy domain of the specified SRF.
309 © ISO/IEC 2025 – All rights reserved

INVALID_SOURCE_DIRECTION indicates that the direction passed to the function or method was either not a
valid Direction instance, or that its reference coordinate was not associated with the source SRF, or that its
reference coordinate was not within the accuracy domain of the source SRF.
INVALID_TARGET_DIRECTION indicates that the direction passed to or returned by the function or method
was either not associated with the target SRF, or that its reference coordinate was not within the accuracy
domain of the target SRF.
INVALID_PRIMARY_AXIS_DIRECTION indicates that the primary axis direction passed to the function or
method was either not associated with the specified SRF, or that its reference coordinate was not within the
accuracy domain of the specified SRF.
INVALID_SECONDARY_AXIS_DIRECTION indicates that the secondary axis direction passed to the function
or method was either not associated with the specified SRF, or that its reference coordinate was not within the
accuracy domain of the specified SRF.
INVALID_ORIENTATION indicates that an orientation passed to the function or method was not a valid
Orientation instance.
INVALID_VECTOR indicates that a vector passed to the function or method was not a valid Vector_3D data
structure or Vector_Quantity3D class instance.
INVALID_PARAMETERS indicates that a parameter data structure is not a valid input to the function or method.
INVALID_CODE indicates that an input code value is not a valid input to the function or method.
UNDEFINED_CODE indicates that an input code value passed to the function or method is either not defined by
this document or is not defined by the implementation.
INCOMPATIBLE_CODE indicates that an input code value passed to the function or method is not compatible
with the other inputs to that function or method.
INVALID_INPUT indicates that an input parameter value cannot be used by the function or method.
INCOMPATIBLE_INPUTS indicates that two or more input values passed to the function or method are not
compatible with one another.
DESTRUCTION_FAILURE indicates that an error occurred during the destruction of an object instance.
FLOATING_OVERFLOW indicates that a floating-point overflow error occurred during the execution of the function
or method.
FLOATING_UNDERFLOW indicates that a floating-point underflow error occurred during the execution of the
function or method.
FLOATING_POINT_ERROR indicates that a Long_Float input is positive or negative infinity, or a not-a-number
(NAN) value, or that a floating-point error (other than an overflow or underflow error) occurred during the
execution of the function or method.
MEMORY_ALLOCATION_ERROR indicates that a memory allocation error occurred during the execution of the
function or method.
INVALID_ROTATION indicates that a rotation passed to the function or method was not a valid Rotation
instance.
310 © ISO/IEC 2025 – All rights reserved

INVALID_SOURCE_VECTOR indicates that the vector passed to the function or method was either not a valid
Vector_Quantity3D instance, or that its reference coordinate was not associated with the source SRF, or
that its reference coordinate was not within the accuracy domain of the source SRF.
INVALID_TARGET_VECTOR indicates that the vector passed to or returned by the function or method was
either not associated with the target SRF, or that its reference coordinate was not within the accuracy domain
of the target SRF.
OTHER_RUNTIME_ERROR indicates that some other kind of runtime error occurred during the execution of the
function or method.
11.2.7.13 STT_Code
The selection data type STT_Code specifies an STT by its code as defined in 7.3.3 or by registration. Each STT
specification includes a code value and a corresponding label.
11.2.8 Array data types
11.2.8.1 Overview
Array data types specify an ordered set whose elements are all of the same data type. Table 11.4 specifies the
notation for Array data types.
Table 11.4 — Array data type notation
Data type Notation
One-dimensional array
Data_Type_Name[ length ]
Two-dimensional array
Data_Type_Name[ rows, columns ]
The symbols “length”, "rows", and "columns" are positive integers. The length of a one-dimensional array is
specified by "length". The index of the first element in the one-dimensional array is either “0” or “1” depending
on the language binding. For two-dimensional arrays, "rows" and "columns" specify the number of rows and
columns of the array respectively. The ordering of the set is row-major. The indices of the first element in the
two-dimensional array are both either “0” or “1” depending on the language binding.
11.2.8.2 Coordinate2D_Array
This data type specifies an Object_Reference array referencing Coordinate2D instances. The length of
the array is given by the record element length.
Coordinate2D_Array ::= {
length Integer_Positive;
coordinate2D_array Object_Reference[ length ];
}
11.2.8.3 Coordinate3D_Array
This data type specifies an Object_Reference array referencing Coordinate3D instances. The length of
the array is given by the record element length.
Coordinate3D_Array ::= {
length Integer_Positive;
311 © ISO/IEC 2025 – All rights reserved

coordinate3D_array Object_Reference[ length ];
}
11.2.8.4 Direction_Array
This data type specifies an Object_Reference array referencing Direction instances. The length of the
array is given by the record element length.
Direction_Array ::= {
length Integer_Positive;
direction_array Object_Reference[ length ];
}
11.2.8.5 DSS_Code_Array
This data type specifies an array containing DSS_Code values. The length of the array is given by the record
element length.
DSS_Code_Array ::= {
length Integer_Unsigned;
dss_code_array DSS_Code [ length ];
}
11.2.8.6 Matrix_2x2
This data type specifies a two-dimensional square array of four Long_Float variables representing a 2x2
matrix.
Matrix_2x2 ::= Long_Float[ 2, 2 ]
11.2.8.7 Matrix_3x3
This data type specifies a two-dimensional square array of nine Long_Float variables representing a 3x3
matrix.
Matrix_3x3 ::= Long_Float[ 3, 3 ]
11.2.8.8 Matrix_4x4
This data type specifies a two-dimensional square array of sixteen Long_Float variables representing a 4x4
matrix.
Matrix_4x4 ::= Long_Float[ 4, 4 ]
11.2.8.9 ORM_Code_Array
This data type specifies an array containing ORM_Code values. The length of the array is given by the record
element length.
ORM_Code_Array ::= {
length Integer_Unsigned;
orm_code_array ORM_Code [ length ];
}
312 © ISO/IEC 2025 – All rights reserved

11.2.8.10 Profile_Code_Array
This data type specifies an array containing Profile_Code values. The length of the array is given by the
record element length.
Profile_Code_Array ::= {
length Integer_Unsigned;
profile_code_array Profile_Code [ length ];
}
11.2.8.11 RT_Code_Array
This data type specifies an array containing RT_Code values. The length of the array is given by the record
element length.
RT_Code_Array ::= {
length Integer_Unsigned;
rt_code_array RT_Code [ length ];
}
11.2.8.12 SRF_Code_Array
This data type specifies an array containing SRF_Code values. The length of the array is given by the record
element length.
SRF_Code_Array ::= {
length Integer_Unsigned;
srf_code_array SRF_Code [ length ];
}
11.2.8.13 SRF_Region_Status_Array
This data type specifies an array containing SRF_Region_Status values. The length of the array is given by
the record element length.
SRF_Region_Status_Array ::= {
length Integer_Positive;
status_array SRF_Region_Status[ length ];
}
11.2.8.14 SRFS_Code_Array
This data type specifies an array containing SRFS_Code values. The length of the array is given by the record
element length.
SRFS_Code_Array ::= {
length Integer_Unsigned;
srfs_code_array SRFS_Code [ length ];
}
11.2.8.15 SRFT_Code_Array
This data type specifies an array containing SRFT_Code values. The length of the array is given by the record
element length.
313 © ISO/IEC 2025 – All rights reserved

SRFT_Code_Array ::= {
length Integer_Unsigned;
srft_code_array SRFT_Code [ length ];
}
11.2.8.16 VectorQuantity3D_Array
This data type specifies an Object_Reference array referencing VectorQuantity3D instances. The length
of the array is given by the record element length.
VectorQuantity3D_Array ::= {
length Integer_Positive;
vector_array Object_Reference[ length ];
}
11.2.8.17 Vector_3D
This data type specifies an array of three Long_Float variables representing a vector in 3D Euclidean space.
This data type is not inherently associated with any specific ORM or SRF embedded frame.
Vector_3D ::= Long_Float[ 3 ]
Vector_3D is used for:
• specifying the axis in Axis_Angle_Parameters (see 11.2.9.4.1)
• specifying a position-vector or direction that is not (yet) tied to a specific SRF in LCE_3D_Parameters
(see 11.2.9.5.3)
• input and output parameters in methods of the BaseSRF3D, Rotation and Orientation classes (see
11.3.5.3, 11.3.9.2, and 11.3.9.3)
11.2.9 Record data types
11.2.9.1 Overview
Data types that encompass a variety of information are termed record data types. A record data type consists
of a sequence of data types that together form one record of data. Each entry of a record data type may be of
any data type defined in this API, including other record data types.
The elements of record data types that represent lengths shall be evaluated as metres, and the elements that
represent angles shall be evaluated as radians.
The following notation is used for defining non-variant record data types:
::=
{
  
  
…
}
where:
: The non-variant record data type that is being defined.
: The name of a record element.
: The data type of a record element. Data type “” indicates no data
is present for the element and the data type is left to the language binding.
314 © ISO/IEC 2025 – All rights reserved

{}: The body of the non-variant record.
The following notation is used for defining the variant record data types:
::= (    )
{
  
  
…
[
:    ;
:    ;
…
]
}
where:
: The name of the selector
: The selection data type used to select the content of the variant record.
: The name of a record element.
: The data type of a record element. Data type “” indicates no data is
present for the element and the data type is left to the language binding.
: A selection data type value for which a record element applies.
{}: The body of the variant record.
[]: The variant part of the variant record that shall follow all non-varying record
elements.
11.2.9.2 Interval
This record data type specifies a coordinate-component interval, consisting of an interval type, a lower bound,
and an upper bound. For non-angular intervals, the value of lower_bound shall be less than the value of
upper_bound. For angular intervals, the absolute value of the difference between the bounds shall be less
than or equal to 2�. For angular intervals, if the value of lower_bound is greater than the value of
upper_bound, the effective interval is understood to span from the specified value of lower_bound to the
specified value of upper_bound plus 2�.
The value of lower_bound is ignored if interval_type is a semi-interval LT_SEMI_INTERVAL, or
LE_SEMI_INTERVAL, or UNBOUNDED.
The value of upper_bound is ignored if interval_type is a semi-interval GT_SEMI_INTERVAL, or
GE_SEMI_INTERVAL, or UNBOUNDED.
Interval ::= {
interval_type Interval_Type;
lower_bound Long_Float;
upper_bound Long_Float;
}
315 © ISO/IEC 2025 – All rights reserved

11.2.9.3 ORM_Transformation_Parameters
This variant record data type represents a set of 2D or 3D ORM transformation parameters.
ORM_Transformation_Parameters ::= { template_code STT_Code }
{
[
IDENTITY:
identity_parameters ;
IDENTITY_2D:
identity_2d_parameters ;
TRANSLATE:
translate_parameters Translate_3D_Parameters;
TRANSLATE_2D:
translate_2d_parameters Translate_2D_Parameters;
PV_7_PARAMETER:
pv_7_parameters Rotate_Scale_Translate_3D_Parameters;
CF_7_PARAMETER:
cf_7_parameters Rotate_Scale_Translate_3D_Parameters;
CF_7_PLUS_3_PARAMETER:
cf_7_plus_3_parameters Molodensky_Badekas_3D_Parameters;
ROTATE_SCALE_TRANSLATE:
rotate_scale_translate_parameters Similarity_3D_Parameters;
ROTATE_SCALE_TRANSLATE_2D:
rotate_scale_translate_2d_parameters Similarity_2D_Parameters;
HOMOGENEOUS_MATRIX_4X4:
homogeneous_matrix_4x4_parameters Homogeneous_3D_Parameters;
HOMOGENEOUS_MATRIX_3X3_2D:
homogeneous_matrix_3x3_2d_parameters Homogeneous_2D_Parameters;
PV_XYZ_ROTATE_SCALE_TRANSLATE:
pv_xyz_rotate_translate_parameters Rotate_Scale_Translate_3D_Parameters;
CF_ZYX_ROTATE_SCALE_TRANSLATE:
cf_zyx_rotate_scale_translate_parameters
Rotate_Scale_Translate_3D_Parameters;
TAIT_BRYAN_ZYX:
tait_bryan_zyx_parameters Rotate_Translate_3D_Parameters;
PV_Z_ROTATE_TRANSLATE:
pv_z_rotate_translate_parameters Z_Rotate_Translate_3D_Parameters;
PV_ZY_ROTATE:
pv_zy_rotate_parameters ZY_Rotate_3D_Parameters;
]
}
11.2.9.4 Rotation and Orientation representation parameters
11.2.9.4.1 Axis_Angle_Parameters
This record data type specifies the rotation and orientation representation parameters specified in 6.6.2. The
rotation angle is given in radians.
Axis_Angle_Parameters ::= {
axis Vector_3D;
angle Long_Float;
}
The value of axis represents the axis of rotation as a unit vector. The value of angle represents the rotation
angle in radians. The valid range for values of angle is (−2
, 2
).
316 © ISO/IEC 2025 – All rights reserved

11.2.9.4.2 Euler_Angles_ZXZ_Parameters
This record data type specifies the rotation and orientation representation specified in 6.6.4.3. It consists of
three rotation angles in radians.
Euler_Angles_ZXZ_Parameters ::= {
spin Long_Float;
nutation Long_Float;
precession Long_Float;
}
The values of spin, nutation, and precession represent consecutive principal rotations in radians about
the z–axis, the x–axis and the z–axis again. The valid range for values of spin, nutation, and precession
is (−2
, 2
).
11.2.9.4.3 Quaternion_Parameters
This record data type specifies the rotation and orientation representation specified in 6.6.5.1. It consists of a 4-
tuple of numbers, the scalar part and the three vector parts. The parameter values shall meet the constraint:
� � � �
� + � + � + � = 1.
� � � �
Quaternion_Parameters ::= {
e0 Long_Float;
e1 Long_Float;
e2 Long_Float;
e3 Long_Float;
}
11.2.9.4.4 Tait_Bryan_Angles_Parameters
This record data type specifies the rotation and orientation representation specified in 6.6.4.4. It consists of
three rotation angles in radians.
Tait_Bryan_Angles_Parameters ::= {
roll Long_Float;
pitch Long_Float;
yaw Long_Float;
}
The values of roll, pitch, and yaw represent consecutive principal rotations in radians about the x–axis, the
y–axis and the z–axis. The valid range for values of roll, pitch, and yaw is (−2
, 2
).
11.2.9.5 SRFT parameter record data types
11.2.9.5.1 EC_Parameters
This record data type specifies the parameters that correspond to SRFT EQUIDISTANT_CYLINDRICAL (see
Table 8.26)
EC_Parameters ::= {
origin_longitude Long_Float;
central_scale Long_Float;
false_easting Long_Float;
false_northing Long_Float;
}
317 © ISO/IEC 2025 – All rights reserved

11.2.9.5.2 LCC_Parameters
This record data type specifies the parameters that correspond to SRFT LAMBERT_CONFORMAL_CONIC
(see Table 8.24)
LCC_Parameters ::= {
origin_longitude Long_Float;
origin_latitude Long_Float;
standard_latitude1 Long_Float;
standard_latitude2 Long_Float;
false_easting Long_Float;
false_northing Long_Float;
}
11.2.9.5.3 LCE_3D_Parameters
This record data type specifies the parameters that correspond to SRFT LOCOCENTRIC_EUCLIDEAN_3D
(see Table 8.11). These localization parameters specify the localized frame associated with the instance of the
SRFT and represent vector components expressed in the embedded frame of its ORM. The lococentre (�) is
the spatial position of the origin of the localized frame. The primary and secondary axis directions (� and �)
define the orientation of the axes of the localized frame.
LCE_3D_Parameters ::= {
lococentre Vector_3D;
primary_axis Vector_3D;
secondary_axis Vector_3D;
}
11.2.9.5.4 LSR_2D_Parameters
This record data type specifies the parameters that correspond to SRFT LOCAL_SPACE_RECTANGULAR_2D
(see Table 8.27), as well as SRFT LOCAL_SPACE_AZIMUTHAL_2D (see Table 8.28) and SRFT
LOCAL_SPACE_POLAR_2D (see Table 8.29).
LSR_2D_Parameters ::= {
primary_direction Axis_Direction_2D;
}
11.2.9.5.5 LSR_3D_Parameters
This record data type specifies the parameters that correspond to SRFT LOCAL_SPACE_RECTANGULAR_3D
(see Table 8.5).
LSR_3D_Parameters ::= {
primary_direction Axis_Direction_3D;
secondary_direction Axis_Direction_3D;
}
318 © ISO/IEC 2025 – All rights reserved

11.2.9.5.6 LTS_Parameters
This record data type specifies the parameters that correspond to SRFT
LOCAL_TANGENT_SPACE_AZIMUTHAL_SPHERICAL (see Table 8.9) and SRFT
LOCAL_TANGENT_SPACE_CYLINDRICAL. (see Table 8.10)
LTS_Parameters ::={
geodetic_longitude Long_Float;
geodetic_latitude Long_Float;
azimuth Long_Float;
height_offset Long_Float;
}
11.2.9.5.7 LTSE_Parameters
This record data type specifies the parameters that correspond to SRFT
LOCAL_TANGENT_SPACE_EUCLIDEAN (see Table 8.8)
LTSE_Parameters ::={
geodetic_longitude Long_Float;
geodetic_latitude Long_Float;
azimuth Long_Float;
x_origin_shift Long_Float;
y_origin_shift Long_Float;
height_offset Long_Float;
}
11.2.9.5.8 Mercator_Parameters
This record data type specifies the parameters that correspond to SRFT MERCATOR (see Table 8.21)
Mercator_Parameters ::= {
origin_longitude Long_Float;
central_scale Long_Float;
false_easting Long_Float;
false_northing Long_Float;
}
11.2.9.5.9 Oblique_Mercator_Parameters
This record data type specifies the parameters that correspond to SRFT OBLIQUE_MERCATOR_SPHERICAL
(see Table 8.22)
Oblique_Mercator_Parameters ::= {
longitude1 Long_Float;
latitude1 Long_Float;
longitude2 Long_Float;
latitude2 Long_Float;
central_scale Long_Float;
false_easting Long_Float;
false_northing Long_Float;
}
319 © ISO/IEC 2025 – All rights reserved

11.2.9.5.10 PS_Parameters
This record data type specifies the parameters that correspond to SRFT POLAR_STEREOGRAPHIC (see Table
8.25)
PS_Parameters ::= {
polar_aspect Polar_Aspect;
origin_longitude Long_Float;
central_scale Long_Float;
false_easting Long_Float;
alse_northing Long_Float;
}
11.2.9.5.11 SRFS_Code_Info
This variant record data type specifies an arbitrary SRFS_Code with its associated SRF set member code.
SRFS_Code_Info ::= ( srfs_code  SRFS_Code )
{
[
UNSPECIFIED:
unspecified ;
ALABAMA_SPCS:
alabama_spcs Alabama_SPCS_Code;
GTRS_GLOBAL_COORDINATE_SYSTEM:
gtrs_global_coordinate_system GTRS_Global_Coordinate_System_Code;
JAPAN_RECTANGULAR_PLANE_CS:
japan_rectangular_plane_cs Japan_Rectangular_Plane_CS_Code;
LAMBERT_NTF:
lambert_ntf Lambert_NTF_Code;
UNIVERSAL_POLAR_STEREOGRAPHIC:
universal_polar_stereographic Universal_Polar_Stereographic_Code;
UNIVERSAL_TRANSVERSE_MERCATOR:
universal_transverse_mercator Universal_Transverse_Mercator_Code;
WISCONSIN_SPCS:
wisconsin_spcs Wisconsin_SPCS_Code;
]
}
11.2.9.5.12 TM_Parameters
This record data type specifies the parameters that correspond to SRFT TRANSVERSE_MERCATOR (see
Table 8.23)
TM_Parameters ::= {
origin_longitude Long_Float;
origin_latitude Long_Float;
central_scale Long_Float;
false_easting Long_Float;
false_northing Long_Float;
}
320 © ISO/IEC 2025 – All rights reserved

11.2.9.6 STT parameter record data types
11.2.9.6.1 Homogeneous_2D_Parameters
This record data type represents the parameters of a 2D homogeneous transformation, consisting of the three
origin displacement components and a scaled rotation submatrix, as specified in Table 7.23.
Homogeneous_2D_Parameters ::= {
delta_x Long_Float;
delta_y Long_Float;
scaled_rotation Matrix_2x2;
}
The values of delta_x and delta_y represent the origin displacement in metres.
The value of scaled_rotation represents the scaled rotation submatrix. Therefore, its determinant shall be
greater than zero, and its inverse shall equal its transpose divided by the square of its determinant.
11.2.9.6.2 Homogeneous_3D_Parameters
This record data type represents the parameters of a 3D homogeneous transformation, consisting of the three
origin displacement components and a scaled rotation submatrix, as specified in Table 7.22.
Homogeneous_3D_Parameters ::= {
delta_x Long_Float;
delta_y Long_Float;
delta_z Long_Float;
scaled_rotation Matrix_3x3;
}
The values of delta_x, delta_y, and delta_z represent the origin displacement in metres.
The value of scaled_rotation represents the scaled rotation submatrix. Therefore, its determinant shall be
greater than zero, and its inverse shall equal its transpose divided by the square of its determinant.
11.2.9.6.3 Molodensky_Badekas_3D_Parameters
This record data type represents the parameters of a Molodensky-Badekas 3D transformation as specified in
Table 7.19.
Molodensky_Badekas_3D_Parameters ::= {
delta_x Long_Float;
delta_y Long_Float;
delta_z Long_Float;
omega_1 Long_Float;
omega_2 Long_Float;
omega_3 Long_Float;
delta_scale Long_Float;
x_0 Long_Float;
y_0 Long_Float;
z_0 Long_Float;
}
The values of delta_x, delta_y, and delta_z represent the origin displacement in metres.
321 © ISO/IEC 2025 – All rights reserved

The values of omega_1, omega_2, and omega_3 represent rotations in radians about the x-, y-, and z-axes. In
general, the valid range for values of omega_1, omega_2, and omega_3 is (−2
, 2
). See the STT specification
for addi
...

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, fixing the ellipsoidal height
coordinate-component (ℎ) of a 3D geodetic coordinate system to zero results in an induced surface geodetic
coordinate system that represents positions on the surface of the ellipsoid modelling the Earth. This document
provides functions for creating coordinate-component surfaces and curves and specifies several standard
induced surface coordinate systems.
The two coordinate-component curves at a point on a curvilinear surface, such as an ellipsoid-based model of
the Earth, can be used to define a plane that is tangent to the curves at the point. This tangent plane can be
used to define a localized 2D or 3D coordinate system. These localized coordinate systems are used in
modelling the position and orientation of objects, such as vehicles and sensors, located on or near the Earth or
other celestial bodies. Such localized coordinate systems also provide Euclidean vector spaces for denoting
directions in curvilinear coordinate systems.
Maps are traditionally created by functionally projecting a region of the surface of an oblate ellipsoid (or sphere)
onto a flat 2D surface for presentation and other user purposes. These and similar functions are termed mapping
equations and are defined in terms of surface geodetic coordinates on the ellipsoid. When inverse mapping
equations are composed with the generating function of the surface geodetic coordinate system, the resulting
function is the generating function for a surface coordinate system. In this way, coordinate systems based on
traditional map projections may be treated as a special case of abstract coordinate systems of coordinate
system type surface. This special case is termed a map projection coordinate system.
NOTE In other contexts, map projection coordinate systems are sometimes described as rectilinear or Cartesian
because of the vector space structure of coordinate-space. That description does not imply that a map projection coordinate
system is a linear coordinate system. Map projection coordinate systems are not linear because the associated generating
functions are not affine. With respect to a linear coordinate system for the same position-space, map projection coordinate
systems exhibit various types of distortion (see 5.3.7.3). In applications the effect of distortion is often mitigated by restricting
the coordinate system domain of the map projection to a smaller sub-set.
Abstract coordinate systems are addressed in greater detail in 5.3. This document specifies a standardized set
of abstract coordinate systems (see 5.3.8).
18 © ISO/IEC 2025 – All rights reserved

4.3.2 Spatial coordinate systems
A spatial coordinate system assigns a unique coordinate to each point in a region of object-space. Abstract
coordinate systems are defined (see 4.3.1) for position-space. Position-space can serve as a model of an object-
space by specifying a normal embedding that maps the position-space orthonormal frame to a corresponding
orthonormal frame embedded in object-space. Using this concept, 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 � = � ∘ � � .
Figure 4.6 illustrates a spatial surface coordinate system bound with a normal embedding of 3D position-space
( )
to the 3D object-space. In this illustration, a surface coordinate �, � in coordinate-space is associated to a
position vector (�, �, �) in position-space. That position then identifies a location in the space of an object via the
normal embedding of position-space. In this example, the normal embedding is determined by the selection of
an origin and three unit points.

Figure 4.6 — A normal embedding of an abstract coordinate system
In applications where a one spatial coordinate system is defined in terms of another spatial coordinate system,
the relationships between them build upon the corresponding relationships between their respective abstract
coordinate systems (see 4.3.1).
The details of spatial coordinate systems are addressed in 5.4.
4.3.3 Temporal coordinate systems
A temporal coordinate system is a realisation of an abstract Euclidean 1D coordinate system that assigns a one-
to-one monotonically increasing relationship between temporal coordinate values and instants in time, such that
larger coordinate values are assigned to later instants in time. A temporal coordinate system is used to associate
a unique instant in time with an event or reference.
There is a requirement to identify time as well as position in environmental representation. Time and position
are often used together by an application to describe when a given condition exists or when an object was
present at a given location. Furthermore, in dynamic physical systems, the normal embedding that maps
position-space to an object-space may change over time. As a result, the relationship between coordinates and
positions is time-dependent. In such systems, time and time differences have to be considered in order to
accurately determine positions and position differences.
This document uses the concept of time in several ways. An object reference model (see 4.6) has either a static
or dynamic binding to a spatial object. In the latter case, time is a parameter of the reference transformation that
© ISO/IEC 2025 – All rights reserved 19

specifies the binding (see 7.5). Spatial reference frames (see 4.7) that are based on dynamic object reference
models also depend on a time parameter. However, these dynamic cases reduce to the corresponding static
cases by fixing a value for the time parameter.
Time is also a factor for static object reference model bindings that are based on physical measurements of
objects or systems that change with time. Time is used to identify the epoch for which these measurements are
applicable.
The details of temporal coordinate systems are specified in 5.5.
4.4 Orientation
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 a reference frame. Orientation
can be specified in terms of either: 1) a change of basis operation that would convert a coordinate from the
object's frame to the reference frame (see 6.2), or 2) a rotation operation that would move the object’s frame
away from alignment with the reference frame (see 6.4).
Several representations of orientation and rotations are in wide use in different application domains. Consistent
definitions of orientations and rotations are required to support interoperability of systems and applications. This
document supports several common representations of orientations and rotations (see 6.6), as well as inter-
conversion operations between these representations (see 6.7). The supported representations defined include:
a) 3x3 matrix,
b) axis-angle,
c) Euler angles, including proper Euler angles and Tait-Bryan angles, and
d) quaternions.
4.5 Reference datums
A reference datum is a geometric primitive in position-space. In 2D position-space, reference datums are points
or directed curves. In 3D position-space, reference datums are points, directed curves, or oriented surfaces.
Oblate ellipsoid surfaces are commonly used to model the Earth and other celestial bodies.
EXAMPLE 1 An ellipsoid reference da
...

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 with respect to a
second embedded frame within the same object-space. A similarity transformation consists of a translation, a
rotation, and/or a scaling operation. If � and � are two normal embeddings, there exists a similarity
� �
transformation � such that � is the composition of � with � , i.e., � � � ∘ � . This is depicted
��←�� � � ��←�� � ��←�� �
� � � �
in Figure 5.6, where a point � in object-space will have vector coordinates � , � , � and � , � , � in the
� � � �� � � � ��
� and � embedded frames respectively. The similarity transformation � , operating on object-space, that

� � ��←��
will translate � ��� to � ��� and align the � basis axes with � basis axes will also perform a change of basis
� � � �
operation: �� , � , � � � ���� , � , � � �. Thus, similarity transformations can be used in the transformation of
� � � �� � � � ��
coordinates between orthonormal frames. Similarity transformations are addressed in greater detail in 7.3.2.
The method of specifying a normal embedding varies across disciplines and application domains. In some
application domains, a normal embedding is implicitly defined by the specification of the origin point and axis
directions. In the case of geodesy, an origin point at the centre of the Earth cannot be directly specified. Instead,
its location is implied by specifying other geometric entities from physical measurements. An object reference
model (see 7.4) implicitly identifies a unique normal embedding in this manner. Other disciplines use a variety
of techniques to either implicitly or explicitly define a normal embedding. This document encapsulates these
techniques within the concepts of reference datum and object reference model.
36 © ISO/IEC 2025 – All rights reserved

5.3 Abstract coordinate systems
5.3.1 Overview
An abstract coordinate system assigns a unique coordinate �-tuple to each point in a range of position vectors
in an �-dimensional Euclidean vector space �1 ≤ � ≤ � ≤ 3� termed position-space, which has a canonical
basis that defines an orthonormal frame. The assignment function is termed the generating function of the
abstract coordinate system. The range may encompass the entire vector space or a proper sub-set, such as a
surface or a curve.
Abstract coordinate systems are formally defined in 5.3.2. Abstract coordinate systems are characterized by
type (5.3.3) and properties (5.3.5). In addition, abstract coordinate systems for 3D position-space generate
coordinate-component surfaces (5.3.4). Localization operators modify abstract coordinate systems by shifting
the vector space origin and changing axis directions (5.3.6). Map projections and augmented map projections
are treated as a special case of abstract coordinate systems and have additional classifications and properties,
as well as several functions unique to map projections (5.3.7). The elements for the specification of an abstract
coordinate system, along with standardized abstract coordinate systems, are specified in 5.3.8. In this document
the term “coordinate system (CS)”, if not otherwise qualified, is defined to mean “abstract CS.”
This document takes a functional approach to the construction of coordinate systems. Annex A provides a
concise summary of mathematical concepts and specifies the notational conventions used in this document. In
particular, Annex A defines the terms interior, one-to-one, smooth, smooth surface, smooth curve, orientation-
preserving, and connected. Additionally, a newly introduced concept, replete, will be used. A set � is replete if
all points in � belong to the closure of the interior of � (see Annex A). A replete set is a generalization of an
open set that allows the inclusion of boundary points. Boundary points are important in the definitions of certain
coordinate systems.
5.3.2 Definition
An abstract coordinate system (CS) assigns a unique coordinate to each point in a subset of position-space
(5.2.3). An abstract Coordinate System shall be comprised of:
a) a CS domain in �-dimensional coordinate-space, (1 ≤ � ≤ 3),
b) a generating function, and
c) a CS range in �-dimensional position-space, (� ≤ � ≤ 3),
where:
a) The CS domain shall be a connected replete domain in �-dimensional coordinate-space, the space of
�-tuples. The elements of the CS domain are coordinates.
b) The generating function assigns each coordinate to a point in position-space. It shall be a one-to-one,
smooth function (see A.4) from the CS domain onto the generating function range.
c) The generating function range shall be termed the CS range. When � � 2 and � � 3, the CS range
shall be a subset of a smooth surface . When � � 1 and � � 2 or � � 3, the CS range shall be a subset
of an implicitly specified smooth curve . The elements of the CS range are positions.

The generating function properties and the implicit function theorem together imply that for each point in the interior of the
CS domain, there is an open neighbourhood of the point whose image under the generating function lies in a smooth surface.
This requirement specifies that there exists one smooth surface for all of the points in the CS domain. This requirement is
specified to exclude mathematically pathological cases.
The generating function properties and the implicit function theorem together imply that for each point in the interior of the
CS domain, there is an open neighbourhood of the point whose image under the generating function lies in a smooth curve.
This requirement specifies that there exists one implicitly-defined smooth curve for all the points in the CS domain. This
requirement is specified to exclude mathematically pathological cases.
© ISO/IEC 2025 – All rights reserved 37

The coordinate of a position � shall be the unique coordinate whose generating function value is �.
The generating function may be parameterized. The generating function parameters (if any) shall be termed the
CS parameters.
The inverse of the generating function shall be termed the inverse generating function. The inverse generating
function is one-to-one and is smooth in the interior of the CS domain, except at points in the image of the CS
domain boundary points where it may be discontinuous.

Figure 5.7 — Abstract equatorial spherical coordinate system example
Figure 5.7 illustrates the components of the Equatorial Spherical abstract coordinate system.
NOTE The generating function of a CS is often specified by an algebraic and/or trigonometric description of a geometric
relationship (see 5.3.3 Example 2). There are also CSs that do not have geometric derivations. The Mercator map projection
(see Table 5.18) is specified to satisfy a functional requirement of conformality (see 5.3.7.3.2) rather than by a geometric
construction.
5.3.3 Coordinate system types
The coordinate-space and position-space dimensions characterize an abstract CS by CS type as defined in
Table 5.1.
Table 5.1 — Coordinate system types
Dimension of Dimension of
CS type
coordinate-space position-space
3D 3 3
surface 2 3
1 3
curve
2D 2 2
1 2
plane curve
The ISO 19111 concept of a linear coordinate system, defined as “a one-dimensional coordinate system in which a linear
feature forms the axis”, is similar in some respects to the curve CS and plane curve CS concepts. This ISO 19111 concept
is distinct from the linearity property of abstract coordinate systems (see 5.3.5.1).
38 © ISO/IEC 2025 – All rights reserved

Dimension of Dimension of
CS type
coordinate-space position-space
1D 1 1
For brevity, a CS may be referred to by its CS type as a 3D CS, surface CS, curve CS, 2D CS, plane curve CS,
or 1D CS.
EXAMPLE 1 The identity function on 3D Euclidean space is the generating function of the Euclidean 3D coordinate
system. Both the coordinate system domain and range sets are the entire Euclidean space. In this case, coordinate-space
and position-space are one and the same. The Euclidean 3D coordinate system (see 5.3.8.2) is a linear coordinate system.
EXAMPLE 2 The polar coordinate system is an example of an abstract coordinate system of coordinate system type 2D
that is defined with the generating function:
�
����,  ��� � ��, ��
where:
� � � cos��� , � � � sin���.
Figure 5.8 — Polar CS geometry
The geometric and trigonometric relationships for this generating function are illustrated in Figure 5.8
�
�� � | � �� ��
The CS domain in coordinate-space is �,  � �� ℝ 0 � �, 0 ≤ � � 2� ∪ 0,0 .
�
The CS range in position-space is ℝ .

Figure 5.9 — The Polar CS generating function
This generating function, �, is illustrated in Figure 5.9. The grey boxes with faded edges in this figure represent the fact that
the range in position-space extends indefinitely, and that the domain in coordinate-space extends indefinitely in the direction
of the �-axis. The lighter grey edges indicate open boundaries, and the darker grey edge is a closed boundary. This CS
range, CS domain, and generating function define an abstract CS representing polar coordinates as defined in mathematics
[EDM, “Coordinates”]. This coordinate system is fully specified in 5.3.8.27 as the Polar coordinate system.
© ISO/IEC 2025 – All rights reserved 39

�
NOTE  In the special case where 1) the CS domain and CS range are both ℝ and 2) the function is the identity function,
�
this approach to defining coordinate systems reduces to the usual definition of the Euclidean coordinate system on ℝ where
each point is identified by an �-tuple of real numbers [EDM] (see Table 5.8, Table 5.29 and Table 5.35).

Figure 5.10 — The geodetic coordinate system geometric and trigonometric relationships
EXAMPLE 3 The geodetic coordinate system for positions in the space containing an oblate ellipsoid is an example of
a coordinate system of coordinate system type 3D. The geometric and trigonometric relationships for the generating function
of this coordinate system are illustrated in Figure 5.10. The coordinate system parameters are the major and minor semi-
axis values � and �. This coordinate system is fully specified in 5.3.8.8 as the Geodetic 3D coordinate system.

Figure 5.11 — Surface geodetic CS geometric and trigonometric relationships
40 © ISO/IEC 2025 – All rights reserved

EXAMPLE 4 The geodetic coordinate system for positions on the surface of an oblate ellipsoid is an example of a
coordinate system of coordinate system type surface. The geometric and trigonometric relationships for the generating
function of this coordinate system are illustrated in Figure 5.11. The generating function for this coordinate system depends
on the major and minor semi-axis parameter values � and �. These are the coordinate system parameters. This coordinate
system is fully specified in 5.3.8.18 as the Surface Geodetic coordinate system.
5.3.4 Coordinate-component surfaces and curves
5.3.4.1 Overview
It is 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, fixing the ellipsoidal height coordinate-
component (ℎ) of a 3D geodetic coordinate system to zero results in an induced surface geodetic coordinate
system that represents positions on the surface of the ellipsoid modelling the Earth (see Figure 5.11). This
Document provides functions for creating coordinate-component surfaces and curves, and specifies several
standard induced surface coordinate systems.
The generating function of a 3D CS is a function of its three coordinate-components. Keeping one of the
coordinate-components fixed (to a constant value) and varying the other two restricts the range of the
generating function to a surface. This restricted generating function may be viewed as a surface CS
generating function. Similarly, keeping two of the three coordinate-components fixed restricts the range of the
generating function to a curve, and the restricted generating function may be viewed as a curve CS generating
function. These observations motivate the definitions of coordinate-component surfaces and curves. The
coordinate-component surface and coordinate-component curve concepts are required to specify induced CS
relationships, to define the special coordinate curves parallel and meridian, and to define CS handedness.
Coordinate-component curves are also used to define localized frames.
5.3.4.2 Coordinate-component surfaces and induced surface CSs
A coordinate-component surface is the surface that results from fixing the value of one of the three coordinate-
components of a 3D CS while letting the values of the other two coordinate-components vary. A coordinate-
st nd rd
component surface is identified by the ordinal number (1 , 2 , or 3 ) of the coordinate-component that is fixed.
If � is the generating function of a 3D CS, and � � �� , � , � � is in the interior of the CS domain �, the three
� � �
coordinate-component surfaces at � are defined by:
� � � � � �
� � � �,  � � � �� � , �, � �,
� �
� � � � � �
� � � �,  � � � �� �, � , � �, and
� �
� ������,  �� � � ����, �, � ��.
� �
The CS domain for � ��� is the connected component of ���,  �� in ℝ � �� , �, �� in �� which contains � � , � � .
� � �
� � � � � �
The CS domain for � � is the connected component of � �,  � in ℝ � ��, � , �� in �� which contains � , � .
� 0 � �
� � � � � �
The CS domain for � � is the connected component of � �,  � in ℝ � ��, �, � � in �� which contains � , � .
� � �
st nd rd
The CS ranges of these generating functions are, respectively, the 1 , 2 , and 3 coordinate-component
surface at �.
st nd rd
Each of these surface CSs shall be termed, respectively, the 1 , 2 , and 3 induced surface CS at �.
rd
EXAMPLE 1 For the Geodetic 3D CS specified in Table 5.14 with CS parameters � and �, the 3 coordinate-
component surface at coordinate � = �0,0,0� is the surface of an oblate ellipsoid with major semi-axis � and minor semi-
rd
axis �. The 3 induced surface CS for the Geodetic 3D CS at � is the Surface Geodetic CS specified in Table 5.24.
rd
EXAMPLE 2 For the Lococentric Cylindrical CS specified in Table 5.17, the 3 coordinate-component surface at
rd
coordinate � = �0,0,0� is a plane. The 3 induced surface CS for the Lococentric Cylindrical CS at � is the Lococentric
Surface Polar CS specified in Table 5.28.
© ISO/IEC 2025 – All rights reserved 41

Several CSs of CS type surface that are specified in this standard are each an induced surface CS for a
corresponding 3D CS.
5.3.4.3 Coordinate-component curves
A coordinate-component curve is the curve that results from fixing the values of two of the three coordinate-
components of a 3D CS while letting the value of the other coordinate-component vary, or from fixing the value
of one of the two coordinate-components of a surface or 2D CS while letting the value of the other coordinate-
st nd
component vary. A coordinate-component curve is identified by the ordinal number (1 , 2 , or in the 3D case
rd
3 ) of the coordinate-component that varies.
The CS type 3D case:
If � is the generating function of a 3D CS, and � = �� , � , � � is in the interior of the CS domain �, the three
� � �
coordinate-component curves at � are defined by:
� ������ = ����, � , � ��,
� � �
� �� � � �
� � � = �� � , �, � �, and
� � �
� ������ = ���� , � , ���.
� � �
The CS domain for � ��� is the connected component of �� in ℝ| ��, � , � � in �� which contains � .
� 0 0 �
� � � | � � �
The CS domain for � � is the connected component of � in ℝ � , �, � in � which contains � .
0 0
� �
The CS domain for � ��� is the connected component of �� in ℝ| �� , � , �� in �� which contains � .
� 0 0 �
st nd rd
The CS ranges of these functions are, respectively, the 1 , 2 , and 3 coordinate-component curve at �.
NOTE  The intersection of two coordinate-component surfaces at � is (the locus of) a coordinate-component curve:
� = � ∩ � , � = � ∩ � , � = � ∩ � .
� � � � � � � � �
The CS type surface and CS type 2D cases:
If � is the generating function of a surface CS or 2D CS, and � = �� , � � is in the interior of the CS domain �,
� �
then the two coordinate-component curves at � are defined by:
� �� � � �
� � � � �� �, � �, and
� �
� ������ � ���� , ���.
� �
� | �
The CS domain for � ��� is the connected component of � in ℝ ��, � � in � which contains � .
� 0 �
� � � | � � �
The CS domain for � � is the connected component of � in ℝ � , � in � which contains � .
� 0 �
st nd
The CS ranges of these functions are, respectively, the 1 and 2 coordinate-component curve at �.
EXAMPLE If � = ��,  � � is in the interior of the CS domain of the Polar CS (5.3.3 Example 2), then the first coordinate-
�
⊤
nd
� �� � � �� �
component curve is � � � = � ��� ,  ��� = �� cos � , � sin �� , and the 2 coordinate-component curve is � � � =
1 2
0 0 0
⊤
� � � �
�� �,  � � = � cos � , ρ sin � .
0 0 0
If � is the generating function for the Geodetic 3D CS or the Surface Geodetic CS, and � = �� , � , 0� in the 3D
� �
case or � = �� , � � in the surface case, then (see Figure 5.12):
� �
st
a) the 1 coordinate-component curve at � shall be termed the parallel at �, and
nd 8
b) the 2 coordinate-component curve at � shall be termed the meridian at �.

ISO 19111 defines the term meridian as “the intersection between an ellipsoid and a plane containing the shortest axis of
the ellipsoid”.
42 © ISO/IEC 2025 – All rights reserved

The meridian at � = �0,0,0� or �0,0� shall be termed the prime meridian .
The parallel at � = �0,0,0� or �0,0� shall be termed the equator.

Figure 5.12 — Geodetic 3D CS geometry, and coordinate-component surface and curves
5.3.5 CS properties
5.3.5.1 Linearity
�
A CS with generating function � is a linear CS if the CS domain is all of ℝ and � is a linear or affine function
�
with respect to the vector space structure of ℝ and position-space.
A curvilinear CS is a non-linear CS. In particular, Geodetic 3D CS and Surface Geodetic CS (Tables 5.14 and
5.24) and every map projection or augmented map projection CS (see 5.3.7) are curvilinear.
5.3.5.2 Orthogonality
A 3D CS, surface CS, or 2D CS with generating function � is orthogonal if the angle between any two coordinate-
component curves at � = ���� is a right angle when � is any coordinate in the interior of the CS domain.
EXAMPLE The Polar CS of 5.3.3 EXAMPLE 2 is an orthogonal CS of type 2D. In this example the CS domain contains
the coordinate (0,0) as a boundary point.
5.3.5.3 Linear CS properties: Cartesian, and orthogonal
th th
In a linear CS, the � coordinate-component curve is a straight line. The � coordinate-component curve at the
�
th
origin � = ���� of a linear CS is the � -axis where � is the all zero coordinate-component �-tuple in ℝ .

ISO 19111 defines the term prime meridian as “the meridian from which the longitudes of other meridians are quantified”.
In Clause 7, most, but not all, oblate ellipsoid Earth object reference models associate the Greenwich meridian with the
prime meridian (see 7.4.5).
© ISO/IEC 2025 – All rights reserved 43

In a linear CS, if the angles between coordinate-component curves at any point are (pairwise) right angles, then
that is the case at all points. In particular, a linear CS is orthogonal if the axes are orthogonal.
A linear CS that is also orthogonal is a Cartesian CS .
EXAMPLE The Lococentric Euclidean 3D CS specified in Table 5.9 is a Cartesian CS since it is a linear CS and its
coordinate-component curves intersect at right angles.
5.3.5.4 CS right-handedness and coordinate-component ordering
� �
Given a 3D CS and a coordinate � = � , � , � in the interior of the CS domain, the coordinate-component
� � �
curves � , � , and � at � � ���� determine an ordered set of three tangent vectors:
� � �
��
�
� � � ,
�
��
���
�
��
�
� � � , and
�
��
���
�
��
�
� � � .
�
��
���
�
An orthogonal 3D CS is a right-handed CS if for any coordinate � in the interior of the CS domain, the ordered
set of tangent vectors � , � , and � form a right-handed coordinate system as defined in IS0 80000-2. The right-
� � �
handed CS property is determined, in part, by the order of the coordinate-components in the coordinate 3-tuple.
The order of the coordinate-components in the specification of an orthogonal 3D CS shall be restricted to an
ordering that ensures a right-handed CS. This restriction is required for uniform treatment of directions, rotations,
and orientations (see Clause 6 and 10.5).
The coordinate-component ordering in the specification of a surface CS that is induced on a coordinate-
component surface of a 3D CS, shall use the coordinate-component order of the inducing 3D CS.
EXAMPLE 1 The Geodetic 3D CS (Table 5.14) coordinate-component ordering ��, �, ℎ� ensures that the CS is right-
handed. A similar ordering for the Planetodetic 3D CS (Table 5.15) is not right-handed because the tangent to Planetodetic
longitude points opposite to the direction of the tangent to Geodetic longitude. Instead, the coordinate-component ordering
� �
�, �, ℎ is specified to satisfy the right-handed CS requirement.
EXAMPLE 2 The Surface planetodetic CS (Table 5.25) coordinate-component ordering ��, �� is determined by the
� �
coordinate-component ordering �, �, ℎ of the Planetodetic 3D CS (Table 5.15) which induces the Surface planetodetic CS
rd
as its 3 coordinate-component surface.
5.3.6 CS localization
5.3.6.1 Overview
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. This document provides a set of parameterized localization operators
that can be used to translate and/or rotate a coordinate system within position-space. It is useful in some
applications to reduce the dimensionality of a 3D coordinate system by fixing the values of one or more of its

Some publications use “rectangular” to denote an orthogonal linear CS, and “oblique” to denote a non-orthogonal linear
CS.
ISO 19111 defines Cartesian coordinate system as “a coordinate system that gives the position of points relative to n
mutually-perpendicular axes”.
44 © ISO/IEC 2025 – All rights reserved

coordinate-components, resulting in an induced surface coordinate system (5.3.4). These two mechanisms can
be combined to create localized induced surface coordinate systems.
5.3.6.2 Localization operators
A coordinate system can be translated and/or rotated to realise a local variant. A localization operation is used
to accomplish this. The generating function of the original CS is composed with an appropriate localization
operator to specify the generating function of the local variant CS. This method of specifying a local variant CS
is termed CS localization. The result is termed a localized CS.
Three parameterized operators, termed localization operators, that operate on or between position-spaces are
defined in Table 5.2. The inverses of these operators are defined in Table 5.3. The vectors in these tables,
termed localization parameters, are vectors in (the range) position-space where � denotes the local origin
(lococentre), and unit vectors � and � denote the primary and secondary axis directions respectively. The
localization operators require � and � to be orthonormal vectors, that is, � and � are orthogonal (� • � � 0) and
normal (‖�‖ = ‖�‖ = 1).
Table 5.2 — Localization operators
Localization
Domain Range Localization parameters Operator definition
operator
� � �
� ℝ ℝ �, �, �, in ℝ �
��
� ���, �, �� � = � + �� + �� + ��,
3D
� and � are orthonormal
where: � = � × �.
� � �
� ℝ ℝ �, �, �, in ℝ
Surface �
�� � �
� �, � = � + �� + ��
Surface
� and � are orthonormal
� � �
� ℝ ℝ �, �, �, in ℝ
2D �
�� � �
� �, � = � + �� + ��
2D
� and � are orthonormal
Table 5.3 — Localization inverse operators
Localization
Inverse operator definition
operator
��
�
� ��� = ��� − �� • ��� + ��� − �� • ��� + ��� − �� • ���
3D
� � �
3D
��
�
� ��� = ��� − �� • ��� + ��� − �� • ���
Surface
� �
Surface
��
�
� ��� = ��� − �� • ��� + ��� − �� • ���
2D � �
2D
There are several forms of CS localization depending on CS type and localization operator. A 3D or surface CS
with generating function G is localized by composing � with the � localization operator. The localized CS is of
3D
the same CS type (CS type 3D or CS type surface, respectively). Its generating function is � ≡ � ∘ � and has
� 3D
the same CS domain as �.
�
There are two localization operators for a 2D CS. One uses localization parameters in ℝ and produces a
�
surface CS. The other uses localization parameters in ℝ and produces a 2D CS.
a) A 2D CS with generating function � is localized by composing � with the � localization operator.
Surface
The localized CS is a surface CS. Its generating function is � ≡ � ∘ � and has the same CS
� Surface
domain as �.
b) A 2D CS with generating function � is localized by composing � with the � localization operator. The
��
localized CS is a 2D CS. Its generating function is � ≡ � ∘ � and has the same CS domain as �.
� 2D
The localization operator parameter q shall be termed the lococentre. A localized CS may be termed a
lococentric CS.
© ISO/IEC 2025 – All rights reserved 45

The CS generated by � is related to the original CS in that the geometry of the coordinate curves and surfaces
�
are similar to that generated with � but with the geometry shifted over in position-space with a translation by �
and oriented with respect to the �, �, and � = � × � basis vectors instead of the � ,  � ,  � basis vectors. This
� � �
use of localization operators specifies a family of CSs with generating functions � parameterized by the
�
localization parameters �, �, �. This employment of lococentric operators is used below in the specification of
all the CSs that have “LOCOCENTRIC_” as a name prefix.
NOTE 1 CS localization preserves the following CS properties: linear/curvilinear, orthogonal, and Cartesian.
The relationship between a CS type and its localized version(s) is summarized in Table 5.4.
Table 5.4 — Localized CS type relationships
CS type Localization Resulting lococentric
operator CS type
3D � 3D
3D
Surface � Surface
3D
2D � Surface
Surface
2D � 2D
2D
NOTE 2  In the case of 3D position-space, a set of localization parameters �, �, and � together with � = � × � specifiy an
orthonormal frame with � as its origin and �, �, � as its basis vectors (see 5.2.3). In effect, a localization operator transforms
the geometry of the CS surfaces and coordinate-component curves with respect to the canonical frame of position-space to
the same geometry with respect to the �, �, �, � orthonormal frame by translating the position-space origin to � and rotating
the axes to align with �, �, �.
EXAMPLE 1 An instance of the Lococentric Euclidean 3D CS (see 5.3.8.3) results from using the � operator to localize
3D
the Euclidean 3D CS (see 5.3.8.2) to a new origin at � and axis directions �, �, and �.
EXAMPLE 2 Given an instance of the Equatorial Spherical CS (see 5.3.8.4), fixing the radius � induces a Surface
Equatorial Spherical CS. The � operator applied to the generating function of this new surface CS produces a Lococentric
3D
Surface Equatorial Spherical CS with origin at � and equatorial plane defined by � and �. (Similar to 5.3.8.5, Lococentric
Equatorial Spherical CS, but with fixed radius �.)
EXAMPLE 3 An instance of the Lococentric Surface Polar CS (see 5.3.8.22) results from using the � operator to
Surface
localize the 2D Polar CS (see 5.3.8.27) onto the surface of a plane in 3D position-space defined by �, � and �.
EXAMPLE 4 An instance of the Lococentric Polar CS (see 5.3.8.28) results from using the � operator to localize the
2D
2D Polar CS (see 5.3.8.27) to a new origin and angle directions.
For creating a localized induced surface CS, the operations of localization and inducing a surface CS (see
5.3.4.2) are order-independent in the following way.
Consider X, a 3D CS with generating function � . For a given set of localization parameters, and a given value
3D
� = 1, 2, or 3, a localized induced surface CS at coordinate � may be derived from X by two methods.
In one method, first X is localized to LX, a 3D CS with generating function � ∘ � . Then LX induces SLX, the
3D 3D
th
n induced surface CS for LX at c with generating function � �� ∘ � �.
� 3D 3D
th
In the other method, first X induces SX, the � induced surface CS for X at � with generating function � �� �.
� 3D
Then SX is localized to LSX, a surface CS with generating function � ∘ � �� �.
3D � 3D
� �
The two resulting localized surface CSs, SLX and LSX, are identical with generating functions � � ∘ � =
� 3D 3D
� ∘ � �� � (see Figure 5.13). For examples, see Table 5.26 Note 1, Table 5.27 Note 2 and Table 5.28 Note
3D � 3
...

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

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)
� � � ∘ � ∘ � �
T T T←S S S
where � denotes the coordinate of � in SRF , and � denotes the coordinate of � in SRF . � is the spatial
S T
S T S
generating function for CS . � �� � is the position vector � expressed in the embedded frame determined by
S
S S
ORMS. � is the similarity transformation that transforms � from the embedded frame determined by ORMS
T←S
to the embedded frame determined by ORMT. The inverse of the spatial generating function � , operating on �
T
expressed in terms of the embedded frame determined by ORM , returns � . The composition of these
T
T
operations is illustrated in Figure 10.3. CS generating and inverse generating functions are specified in Clause
5. Similarity transformations are specified in Clause 7.

Figure 10.3 — Change of SRF operation – applied to coordinates
Equation 10.5 is only defined for a value of � in the CSS domain if its corresponding position belongs to the
S
� �
CST range (the range of a generating function is the domain of its inverse generating function). If Dom � is
S
� � � �
the domain of the generating function � , Rng � is the range of the generating function � , and Rng � is the
S S S T
range of the generating function � , Equation 10.5 is only defined for � in the set:
T S
�� ��
(10.6)
� ������ � ∩ � ������ ��� ≡ �� in Dom�� �|� �� �� �� in ����� ��
S S T←S T S S T←S S S T
If � does not belong to this set, it is invalid for the operation in Equation 10.5.
S
EXAMPLE SRFS is SRF GEOCENTRIC_WGS_1984 and SRFT is an instance of SRF template MERCATOR, with
ORM WGS_1984. For any � that is on the �-axis of SRF , Equation 10.5 is not defined and is thus invalid, because the �-
S
S
axis is not contained in the range of SRF template MERCATOR and, thus, it is not contained in the set in Equation 10.6.
284 © ISO/IEC 2025 – All rights reserved

SRFT may optionally specify an applicable region � , and may optionally also specify an extended region �
T T
� � � �
(see 8.3.2.4). If Dom � is the domain of the generating function � , then � ⊆ � ⊆ ��� � . If � is computed
T T T T T T
using Equation 10.5, � is either within the applicable region (� is in � ), or � is within the extended region but
T T T T
not within the applicable region (� is in � /� ), or � is within the CS domain but not within the extended region
T T T T
� �
(� is in Dom � \� ).
T T T
In applications that functionally conform to an SRM profile, the domain of an SRF operation is restricted to the
accuracy domain of the SRF as specified by that profile (see Clause 12).
Equation 10.5 depends on the existence of a similarity transformation � from the embedded frame
T←S
determined by ORM to the embedded frame determined by ORM . If ORM and ORM represent the same
S T S T
object, � is as defined in 10.3.2. If ORMS and ORMT represent different objects, � is as defined in 10.3.3.
T←S T←S
The simplifications
If SRFS and SRFT are two CELESTIODETIC SRFs with different object reference models for the same spatial
object, Equation 10.5 transforms the coordinate � � �� , � , ℎ � with respect to one oblate ellipsoid to � �
S S S S T
�� , � , ℎ � with respect to the other oblate ellipsoid. A transformation between two CELESTIODETIC SRFs for
T T T
the spatial object Earth is known as a horizontal datum shift.
NOTE A number of numerical approximations developed to implement horizontal datum shift have been published.
Under the assumption of zero rotations and no scale differences, a widely used approximation to directly transform � �
S
�� , � , ℎ � to � � �� , � , ℎ � is the standard Molodensky transformation formula (see [NGA36]).
S S S T T T T
In the case of a time-dependent relationships between ORMS and ORMT, Equation 10.5 generalizes to:
-1
� ��� � � ∘ � ��� ∘ � �� �
T T T←S S S
� �
The time-dependent similarity transformation � � is as discussed in 10.3.2 and 10.3.3, depending on
T←S
whether ORM and ORM represent the same object or two different objects.
S T
10.4.3 Matched normal embeddings
In this special case of the change of SRF operation, the source and target SRFs share the same ORM, or, more
generally, the reference transformations of ORMS and ORMT are equivalent (i.e., matched normal embeddings),
and therefore � is the identity transformation. Consequently, Equation 10.5 simplifies to:
T←S
-1 ��
� = � ∘ � �� � for all � in the set: �� ������ � ∩ ����� ���. (10.7)
T T S S S S S T
EXAMPLE 1 If SRFS is a CELESTIODETIC SRF and SRFT is the CELESTIOCENTRIC SRF for the same ORM, then
-1
since the CS of the CELESTIOCENTRIC SRF is Euclidean_3D for which the � is the identity, Equation 10.7 reduces to
T
the geodetic generating function: � = � �� �.
T S S
If SRF is a 3D SRF that has ellipsoidal height designated as the vertical coordinate-component of the SRF (see
T
8.4.3), and SRFS is the induced zero height surface SRF, the promotion operation converts a surface coordinate
st nd st nd
� in SRF to a 3D coordinate in SRF by setting the 1 and 2 coordinate-components of � to the 1 and 2
S T
S T
rd
coordinate-components of � and setting the 3 coordinate-component, ellipsoidal height, to 0. Coordinate
S
promotion is a special case of Equation 10.7. Applicable spatial reference frames include those based on SRF
templates CELESTIODETIC, PLANETODETIC, and all map projection SRF templates.
EXAMPLE 2 If SRFS is an induced zero height surface CELESTIODETIC SRF and SRFT is the 3D CELESTIODETIC
SRF for the same ORM, Equation 10.7 promotes � = ��, �� from a coordinate of CS type surface to � = ��, �, 0� a
S T
coordinate of CS type 3D.
Historically it was thought that these approximations would require less computation than direct conversion. The perceived
computational advantage may have been overcome by technology advances. New efficient algorithms for converting
celestiocentric coordinates to celestiodetic coordinates have been developed that result in appreciably faster transformations
without the attendant loss of accuracy.
© ISO/IEC 2025 – All rights reserved 285

If SRFS is a 3D SRF that has ellipsoidal height designated as the vertical coordinate-component of the SRF
(see 8.4.3), and SRF is the induced zero height surface SRF, the truncation operation converts a 3D coordinate
T
st nd st nd
� in SRFS to a surface coordinate � , by setting the 1 and 2 coordinate-components of � to the 1 and 2
S T T
coordinate-components of � . The point in object-space corresponding to � and the point in object-space
S S
corresponding to � are not the same point unless the height coordinate-component ℎ = 0. Truncation,
T
therefore, does not generally preserve location.
EXAMPLE 3 If SRFS is a CELESTIODETIC 3D SRF, the (induced) zero height surface SRFT is the surface
CELESTIODETIC SRF for the same ORM. The truncation operation associates � = ��, �� to � = ��, �, 0�.
T S
EXAMPLE 4 SRFS is a CELESTIODETIC 3D SRF based on ORM SIRGAS_2000 (Table D.2). SRFT is a
CELESTIODETIC 3D SRF based on ORM WGS_84, which is the reference ORM for Earth. The reference transformation
for SIRGAS_2000 (Table E.6) is the identity transformation, thus the ORM embedded frames match and Equation 10.7
applies. However, the ellipsoid RDs for these two ORM have differing minor semi-axis values �. Thus, the generating
-1
functions for these SRFs, while both CELESTIODETIC 3D, have differing values at non-zero latitudes. Consequently � ∘
T
� in Equation 10.6 will not equal the identity function. Furthermore, the applicable region of SRF is smaller than the
S
S
applicable region of SRF .
T
10.4.4 Matched normal embeddings and map projection SRFs
In this special case of the change of SRF operation for map projection spatial reference frames, the source and
target spatial reference frames share the same ORM, or, more generally, the reference transformations of ORM
S
and ORMT determine the same embedded frame (i.e., matched normal embeddings), and therefore � is the
T←S
identity transformation.
The spatial CS generating function � for an augmented map projection SRF is implicitly defined (see 5.3.7.2
MP
and 5.4.2) by the composition of the spatial generating function, � , for the GEODETIC 3D CS with the inverse
GD
� �
mapping equation � ≡ � , � , ℎ as:
� �
� = � ∘ �.
MP GD
If SRFS and SRFT are map projection spatial reference frames for the same object, and the reference
transformations of ORM and ORM are equivalent, Equation 10.7 becomes:
S T
��
� = �� ∘ � � ∘ �� ∘ � ��� �
T GD,T T GD,S S S
(10.8)
��
� �
= � ∘ � ∘ � ∘ � �
T GD,T GD,S S S
where:
� : inverse mapping equations for SRFS,
S
� : spatial generating function for the GEODETIC 3D CS for SRF ,
S
GD,S
� : inverse mapping equations for SRFT (the inverse of � )
T T
� : mapping equations for SRF , and
T
T
� : spatial generating function for the GEODETIC 3D CS for SRFT,
GD,T
Furthermore, if ORM = ORM , � = � and Equation 10.8 simplifies to:
S T
GD,S GD,T
(10.9)
� �
� = � ∘ � � .
T T S S
If SRF is a CELESTIODETIC SRF, SRF is an augmented map projection SRF, and ORM = ORM , Equation
T S T S
10.7 simplifies to:
� �
� = � � .
T S S
Similarly, if SRF is a CELESTIODETIC SRF, SRF is an augmented map projection SRF, and ORM = ORM
S T T S,
Equation 10.7 simplifies to:
� = � �� �.
T T S
NOTE In Equation 10.8 the ORM and ORM are based on ORMTs OBLATE_ELLIPSOID_ORIGIN and/or
S T
SPHERE_ORIGIN. If the source RD set components ORIGIN_3D, RD Z_AXIS_3D and RD X_AXIS_3D coincide with
286 © ISO/IEC 2025 – All rights reserved

corresponding target RD set components, each ORM will determine the same normal embedding. However, if the oblate
ellipsoid RD parameters (major and/or minor semi-axes) or sphere RD parameters (radius) do not match, � ≠ � .
GD,S GD,T
10.4.5 SRFs with Cartesian coordinate systems
In this special case of the change of SRF operation both the source and target SRFs (SRF and SRF ) are
S T
instances of the LOCOCENTRIC_EUCLIDEAN_3D SRFT (Table 8.11). As noted in 8.4.5, this special case is
important for the treatment of directions, vectors, and orientations (see 10.5). This SRFT requires localization
parameter vectors �, �, and � in the embedded frame � determined by the associated ORM (see 8.4.4). In terms
of these parameters the spatial generating function, � , is in the form of an affine transformation and thus
LE3D
allows the change of SRF operation to be explicitly expressed in affine transformation form (Equation 10.10) as
well. The affine form of � operating on the coordinate ��, �, �� of a position � in the localized frame � is:
LE3D
� = � ���, �, ��� = � ∘ � ���, �, ���
LE3D 3D E3D
= � + �� + �� + ��
� � �
� � �
� � �
= � + � � � + � � � + � � �
� � �
� � �
� � �
� � �
�
� � �
� � �
= � + � � �� �
� � �
� � �
�
� � �
�
= � + � �� �
�←�
�
where:
� � �
� • � � • � � • �
� � �
� � �
� = � � = �� • � � • � � • �� ,
� � �
�←�
� � �
� • � � • � � • �
� � �
�, � and � = �� × �� are the basis vectors of the localized frame �, and
�, �, � are the basis vectors of the embedded frame �.
The spatial generating function � maps a coordinate tuple in the domain of the localized frame of the SRF
LE3D
to the corresponding position � in terms of the embedded frame � determined by the ORM of the SRF. The
�
coordinate tuple ��, �, �� corresponds to the column vector �� � �� , for � in the localized frame � specified
by the parameters �, �, and �.
The inverse generating function can be similarly expressed as:
��
� � � �
� � = �, �, �
LE3D
where
� �� �
� � �
� � = � �� − �� and � = � = �
�←� �←� �←� �←�
The change of basis operation � transforms a position-vector in terms of the embedded frame � to the
�←�
corresponding position-vector in terms of the localized frame � of the SRF.
The affine form of the spatial generating function � and its inverse provide an affine form for the change of
LE3D
SRF operation between two instances of the LOCOCENTRIC_EUCLIDEAN_3D SRFT, SRFS and SRFT, with
differing ORMs. This is illustrated in Figure 10.4. In this figure, the �-axis of each of the four frames shown
projects out of the page. SRFS has localization parameters � , � , � and associated ORMS, and SRFT has
S S S
localization parameters � , � , � and associated ORMT. The similarity transformation between these object
T T T
reference models is denoted by � .
T←S
© ISO/IEC 2025 – All rights reserved 287

Figure 10.4 — Change of SRF operation for Lococentric Euclidean 3D SRFs
The coordinate � in SRFT that corresponds to coordinate � in SRFS can be computed using Equation 10.5:
T S
��
� = � ∘ � ∘ � �� �
T T←S LE3D, S S
LE3D, T
The change of SRF operation consists of three steps. First, the coordinate � is transformed from the localized
S
frame � for SRFS to its embedded frame � , as shown in the left side of Figure 10.4. Next, the similarity
S S
transformation � transforms the coordinate from the embedded frame � for SRF to the embedded frame
S
T←S S
� for SRFT. Finally, the coordinate is transformed from the embedded frame � of SRFT to its localized frame
T T
� , as shown in the right side of Figure 10.4.
T
Substituting the expression in Equation 10.3 for � , and applying the affine transformation to both �
T←S LE3D, S
��
and � gives:
LE3D, T
�
� = � �� �� + � �� �� − � �
T T←S S � ←� S T
� ←�
T T S S
σ
R←S
�
��⃗
� �
= � �Δ − � + � �� + � � ��
� ←� T←S T T←S S � ←� S
T T S S
σ
R←T
σ σ
R←S R←S
� �
��⃗
� �
= � �Δ + � � − � � + � � �� ∘ � ∘ � � �
� ←� T←S T←S S T ����←�������T←�S������←��� S
T T T T S S
σ σ
������������������������� �����
R←T R←T
������
�����
�������� ������
��������������
������
where
(10.10)
� = ��, �, �� , � = ��, �, �� , and
S S T T
for: i = S or T,
� � �
�,� �,� �,�
� � �
� � � �,
�,� �,� �,�
� ←�
� �
� � �
�,� �,� �,�
� � � � � �
� � � �,� �,� �,��, � � � �,� �,� �,��, and
� �
� � �
� �
� � �,� �,� �,� are the CS localization parameters
�
288 © ISO/IEC 2025 – All rights reserved

The advantage of the final form of Equation 10.10 is that it is significantly more efficient when transforming a
large number of points, as the vector, factor, and matrix components are constant and can be computed once
and reused for each point.
If the corresponding reference transformations of ORM and ORM are equivalent, in that they each determine
S T
the same embedded frame, Equation 10.7 specializes to Equation 10.11:
��
� � � ∘ � �� �,
T LE3D,T LE3D, S S
� �
� � � �
� � � � − � + � ∘ � � (10.11)
T � ←� S T � ←� � ←� S
T T T T S S
where � � ��, �, ��
S
Every SRF C with a Cartesian coordinate system is equivalent to the LOCOCENTRIC_EUCLIDEAN_3D SRF
specified with SRFT localization parameters defined as:
� is the embedded frame vector for the origin of C,
� is the unit vector on the primary axis of C pointing in the positive direction, and
� is the unit vector on the secondary axis of C pointing in the positive direction.
Thus Equations 10.10 and 10.11 apply to SRFs with Cartesian coordinate systems as well.
Similarly, the Cartesian coordinate system of any localized frame specified with frame parameter vectors �, �,
and � may also be identified with a LOCOCENTRIC_EUCLIDEAN_3D SRF using the same parameters.
10.4.6 Instantiating abstract object-space SRFs
Engineering designs or abstract models are intended for realisation in the physical world or in virtual worlds.
Instantiation of such models can require several types of SRFs and specific sequences of position operations.
Abstract models are designed in abstract object-spaces using such SRFs that have a Cartesian coordinate
system as LOCAL_SPACE_RECTANGULAR_3D. In many application domains, abstract models are included
in other object-spaces. These other (target) object-spaces may be another abstract object-space, using its own
instance of a LOCAL_SPACE_RECTANGULAR_3D SRF, or may be a physical object-space, using an SRF
with either a Cartesian or non-Cartesian coordinate system. To include an abstract model in a target object-
space that is specified with an SRF that has a non-Cartesian coordinate system, it is necessary to establish a
lococentric SRF that has a Cartesian coordinate system. A uniform method is used to establish such a
lococentric SRF regardless of the properties of the SRF in the target object-space. The SRF in the target object-
space supplies the reference coordinate � to specify the origin of the lococentric SRF, which is instanced from
either a LOCAL_TANGENT_SPACE_EUCLIDEAN SRFT or a LOCOCENTRIC_EUCLIDEAN_3D SRFT. In this
role, the SRF in the target object-space becomes the reference SRF and the lococentric SRF acts as the target
SRF.
EXAMPLE 1 A building plan is designed in the source model SRF , an abstract space
S
LOCAL_SPACE_RECTANGULAR_3D SRF. A terrestrial site survey establishes the coordinate for the origin of the
model in a reference SRF, a CELESTIODETIC SRFR. The target LOCAL_TANGENT_SPACE_EUCLIDEAN SRF,
SRFT, is instanced at the origin point specified in SRFR. Source coordinates in SRFS are related to local target coordinates
in SRFT by: �� , � , � � � ��� , � , � �, where � is a model scale factor. In addition to scaling, the instanced model is often
T T T S S S
rotated to adjust its orientation at the instanced position.
NOTE In some modelling applications, the model centre of gravity or bounding box centre, among other choices, is
considered to be the "model origin". However, for purposes of model instantiation, the model origin is the point with
coordinate �0, 0, 0� in the SRF in which the model is defined.
The instancing of an abstract model entails the following steps:
1) If the abstract space geometric model is specified in SRFM that is not a
LOCAL_SPACE_RECTANGULAR_3D SRF and is instead specified in another 2D or 3D abstract space
SRF, the model is converted using Equation 10.6 from SRFM to SRFS, a
LOCAL_SPACE_RECTANGULAR_3D SRF. Otherwise, SRF becomes SRF .
M S
© ISO/IEC 2025 – All rights reserved 289

2) The position at which the model is instanced in the physical or abstract target object-space is identified
by a coordinate � in SRF , a reference SRF for the target object-space.
R
3) The target for the conversion is SRF , a lococentric SRF with a Cartesian coordinate system and its
T
origin specified by the coordinate � in SRF . SRF may be either a
R T
LOCAL_TANGENT_SPACE_EUCLIDEAN SRF or a LOCOCENTRIC_EUCLIDEAN_3D SRF. SRF is
T
realised by the reference coordinate � and the SRF template parameters.
T
4) A world transformation is supplied to correctly position, scale, and orient the geometric model instance.
The transformation includes a scaled rotation matrix ��, where � is a scale factor and � is a rotation or
��⃗
� �
identity matrix. The transformation may also optionally include Δ � Δ� , Δ� , Δ� , an offset of the
T T T T
model origin from the SRF origin.
T
5) Each model vertex coordinate in SRFS is converted to a corresponding coordinate in SRF through the
T
following transformation:
� �
Δ�
� �
� � � ��� + �� � � .
(10.12)
� Δ� �
T S
T
��⃗
This equation is in the form of Equation 10.5 where � � � � Identity and � ��� � Δ + ��� (see Equation
S T T←S T
10.2), thus the conversion may be viewed as a change of SRF operation. See also 10.5.3 Example 2.
In the terminology of ISO/IEC 18023-1, when Instantiating a model in abstract object-space into either another
abstract object-space or a physical object-space, the terms �� appearing in Equation 10.12, and
σ
R←S
� � �� appearing in Equation 10.3 represent the same concept (scaled rotation matrix) and are
� T←S
R←T
denoted by �. In ISO/IEC 18023-1, the invertible 3x3 matrix � is termed a World Transformation matrix and is
specified in the class which is a component class of Instance>.
NOTE Equation 10.12 illustrates that digital graphic composite pattern modelling techniques such as SceneGraph trees
that use scale and rotation matrices � together with translation operations at each tree node are special cases of Equation
10.4. See also 10.5.3 Example 2.
EXAMPLE 2 A model geometry is specified in SRFM, an abstract object-space SRF with a Cartesian coordinate system.
The model is to be instanced in a physical object-space with a geocentric reference SRF, SRF . The SRF reference
R R
coordinate � determines the position of the model origin at point �. SRFT is the target SRF realised from the
LOCOCENTRIC_EUCLIDEAN_3D SRFT with template parameters �, �, �, where � and � are, respectively, the primary
and secondary coordinate axis unit vectors of SRFT with respect to SRFR. The orientation of the instanced model with respect
to SRF (and SRF ) is determined by the model’s rotation matrix �.
T R
EXAMPLE 3 A CAD model of an automobile wheel is designed in an abstract object-space using a
LOCAL_SPACE_RECTANGULAR_3D source SRF, SRF . The wheel model is then instanced into another abstract object-
S
space where a CAD model for the entire car is being designed, using a target LOCAL_SPACE_RECTANGULAR_3D SRF,
SRF . This is illustrated in Figure 10.5. In this simple case, there is no need for a distinct reference SRF, and there is no
T
need to localize the target SRF. The centre of the wheel model is at the origin of SRFS, and its orientation is aligned with the
axes of SRF . A transformation � embeds an instance of the SRF into the abstract object-space of the car model,
S S
T←S
scaling the wheel model by � to be consistent with the car model, and translating it by � to the appropriate position with
T
respect to the car model. If necessary, the transformation can also rotate the wheel model by � to align it with the car model.
SRFS is an example of a component object SRF with respect to SRFT (see 8.4.2).
290 © ISO/IEC 2025 – All rights reserved

Figure 10.5 — Abstract object realised in another abstract object-space
EXAMPLE 4 A house is designed in an abstract object-space using a LOCAL_SPACE_RECTANGULAR_3D source
SRF, SRF . A terrestrial site survey using the GEODETIC_WGS_1984 SRF as the reference SRF, SRF , establishes the
S R
� �
geodetic coordinate λ , φ , ℎ of the southeast corner of the site where the house will be built. This geodetic coordinate
� � �
provides parameter values for an instance of the LOCAL_TANGENT_SPACE_EUCLIDEAN SRF template that defines the
origin (and tangent point) of the target SRF, SRFT (see 8.4.4). The origin of SRFT is at the southeast corner of the building
site, and its axes align with local east and local north. Because the house will not be positioned at the origin of SRF , or
T
aligned with its axes, the transformation � scales the house model to its actual size, rotates it to its planned orientation
T←S
on the site, and translates it to its planned position. This is illustrated in Figure 10.6.

Figure 10.6 — Abstract object realised using a geodetic reference point
EXAMPLE 5 A house is designed in an abstract object-space using a LOCAL_SPACE_RECTANGULAR_3D source
SRF, SRF . The GEOCENTRIC_WGS_1984 SRF is used as the reference SRF, SRF . The localization parameters � , � ,
S R
T T
and � , for an instance of the LOCOCENTRIC_EUCLIDEAN_3D SRF template define the target SRF, SRFT (see 8.4.4).
T
The geocentric coordinate ��, y, �� determines a corner of the building site, which is the origin of SRF at � . The building
T
T
site footprint determines the axes � and � . Because the house will not be positioned at the origin of SRFT, or aligned with
T T
its axes, the transformation � scales the house model to its actual size, rotates it to its planned orientation on the site,
T←S
and translates it to its planned position. This is illustrated in Figure 10.7.
© ISO/IEC 2025 – All rights reserved 291

Figure 10.7 — Abstract object realised using a geocentric reference point
10.5 Vector operations
10.5.1 Overview
Directions and vector quantities associated with a 3D SRF are specified with respect to 3D localized frames
(see 5.3.6.3). Given a localized frame for object-space (see 8.4.4), a direction is represented as a unit vector in
the Cartesian coordinate system determined by the frame. Vector quantities, such as velocity or force, are
specified as vectors of appropriate direction and magnitude in the frame. The 3D localized frame is termed the
vector reference frame (see 5.3.6.4).
The choice of the vector reference frame is often determined by the requirements of the user application. A 3D
SRF can be used directly or indirectly to specify the vector reference frame (see 8.4.5).
One choice is to use a local tangent frame as the vector reference frame. A coordinate � in the interior of the
domain of an orthogonal right-handed 3D SRF specifies the local tangent frame at � (see 5.3.6.3 and 8.4.5).
This local tangent frame has its origin at � and its basis vectors tangent to the coordinate-component curves of
the 3D SRF at the origin.
In the special case that the 3D SRF is an SRF with a Cartesian coordinate system, all coordinate-component
curves are straight lines in object-space. For each coordinate-component, all coordinate-component curve
instances are parallel to one another. All coordinate-component curve instances for each coordinate-component
are perpendicular to the coordinate-component curve instances for the other two coordinate-components. Thus,
all local tangent frames in an SRF with a Cartesian coordinate system are oriented the same way and differ only
in the location of the frame origins.
A less restrictive choice is to use a localized frame (see 8.4.5) as the vector reference frame. An SRF with a
Cartesian coordinate system and spatial generating function �� � specifies a localized frame by coordinates
� � � � � � � � � �
� , � , � where � � is the localized frame origin and the vectors � � − � � and � � − � � , which are
� � � � � � � �
perpendicular to each other, are its basis vectors (see 5.3.6.3).
Given a vector with respect to one vector reference frame, the representation of the vector can be converted to
a second vector reference frame if the orientation of one frame with respect to the other can be computed. The
conversion operation under various situations is treated in 10.5.2. In the most general case, this operation uses
the rotation matrix � from the similarity transformation � in Equation 10.3. The translation and scale
T←S T←S
factor terms of � are not used since vectors are translation invariant and of fixed vector magnitude. Vectors
T←S
represented in one object-space can also be instantiated in another object-space. This is addressed in 10.5.3.

All of the 3D SRFTs in this document are based on orthogonal right-handed CSs.
292 © ISO/IEC 2025 – All rights reserved

10.5.2 Converting vectors between different vector reference frames
Given a source SRF, SRF with corresponding ORM and embedded frame � , and a target SRF, SRF with a
S S T
S
corresponding ORM and embedded frame � , a vector reference frame � can be derived from SRF at
T S
T S
coordinate � as described in 10.5.1. Similarly, another vector reference frame � can be derived from SRFT at
S T
coordinate � .
T
SRF and SRF can be in the same object-space, or in different object-spaces. When SRF and SRF are in
S T S T
the same object-space, their embedded frames � and � can be either distinct or identical. When SRFS and
S T
SRF are in different object-spaces, their embedded frames are always distinct.
T
Identical embedded frames:
If both SRF and SRF are in the same object-space, there are several conditions under which the embedded
S T
frames � and � are identical (i.e., share the same origin and the same basis vectors):
S T
a) SRFS and SRFT are the same SRF,
b) SRF and SRF are specified using the same ORM, or
S T
c) SRFS and SRFT are specified using different ORMs that determine normal embeddings that produce
the identical embedded frames.
In these cases, given � , a vector with magnitude and direction represented in vector reference frame � , the
S S
same vector, denoted as � , can be represented with respect to vector reference frame � as:
T T
� � �  � ,
T T←S S
where � is the orientation of vector reference frame � with respect to vector reference frame � (see 6.3.2).
T←S S T
Since both vector reference frames � and � are specified using identical embedded frames, � is the
S T T←S
direction cosine matrix that transforms positions in � to equivalent positions in � (see 6.2.2):
S T
� • � � • � � • �
S T S T S T
� • � � • � � • �
� � � �,
S T S T S T
T←S
� • � � • � � • �
S T S T S T
(10.13)
where:
for � = S, T: � , � and � are the basis vectors of vector reference frame � at � .
� � � � �
Distinct embedded frames:
In the most general case when either the two vector reference frames � and � are specified using distinct
S T
embedded frames, or when SRF and SRF are in different object-spaces, � is computed as:
S T
T
� � � ∘ � ∘ �  �
T � ←� T←S � ←� S
T T S S
where:
� is the transpose of � ,
� ←� � ←�
T T T T
� is the rotation matrix component of the similarity transformation � from ORM
S
T←S T←S
to ORMT (see Equation 10.3 in 10.3.2) and
(10.14)
for: i = S or T,
� • � � • � � • �
� = �� • � � • � � • ��,
� ←�
� �
� • � � • � � • �
�, �, � are the basis vectors for the vector reference frame � at � , and
i �
�, �, � are th
...