# I. Executive Summary

Testbed-18 explored the potential use of OGC Standards for non-terrestrial applications and was scoped as a paper study. Validation of the Testbed-18 recommendations has been left for Testbed-19. This OGC Engineering Report (ER) documents recommended changes to OGC Standards and the implementation experience to justify those changes.

The use of OGC Standards include geospatial applications for non-Earth planets as well as interplanetary spatiotemporal applications. Two Standards emerged as key: ISO 19111 (OGC Abstract Specification 2: Referencing by coordinates) and OGC 21-056r11 (OGC GeoPose 1.0 Data Exchange Standard). Extensions to ISO 19111 were identified which would support the representation of non-terrestrial planetary spatial reference systems as well as interplanetary spatiotemporal reference systems.

The GeoPose Standard (GeoPose) was explored as a mechanism to integrate the large number of reference systems and transformations needed to model the geometry of interplanetary spacetime.

In the context of the Double Asteroid Redirection Test (DART) scenario, positions and orientations in different coordinate reference systems and associated attributes such as velocities of non-terrestrial objects were encoded using two different approaches: as sequences of extended GeoPoses, and as OGC Moving Features JSON (MF-JSON). These encoded data were then used as the basis for a 3D visualization demonstration.

This work is not intended to replace the existing standards already used in astronomy such as the World Coordinate System (WCS). The recommendations provided in this ER are rather intended to improve interoperability by specifying how to export a subset of a WCS description as OGC/ISO data structures for consumption by GIS software or other geospatial technology applications.

Testbed-18 also investigated how GeoPose could be integrated with mobile location-aware devices such as smartphones. Engineering Report OGC 22-016r3 (Testbed-18: Moving Features) concluded that GeoPose could enrich data with location and orientation information synchronized to video and other sensors and identified two suitable road network use cases for study using WebVMT in Testbed-19.

# II. Keywords

The following are keywords to be used by search engines and document catalogues.

ogcdoc, ogc, referencing, coordinate operation, space, extraterrestrial, relativity, Minkowski, spacetime, ISO 19111, GeoPose, testbed, DART, OS Bubble

# III. Contributors

All questions regarding this document should be directed to the editor or the contributors:

Name | Organization | Role |
---|---|---|

Rob Smith | Away Team | Contributor |

Sina Taghavikish | Open Geospatial Consortium | Editor |

Charles Heazel | HeazelTech | Contributor |

Jérôme Jacovella-St-Louis | Ecere | Contributor |

Carl Stephen Smyth | Open Site Plan | Contributor |

Martin Desruisseaux | Geomatys | Contributor |

# 1. Introduction

OGC Testbed-18 evaluated the potential use of existing OGC/ISO Standards for applications on celestial bodies other than planet Earth. These applications include data for other planetary bodies, for objects in orbit around those planetary bodies, and for objects in free flight within our solar system. Testbed-18’s research on non-terrestrial bodies and standards was largely a paper exercise. This research included an evaluation of the published standards to determine what should be possible. Validation of the conclusions through prototype implementations was left for Testbed-19. This Engineering Report (ER) documents the results of those Testbed-19 prototype implementation efforts.

The following five observations were central to the organization of the Testbed-19 effort.

Most of the changes required to support non-terrestrial missions are in the coordinate reference system definitions (part of ISO 19111).

The coordinate transformation framework of ISO 19111 is applicable with no change. However, its GML encoding is not widely supported in software.

GeoPose can be an alternative (not necessarily easier) encoding for associating non-terrestrial coordinate reference systems and coordinate transforms.

The 4D spacetime coordinate systems required for interplanetary space are also useful for terrestrial applications. Examples include satellite communications and solar radiation storm forecasts.

Further work on Moving Features and Sensor Integration will play an essential role in enabling non-terrestrial spatial infrastructures.

Agreeing on these five observations allowed Testbed-19 work to proceed in three threads, each of them described in its own chapter. The first thread focused on coordinate reference systems and coordinate transformations. The second thread focused on the use of 4D GeoPose (NeoPose) for highly dynamic non-terrestrial and terrestrial applications. The third thread advanced the work on Moving Features and Sensor Integration with an eye toward incorporation of the work from the first two threads.

## 1.1. Thread One — ISO 19111+

The first chapter of this ER addresses extensions to ISO 19111 (ISO 19111+). These extensions will allow ISO 19111 to describe both non-terrestrial planetary coordinate reference systems and non-planetary coordinate reference systems in free space. These extensions are documented using UML diagrams, XSD schemas, and Java/Python interfaces which were implemented in Open Source software. Links to source codes on GitHub are given in Annex B (XML) and Annex C (Java).

## 1.2. Thread Two — NeoPose

The second chapter of this ER describes adaptations of GeoPose (NeoPose) for non-terrestrial applications. Once off the surface of the Earth, there is no single overarching coordinate reference system. A measurement may be expressed in the local (proper) reference system or in that of an observing entity. The value of a measurement may be expressed in an unlimited number of reference systems which calls for a framework to support coordinate transformations between arbitrary coordinate reference systems. ISO 19111 is one such framework, but it is constrained by the above-cited lack of GML support in popular software. With a few modifications, GeoPose would also be well suited for that purpose. This chapter explores the specific modifications to GeoPose needed to create a NeoPose Standard.

## 1.3. Prototyping ISO 19111+ and NeoPose

The third and fourth chapters describe the two prototype environments developed for Testbed-19 as well as the performance of the ISO 19111+ and NeoPose products in those environments.

Chapter three describes exercises based on the NASA Double Asteroid Redirection Test (DART) mission. DART was a NASA mission which sought to deflect a moonlet in orbit around an asteroid. This scenario is interesting in that it involves high positional accuracy for multiple moving bodies, moving at high velocities, in deep space. It is a good proxy for a deep space tracking and rendezvous mission.

Chapter four describes exercises using the Hillyfields Bubble. The Hillyfields Bubble is a multipurpose dataset captured in support of the development of Augmented Reality/Metaverse architectures and infrastructure prototypes. These data were collected over the UK Ordnance Survey Headquarters in Southampton, UK on the 25th and 26th of April, 2023. The large number of moving objects involved, as well as the number and variety of moving sensors, makes this a good proxy for non-terrestrial planetary missions.

## 1.4. Thread Three — Moving Features and Sensor Integration

Chapter five returns to the Earth and addresses issues involving data synchronization from multiple sources. This chapter advances work on Testbed-18 Moving Features and Sensor Integration through prototypes and implementations of a set of Road Network use cases. The geotagged video use cases were selected from those documented in the Testbed-18 Moving Features Engineering Report (OGC 22-016r3) and derived from discussions with UK national road network authorities. Concurrent video data were captured with GeoPose by multiple cameras in a collaborative effort hosted by Ordnance Survey in April 2023. The captured data were encoded based on the OGC GeoPose Standard. These data included many moving objects observed by static and moving devices to study how geotagged video and sensor data could be enriched by synchronization and aggregation over time.

# 2. Terms and definitions

This document uses the terms defined in OGC Policy Directive 49, which is based on the ISO/IEC Directives, Part 2, Rules for the structure and drafting of International Standards. In particular, the word “shall” (not “must”) is the verb form used to indicate a requirement to be strictly followed to conform to this document and OGC documents do not use the equivalent phrases in the ISO/IEC Directives, Part 2.

This document also uses terms defined in the OGC Standard for Modular specifications (OGC 08-131r3), also known as the ‘ModSpec’. The definitions of terms such as standard, specification, requirement, and conformance test are provided in the ModSpec.

For the purposes of this document, the following additional terms and definitions apply.

Some of the concepts encountered in this Engineering Report are not commonly encountered in the Geospatial field. Others, while they may look familiar, take on a slightly different meaning. Those terms are defined in this section. For more complex cases, a more detailed description in provided in Annex E. The definitions in this section provide links to associated descriptions where they are appropriate.

## 2.1. **Barycenter**

the center of mass of two or more bodies that orbit one another

NOTE

A barycenter is a dynamical point, not a physical object.

[**SOURCE:** Wikipedia]

## 2.2. **Coordinate**

one of a sequence of numbers designating the *position* (Clause 2.16) of a *point*

NOTE

In a spatial

*coordinate reference system*(Clause 2.3), the*coordinate*numbers are qualified by units.NOTE

See also Clause 2.5.

[**SOURCE:** ISO 19111]

## 2.3. **Coordinate Reference System**

coordinate system that is related to an *object* (Clause 2.15) by a *datum* (Clause 2.6)

NOTE

For geodetic and vertical

*datums*(Clause 2.6), the*object*(Clause 2.15) will be a celestial body such as Earth.

[**SOURCE:** ISO 19111]

## 2.4. **Coordinate System**

set of mathematical rules for specifying how *coordinates* (Clause 2.2) are to be assigned to *points*

[**SOURCE:** ISO 19111]

## 2.5. **Coordinate tuple**

tuple composed of coordinates (Clause 2.2)

NOTE

The number of coordinates in the coordinate tuple equals the dimension of the coordinate system; the order of coordinates in the coordinate tuple is identical to the order of the axes of the coordinate system.

[**SOURCE:** ISO 19111]

## 2.6. **Datum**

parameter or set of parameters that realize the *position* (Clause 2.16) of the origin, the scale, and the orientation of a *coordinate system* (Clause 2.4)

[**SOURCE:** ISO 19111]

## 2.7. **Domain**

well-defined set

NOTE

*Domains*are used to define the*domain*set and range set of*attributes*, operators, and functions.

[**SOURCE:** ISO 19109, Clause 4.8]

## 2.8. **Domain <general vocabulary>**

distinct area of human knowledge to which a terminological entry is assigned

NOTE

Within a database or other terminology collection, a set of

*domains*(Clause 2.7) will generally be defined. More than one*domain*(Clause 2.7) can be associated with a given*concept*.

[**SOURCE:** ISO 19104, Clause 4.11]

## 2.9. **Geodesic**

a geodesic is a curve representing in some sense the shortest path between two points in a surface

NOTE

It is a generalization of the notion of a “straight line”.

[**SOURCE:** Wikipedia]

## 2.10. **Global Reference System**

Coordinate Reference System of the trajectory of the reference point

NOTE

See also Annex E.4.

[**SOURCE:** ISO 19141]

## 2.11. **Grid**

covering of a multi-dimensional region using quadrilateral shapes (in the 2D case)
or their *n*-dimensional generation (in the nD case) with no overlaps and gaps

[**SOURCE:** ISO 19123]

## 2.12. **Inertial Reference System**

frame of reference where a body that is subject to no net force moves with constant velocity in a straight line, at least locally

SOURCE

Matthew Baring, “Lecture Notes for PHYS 532”, Rice University, Spring 2023.

NOTE

The “body” may be the barycenter (Clause 2.1) of a group of bodies.

NOTE

See also Annex E.3.

## 2.13. **Local Reference System**

local engineering coordinate system established using the object reference point as its origin

NOTE

See also Annex E.4.

[**SOURCE:** ISO 19141]

## 2.14. **Location**

particular *place* or *position* (Clause 2.16)

NOTE

*Locations*are physical*places*, typically on the surface of the Earth, although*locations*can be relative to other, non-earth centric coordinate reference systems.NOTE

*Locations*can be a single*point*, a centroid, a minimum bounding rectangle, or a set of vectors.NOTE

A

*location*should be persistent over time and does not change.

[**SOURCE:** ISO 19112, Clause 3.1.3]

## 2.15. **Object**

entity with a well defined boundary and identity that encapsulates state and behavior

NOTE

This term was first used in this way in the general theory of object oriented programming, and later adopted for use in this same sense in UML. An

*object*is an instance of a*class*.*Attributes*and relationships represent state.*Operations*, methods, and state machines represent behavior.

[**SOURCE:** ISO 19103]

## 2.16. **Position**

data type that describes a *point* or *geometry* potentially occupied by an *object* (Clause 2.15) or person

NOTE

A

*direct position*is a semantic subtype of*position*.*Direct positions*as described can only define a*point*, and therefore not all*positions*can be represented by a*direct position*. That is consistent with the “is type of” relation. An ISO 19107 geometry is also a*position*, but not a*direct position*.

[**SOURCE:** ISO 19133]

## 2.17. **Reification**

process by which an abstract idea about a computer program is turned into an explicit data model or other object created in a programming language

[**SOURCE:** Wikipedia]

## 2.18. **Reference Frame**

parameter or set of parameters that realize the position of the origin, the scale, and the orientation of a coordinate system

[**SOURCE:** ISO 19111]

## 2.19. **Series expansion**

technique that expresses a function as an infinite sum, or series, of simpler functions

NOTE

It is a method for calculating a function that cannot be expressed by just elementary operators (addition, subtraction, multiplication, or division).

NOTE

The resulting so-called series can often be limited to a finite number of terms, thus yielding an approximation of the function.

[**SOURCE:** Wikipedia]

## 2.20. **Serialization**

process of translating a data structure or object state into a format that can be stored (e.g., files in secondary storage devices, data buffers in primary storage devices) or transmitted (e.g., data streams over computer networks) and reconstructed later (possibly in a different computer environment)

[**SOURCE:** Wikipedia]

## 2.21. **World Reference System**

Spatial Coordinate Reference System object which relates the positions of features in the real world.

NOTE

See also Annex E.4.

[**SOURCE:** OGC 19-045r3]

# 3. Non-Terrestrial Reference Systems

A Coordinate Reference System (CRS) is a framework that uses coordinates to precisely measure locations in space and time.
The ISO 19111 Standard, also available as OGC Topic 2, provides an abstract model for this framework,
together with a framework for coordinate conversions and transformations.
While this model was initially designed for coordinates on the surface of the Earth,
it also defines structures, such as `EngineeringCRS`, that can support locations which are not defined relative to the Earth.
Those structures are already capable of providing *some* CRS definitions for use in free space.
The Testbed-18: Reference Frame Transformation Engineering Report (OGC 22-038r2)
proposed extensions to those structures for more complete and accurate definitions of non-terrestrial Coordinate Reference Systems.

ISO 19111 is an abstract model defined in the Unified Modeling Language (UML). It is not intended to be implemented directly. Rather, Implementation Standards are generated from the abstract model. These Implementation Standards provide a machine-readable representation of the abstract model, tailored for a specific implementation domain. These “implementations” are similar to, but not the same as the “implementations” concept from Model Driven Architecture (MDA). To distinguish them, this Engineering Report uses the reification term (Clause 2.17). Some reifications cover only a subset of ISO 19111 for simplicity reasons.

Table 1 — Reifications of ISO 19111 abstract model

Standard or product | Type | Reification of | Cover all the UML? |
---|---|---|---|

EPSG geodetic dataset | Dataset | ISO 19111:2019 | No |

ISO 19162:2019 — WKT 2 | Encoding | ISO 19111:2019 | No |

ISO 19136:2007 — GML | Encoding | ISO 19111:2007 | Yes |

OGC 09-083r4 — GeoAPI 3.0 | API | ISO 19111:2007 | Yes |

PROJ-JSON (community) | Encoding | ISO 19111:2019 | To be verified |

The following software packages are examples of implementations of above-cited reifications.

Table 2 — Some known implementations of reifications of ISO 19111 abstract model

External project | Implementation of | License | Source code |
---|---|---|---|

Apache SIS | OGC 09-083 — GeoAPI 3.0.2 | Apache 2 | GitHub |

PROJ-JNI | OGC 09-083 — GeoAPI 3.0.2 | MIT | GitHub |

OGC Testbed-18 participants evaluated ISO 19111 for use on non-Earth planets and in free space. The results of that analysis were documented in OGC 22-038r2. This Testbed-19 Engineering Report (ER) proposes extensions to the following Standards with programmatic definitions of concepts introduced in Testbed-18.

ISO 19111, extended with UML diagrams as presented in this section.

ISO 19136, extended with XSD schemas as presented in Annex B.1.

GeoAPI 3.0, extended with Java and Python interfaces as presented in Annex C.

The extensions to each of those standards should be assigned to an OGC working group for discussion or standardization as follows.

The CRS Standards Working Group (SWG) can evaluate the UML diagrams for eventual incorporation in OGC Topic 2 and ISO 19111.

The Planetary Domain Working Group (DWG) can evaluate the XML schema for eventual publication on http://schemas.opengis.net/gsp/.

The GeoAPI SWG can evaluate the new interfaces for eventual incorporation in the GeoAPI main module.

As part of the Testbed-19 work, these extensions were further validated through implementation in a branch of the Apache SIS implementation of the OGC GeoAPI 3.0.2 reification.

## 3.1. Abstract model overview

The ISO 19111 abstract model contains two main parts:
Classes for the definition of coordinate reference systems (`CRS` and related classes such as `Datum`),
and classes for the definition of coordinate operations (`CoordinateOperation` and related classes such as parameters).
The latter part will be discussed in the Coordinate transformations section of this ER.
The following section concerns the first part, the Coordinate Reference System (CRS).
The following UML represents some ISO 19111 classes relevant to this section, together with proposed extensions.
The tan boxes are classes defined in ISO 19111, while the blue boxes are proposed extensions.

Figure 1 — Extensions to ISO 19111

`MinkowskiCS` is introduced as a spatiotemporal equivalent of `CartesianCS`.
Note that `MinkowskiCS` is defined as a coordinate System (CS), not a coordinate reference System (CRS).
Expectations for coordinate systems are described in the next section.
Note also that `MinkowskiCS` is defined as a subtype of `CartesianCS`
since the temporal axis is considered orthogonal to the spatial axes
and the unit of measurement is the same (see Clause 3.2.1.4).
A consequence of this hierarchy is that `MinkowskiCS` can be associated to `GeodeticCRS` and `EngineeringCRS`.
By contrast, new CS classes would not be defined as direct subtypes of `CoordinateSystem`.

### 3.1.1. Discussion on keeping the Coordinate Systems simple

An ISO 19111 coordinate system is only a set of axes at no particular location,
together with geometry formulas that are implied by the coordinate system *class*
(not to be confused with the coordinate system *unions*,
which are not covered in this section).
For example, the use of a `CartesianCS` implies that angles, distances, surfaces, volumes, *etc.*
are computed by formulas derived from Euclidean geometry.
The use of a `CylindricalCS` or `SphericalCS` implies different sets of formulas for computing geometric properties.
But all `CoordinateSystem` classes defined by ISO 19111 imply relatively simple and well-known formulas.
This simplicity is necessary for performing tasks such as computing intersections
or solving integral equations for computing surfaces.
The most complex coordinate system class defined by ISO 19111 is the `EllipsoidalCS`.
In that latter case, solving the integral equations requires series expansions (Clause 2.19),
as done in map projections or geodesic (Clause 2.9) calculations.
Extensions to ISO 19111 such as `MinkowskiCS` should not be much more complex.

Figure 2 — ISO 19111 Coordinate Systems

The simplicity mandated by the approach defined in the above paragraph may seem restrictive,
but is an unavoidable step applied even with complex topographies.
Complexity is usually managed by splitting a surface into small cells.
Inside each cell, the “simple” mathematics of a coordinate system is assumed to be a good approximation.
For example, the figure below zooms in on a single cell of a complex surface.
If a software package computes the shortest path (the geodesic) between two points inside that cell
by applying linear interpolations between (*x*₁, *y*₁, *z*₁) and (*x*₂, *y*₂, *z*₂) coordinate tuples,
then that software is implicitly using a Cartesian coordinate system.
The cells size (grid resolution) is chosen in such a way that
approximating the real surface by a flat surface inside the cell area is considered an acceptable error.

Figure 3 — Surface with local Cartesian CS in each cell

In the above example, the shortest path inside a cell can be computed using the global (Clause 2.10) Cartesian coordinate system for the whole grid (gray axes), or a Cartesian coordinate system which is local (Clause 2.13) to the cell (red axes). In the example, both coordinate systems produce the same results, but the local CS is simpler because it can be reduced to a two-dimensional coordinate system (i.e., the perpendicular axis can be omitted) if all points lie on the surface. Coordinate transformations between those two systems are not discussed in this section, as these transformations require Coordinate Reference Systems (CRS) to provide context for the Coordinate Systems (CS).

The local coordinate system does not need to be of the same class as the global one.
For example, the local CS could be an `EllipsoidalCS` if that is a better
approximation of the real geometry inside the area of that cell, as illustrated in the figure below.
In this case, doing geodesic calculations in the local CS
produces different results than the cases illustrated in Figure 3.

Figure 4 — Surface with local ellipsoidal CS in each cell

In the above examples, calculations must be limited to a single cell. If the feature of interest spans more than one cell, then calculations must be performed separately in each cell and the results combined in some way. ISO 19111 does not specify how multi-cell calculations should be done.

An application can choose to use the same `CoordinateSystem` (CS) for all cells,
even if axis directions vary slightly between different cells.
Using a common CS means that all cells use the same geometric formulas
with axes having the same units of measurement and the same orientations relative to the cell.
The precise orientations of the axes are encapsulated in the Reference Frame,
which is not part of a Coordinate System (it is part of a Coordinate *Reference* System).
Using a uniform Coordinate System makes combining the results of adjacent cells easier, for example, by stating that all cells use a `CartesianCS` with measurements in meters.
Therefore, volumes or areas computed in adjacent cells can be summed without unit conversions.
This is true even for `EllipsoidalCS` using ellipsoids of different sizes and shapes.
In the ISO 19111 model, the shape of the ellipsoid is not a property of the Coordinate System.
Rather, it is a property of the Geodetic Reference Frame which, together with the `EllipsoidalCS`,
forms a Geodetic Coordinate Reference System.

### 3.1.2. Discussion on CRS domain of validity versus CS simplicity

An ISO 19111 Coordinate *Reference* System (CRS) is associated with exactly one Coordinate System (CS),
except Compound CRS, which is omitted for the following discussion.
A CRS is also associated, through subclasses of the `datum` class,
with information about the CRS origin and “absolute” axis orientations (e.g., relative to stars).
Consequently each cell in a grid such as Figure 3 or Figure 4
has its own local `CRS` because each cell has a different reference frame
for different origin and “absolute” axis directions.

Coordinates can be transformed from the global CRS to the local CRS of a particular cell
before computing geometric properties in a given cell.
Note that in this scenario, the complexity of the irregular surface
appears in the process of *transforming* coordinates from the global CRS to a local CRS.
This complexity does not appear in any coordinate system before or after the transformation.
In ISO 19111 modeling, the complexity is in `CoordinateOperation`, not in `CoordinateSystem`.

Figure 5 — ISO 19111 Operations and Coordinate Reference Systems

Given the restriction that each ISO 19111 CRS (excluding `CompoundCRS`)
shall be associated with exactly one CS,
and given that a CS should be mathematically simple,
the CRS in Figure 3 and Figure 4 can be based on one of the following choices.

The global three-dimensional Cartesian coordinate system, in which case the complex surface plays no role. That surface is a feature

*inside*the CS domain, but does not define the CS itself and is not involved in any calculation between pairs of (*x*,*y*,*z*) coordinate tuples.A global two-dimensional coordinate system resulting from a curve-fitting of the complex surface. The result can be the surface of a plane, cylinder, sphere, ellipsoid, or something else defined outside ISO 19111. That approximation can be very good in some cases (e.g., Earth surface approximated by an ellipsoid). This option is nevertheless not discussed further in this Engineering Report.

A local two-dimensional coordinate system on the complex surface, i.e., the CS of one of the cells. That coordinate system may be Cartesian or ellipsoidal (among others) as illustrated in the two above examples, depending on the desired compromise between accuracy and mathematical simplicity.

Each alternative has pros and cons. Option #1 allows the referencing of any point anywhere in the domain covered by the global CRS. However, it does not allow accurate geodesic calculations (e.g., shortest path on the surface) between pairs of points. Conversely, option #3 is limited to a small area, but allows much more accurate geodesic calculations in that area.

Note also that complex numerical models, such as those based on fluid mechanic (meteorological and oceanographical models) or based on the equations of Einstein’s General Relativity (Annex E.2), do not change the fundamental approach. Those numerical models still need to split a large space into a grid (Clause 2.11) of cells small enough to allow the use of “simple” mathematics inside each cell with acceptable errors. The grids may be more sophisticated than grids of equilateral cells, but they are still grids with cells delimited by analytic functions.

The above discussion implies that if geometric properties or geodesics paths are required with high accuracy,
then the associated calculations may require a CRS restricted to a local area.
However, the area can be made larger by a choice of coordinate system class,
or by a choice of kind of acceptable errors.
This is partially illustrated for one-dimensional coordinate systems by the figure below.
However, the discussion should be thought of as if the coordinate systems were two- or three-dimensional.
The left side shows the case when Cartesian coordinate systems are wanted.
No `CartesianCS` can be a good fit for the whole mountain,
so the calculations must be restricted to smaller areas.
The calculations can only be done between pairs of points on the same side of the mountain.
If a calculation needs to be done between two points that are on each side of the mountain,
it needs to be split into two parts, computed independently on each side, then combined somehow.
In the ISO 19111 model, those two computations are done in two different Coordinate Reference Systems.
However, if the coordinate system is based on a quadratic curve instead of straight lines,
as shown in the right side of the figure below,
then it becomes possible to do computation on the whole mountain with a single CRS.
Therfore, computation between points on different sides of the mountain is no longer a problem.

Figure 6 — More complex coordinate system covering larger area

In a two-dimensional coordinate system, the use of `EllipsoidalCS` instead of `CartesianCS`
allows covering a larger surface with a continuous function in a way similar to Figure 6.
In the case of the Earth, using `EllipsoidalCS` is often an approximation good enough
for covering the whole planet with a single CRS, such as WGS84.
However, it does not change the general principle that `EllipsoidalCS` is still an approximation.
On some irregular bodies, that approximation may not be good enough to support the use of a
single `EllipsoidalCS` for the whole body with the desired accuracy.

### 3.1.3. Coordinate System versus Coordinate Transformation roles in accuracy

A coordinate system based on a cubic curve would be more accurate or would cover a yet larger area
than the examples shown in Figure 6,
but at the cost of more mathematical complexity.
Because the equations for intersections, surfaces, *etc.* can quickly become unsolvable,
that mathematical complexity cannot be increased indefinitely.
For example, ellipsoidal equations are only of degree 2, and already very difficult to solve.
To cover a larger area, an alternative to increasing mathematical complexity
is to keep a simpler coordinate system, such as `CartesianCS`, but accept some errors.
For example, it is possible to favor accuracy in surface calculations at the expanse of accuracy in angles, or conversely.
Controlling those errors is the art of map projections.

The overall accuracy does not depend only on the accuracy of formulas in the chosen coordinate system. Overall accuracy also depends on the accuracy of the transformation used for expressing points in that coordinate system. For example, Figure 7 below illustrates the results of a numerical experiment done at a point located at 45°N on Earth. The following test was repeated at distances varying from 1 meter to 1000 kilometers around the above-cited point.

A circle is drawn around the center point (0°E 45°N) with a radius equal to the distance to test. The circle is determined by computing the locations of 360 points (each point is separated by 1°) using geodesic formulas on an ellipsoid published by Karney (2013).

Distances and azimuths (horizontal angles from north) are computed for paths from the center point to the above-cited 360 points using the following methods.

Using

`SphericalCS`formulas (distances are the arc lengths):On an authalic sphere (sphere of the same surface as the ellipsoid) using the geographic coordinates as-is; and

On the same authalic sphere, but with geographic coordinates converted from the geodetic latitudes on the flattened sphere (Earth) to the geocentric latitudes on the authalic sphere. Those latitudes differ by about 21 kilometers. This operation is identified as a “datum shift” in Figure 7.

Using

`CartesianCS`formulas (distances computed by the Pythagorean formula):After projection to “Mercator (variant B)” with standard parallel at 45°; and

After projection to “Lambert Conic Conformal (2SP)” with the two standard parallels at 45°.

The above calculations are compared with the expected distances and azimuths, which are the values used for drawing the circle in the first step.

The *Y* axis below shows the relative error, as a percentage of the distance shown on the *X* axis.
For example, an error of 0.25% for a distance of 10 kilometers is an error of 25 meters.
The error bars correspond to one standard deviation.

Figure 7 — Relative errors of distances around 0°E 45°N computed with different methods

An observation is that naive application of spherical formulas on Earth,
with WGS84 latitudes and longitudes used directly, is not very good compared to other approaches.
The relative errors are constant at around 0.13% over the range of tested distances,
and the standard deviation is almost as large.
A more sophisticated calculation converting the latitude values before applying spherical formulas gives better results,
with relative errors at around 0.06% and negligible standard deviations.
However, and maybe counter-intuitively, the use of `CartesianCS` gives better results than `SphericalCS` over small distances.
Two factors contribute to that accuracy:

the use of a “standard parallel” projection parameter configures the map projection for optimal accuracy around the latitude used in this test, namely 45°N; and

the Mercator and Lambert Conic Conformal map projection formulas take into account the flattened shape of Earth.

On distances small enough, the geometrical distortions caused by using `CartesianCS`
are smaller than the errors caused by ignoring Earth flatness in spherical formulas
or caused by using a global sphere radius which may not be optimal for the test area.
(Note: a sphere with geocentric radius computed at 45°N was also tested,
but the results are not shown because they were similar to the authalic sphere case).
In this test, the use of “Mercator (variant B)” projection is more accurate than spherical formulas for distances up to 100 kilometers
and the use of “Lambert Conic Conformal (2SP)” is still more accurate even at 1000 kilometers.

The results of using “Popular Visualization Pseudo Mercator” are not shown in this graph
because the errors are around 41% and would not fit in the *Y* axis scale.
Those errors are caused mostly by the scale factor not well suited to 45°N.
Other factors contributing to the errors are the facts that this projection ignores Earth flatness
and uses the equatorial radius instead of some globally better value such as the authalic radius
(radius of the authalic sphere).

### 3.1.4. Implications for MinkowskiCS

`MinkowskiCS` is a four-dimensional coordinate system developed for use in Special Relativity.
It ignores the spacetime curvature caused by gravity according to General Relativity (Annex E.2).
However, even in the context of General Relativity, the Minkowski coordinate system can be useful
as an approximation good enough at short distances from the object of interest.
Such an approximation is like the use of `CartesianCS` in map projections,
which are flat approximations of a curved surface considered good enough inside a known region.

Because Cartesian and Minkowski coordinate systems are flat spacetime approximations, it is tempting to conclude that geodesic (Clause 2.9) calculations performed in those coordinate systems can only be less accurate than geodesic calculations performed in a coordinate system taking the curvatures in account, such as a spherical coordinate system. But as shown in Figure 7, this is not necessarily the case because the overall accuracy depends on two factors: the fitness of the coordinate system to the local geometry and the accuracy of the coordinate operation applied to get there (Clause 3.1.3).

The choice of a coordinate system impacts the complexity of a fundamental object of study in General Relativity.
In the context of Einstein’s relativity, spacetime geometry is described by a *metric tensor*.
The metric can be represented as a matrix and defines how distances, angles, and other geometry properties are computed.
While those metrics are of particular importance in relativity,
this concept can be used in classical geometry as well.
The Euclidean metric used in `CartesianCS` is the simplest:

${g}_{ij}=\left[\begin{array}{ccc}1& 0& 0\\ 0& 1& 0\\ 0& 0& 1\end{array}\right]$ (1)

Let *p* be the coordinate tuple of a point in space or space-time,
and *p _{i}* (or

*p*) be one of the coordinates of that tuple. For a small displacement

_{j}*dp*, the small distance

*ds*is given by:

$d{s}^{2}=\sum _{i}\sum _{j}{g}_{ij}\cdot d{p}_{i}\cdot d{p}_{j}$ (2)

For the Euclidean metric, the development gives the familiar Pythagorean formula:

$d{s}^{2}=\left(\begin{array}{c}+dx\cdot dx+0+0\\ +0+dy\cdot dy+0\\ +0+0+dz\cdot dz\end{array}\right)=d{x}^{2}+d{y}^{2}+d{z}^{2}$ (3)

By comparison, the metric at the surface of a `SphericalCS` is as below,
assuming a radius of 1, coordinates in (latitude, longitude) order and units in radians.
The main thing to note is that this metric is not constant.
The matrix varies at every position, because it depends on the latitude φ.
Consequently, computing the geodesic distance *s*² on a non-short path requires resolving an integral equation
(not done in this ER).

${g}_{ij}=\left[\begin{array}{cc}1& 0\\ 0& cos\left(\varphi \right)\end{array}\right]$ (4)

`MinkowskiCS` can be seen as `CartesianCS` generalized to the spatiotemporal domain.
Its metric is shown below, using the (- + + +) sign convention.
Coordinates are in (*t*, *x*, *y*, *z*) order with the time coordinate already multiplied by *c*,
as required by the `MinkowskiCS` definition proposed in this ER:

${g}_{ij}=\left[\begin{array}{cccc}-1& 0& 0& 0\\ 0& 1& 0& 0\\ 0& 0& 1& 0\\ 0& 0& 0& 1\end{array}\right]$ (5)

In the same way as the metric on the surface of a `SphericalCS` may be considered of manageable complexity,
there are some alternatives to `MinkowskiCS` which are also of manageable complexity.
For example, assuming a system with spherical symmetry residing in a vacuum,
then the Schwarzschild metric (Annex E.7) may provide
a computationally feasible solution for *ds*² in Formula (2).
This ER does not propose classes for modeling those alternatives yet,
but it is expected that if `MinkowskiCS` is accepted, other classes could follow the path.

`MinkowskiCS` may not provide sufficient accuracy in some situations
in the same way as `CartesianCS` on the Earth’s surface is not accurate when the area of interest becomes too large.
The accuracy on Earth can be improved by “upgrading” `CartesianCS` to `EllipsoidalCS`.
Likewise, the accuracy in a relativist context may be improved by “upgrading” `MinkowskiCS`
to another relativist coordinate system using a more complex metric.
However, those “upgrades” cannot be such that the geometry formulas become unsolvable.
When the combination of a large region and high accuracy exceeds what can be solved,
splitting the region in smaller cells as illustrated in Figure 3 become unavoidable.

This Engineering Report does not explore how to combine calculations done in adjacent cells.
Doing so may require the participation of other OGC working groups such as
Discrete Global Grid Systems (DGGS).
However, those combinations would probably require coordinate transformations between cells.
This is where the complexity of geoid surfaces or gravitational fields are involved.
But this complexity is in the *transformation* between two CRSs, not in the CRSs themselves.

### 3.1.5. Engineering CRS for spacecraft

The coordinate reference system of a spacecraft can be described by an `EngineeringCRS`.
This type of CRS was discussed in OGC 22-038r2 and an example is provided with the `DART.xml` file.
ISO 19111 restricts the set of CS classes that can be associated to an `EngineeringCRS`.
The allowed CS classes are affine, Cartesian, cylindrical, linear, ordinal, polar, and spherical implying that `MinkowskiCS` is also accepted because it is a subtype of `CartesianCS`.
However, this is not necessarily the case for other metrics such as Schwarzschild (Annex E.7).
Relaxing this restriction on CS type is proposed in Clause 3.2.3.3.

## 3.2. Recommendations

This section describes the ISO 19111 extensions exercised in this Testbed-19. Each extension is expressed in the following three different ways:

As Unified Modeling Language (UML) diagrams in this ER.

As an XML schema extending the Geographic Markup Language (GML) Standard.

As Java interfaces in a branch of the OGC GeoAPI Standard.

Each of those recommendations can be assigned to an OGC working group for discussion or standardization as follows.

The CRS SWG can evaluate the UML diagrams for eventual incorporation in OGC Topic 2 and ISO 19111.

The Planetary DWG can evaluate the XML schema for eventual publication on http://schemas.opengis.net/gsp/.

The GeoAPI SWG can evaluate the new interfaces for eventual incorporation in the GeoAPI main module.

This section provides recommendations for ISO 19111 only. The recommendations for reifications such as GML and GeoAPI are presented in Annex B.1 and Annex C because they are derivatives of the recommendations for ISO 19111.

### 3.2.1. Additions to OGC Topic 2/ISO 19111

Most classes listed below are new and do not require modifications to the ISO 19111 Standard,
as the classes can be specified as an extension in a separate document.
An exception is `CelestialBody` which may need to be included in ISO 19111
if an association from `Datum` to `CelestialBody` is added.

#### 3.2.1.1. InertialCRS

**Description:**
InertialCRS is a 2-, 3-, or 4-dimensional coordinate reference system associated with an Inertial Reference Frame.
When associated to a Cartesian coordinate system, axis directions can be `geocentricX`, `geocentricY`, and `geocentricZ`.
However, those geocentric axes are not rotating with the celestial body.
Instead, these axes are often pointing toward distant celestial objects.

**Properties:**
This class inherits the attributes and associations defined by `SingleCRS` with no addition.
However, the `datum` association is restricted to the `InertialReferenceFrame` subtype.
Such restrictions are called *type covariances*.
The association is repeated below for specifying this restriction.

Table 3 — InertialCRS properties

Property | Type | Obligation | Description |
---|---|---|---|

datum | InertialReferenceFrame | Mandatory | Association to the inertial datum used by this inertial CRS. |

NOTE

Inertial CRS provides a frame where object motions can be easier to calculate, because objects subject to no net force move in straight lines. It would not be the case in a non-inertial CRS.

NOTE

A planet will most likely use a Geodetic Coordinate Reference System. However, Inertial Coordinate Reference Systems can nevertheless be associated to planets as intermediate steps in a chain of coordinate operations from one body to another body. For example, for describing the location of a spacecraft relative to Earth. See Clause 3.4 for a use case with DART data.

#### 3.2.1.2. InertialReferenceFrame

**Description:**
An InertialReferenceFram is an inertial datum attached to a body or barycenter (Clause 2.1),
subject to no net force and therefor moving at constant velocity in straight line.
The inertial datum MAY be centered on a defined ellipsoid (or sphere).
Alternatively, the inertial datum may be associated to a Cartesian (3D case),
or to a Minkowski (4D case) coordinate system centered in the ellipsoid (or sphere).

**Properties:**
Inertial Reference Frames have the same properties as Geodetic Reference Frames,
except that the ellipsoid and the prime meridian are optional,
and the “prime meridian” attribute is named “prime direction.”
Contrarily to the geodetic case, the prime direction of an Inertial Reference Frame
is not defined by the location of a feature on the celestial body.
Such a prime meridian would be of little use because its coordinate would be constantly changing with a planet’s rotation.
Instead, the prime direction is defined relative to a distant feature such as a star.
For example, the Ecliptic coordinate reference system defines the primary direction by the March equinox.

Table 4 — InertialReferenceFrame properties

Property | Type | Obligation | Description |
---|---|---|---|

celestialBody | CelestialBody | Optional | Association to the celestial body used by this inertial datum. |

ellipsoid | Ellipsoid | Optional | Association to the ellipsoid used by this inertial datum. |

primeDirection | PrimeMeridian | Optional | Association to the prime meridian used by this inertial datum. |

NOTE

Inertial Reference Frames can be used for highly irregular objects such as asteroids. These may not have an ellipsoid nor prime meridian. Planets with a solid surface will most likely use Geodetic Coordinate Reference Frames instead, but Inertial Reference Frames may still be needed as coordinate transformation steps.

NOTE

Inertial Reference Frames may be required for gas planets or stars that are not rotating as a rigid body. For those bodies, it is difficult to define a Geodetic Reference Frame if there is no stable feature for defining a rotation rate. But the ellipsoid attribute is still relevant for those bodies.

NOTE

Inertial Reference Frames are not necessarily centered on a celestial body. The frame may be centered, for example, on the barycenter (Clause 2.1) of a solar system. In the latter case, the frame origin may be located in the vacuum.

NOTE

NASA SPACE uses the “Ephemeris Object” term instead of “Celestial body.”

#### 3.2.1.3. CelestialBody

**Description:**
CelestialBody is a name or identifier of the star, planet, asteroid, or other celestial body
for which a reference frame is defined.

**Properties:**
Since `CelestialBody` is an `IdentifiedObject`, it inherits the `name` and `identifiers` properties.
The celestial body shall be identified by its name, optionally with aliases,
and optionally by one or many identifiers valid in some registries.

#### 3.2.1.4. MinkowskiCS

**Description:**
MinkowskiCS is a 4-dimensional coordinate system.
The three spatial dimensions give the position of points relative to orthogonal straight axes.
The fourth dimension gives the position in time since an epoch.
All axes shall have the same length unit of measure,
with time expressed as the distance covered by light in the vacuum during the elapsed time.
A `MinkowskiCS` shall have exactly four `axis` property elements.

**Properties:**
No additional properties compared to all other `CoordinateSystem` classes.

### 3.2.2. Additions to OGC WKT 2 / ISO 19162

This section proposes new keywords for the Well Known Text (WKT) 2 format. Those additions require changes in the definitions provided in Backus-Naur form (BNF). The following table shows a summary of new WKT keywords. Those new keywords should be added (except Minkowski) to the Well-known text representation of coordinate reference systems Standard (OGC 18-010r11) §6.6 — Reserved keywords, with “TBD” replaced by the actual section numbers where the keywords are defined.

Table 5 — Summary of new WKT keywords

Keyword | BNF element | Clause in which defined |
---|---|---|

alias | <alias keyword> | TBD |

celestialBody | <celestial body keyword> | TBD |

inertialCRS | <inertial CRS keyword> | TBD |

Minkowski | <spatial cs type> | 7.5.1 |

#### 3.2.2.1. Alias

In OGC 18-010r11 §7.3, rename the section from “Scope, extent, identifier, and remark”
to “Scope, extent, identifier, *alias*, and remark”.
In the requirement for `<scope extent identifier remark>`,
add the following optional item before the identifiers:

[ { <wkt separator> <alias> } ] ...

Figure 8 — BNF reference to alias

Add a section with the following content:

**Requirement:** The WKT representation of an `<alias>` shall be:

<alias> ::= <alias keyword> <left delimiter> <alias text> <right delimiter>

<alias keyword> ::= ALIAS

<alias text> ::= <quoted Latin text>

Figure 9 — BNF definition of alias

#### 3.2.2.2. CelestialBody

In the WKT specification, insert a new section before “8.2.1 Ellipsoid” as follows.

The `<celestialBody>` object is an attribute of `<geodetic reference frame>`.
The WKT representation of a celestial body shall be:

<celestialBody> ::= <celestial body keyword> <left delimiter>

<celestial body name> <right delimiter>

<celestial body keyword> ::= CELESTIALBODY

<celestial body name> ::= <quoted Latin text>

Figure 10 — BNF definition of celestial body

In section 8.2.3, update the first cell of the requirement table by the following line
(the difference compared to the existing standard is the insertion of
`[<wkt separator> <celestialBody>]`).

<geodetic reference frame keyword> <left delimiter> <datum name> <wkt separator>

[ <wkt separator> <celestialBody> ] <ellipsoid> [ <wkt separator> <datum anchor> ]

[ { <wkt separator> <identifier> } ]… <right delimiter>

[ { <wkt separator> <prime meridian> } ]

Figure 11 — Modified BNF definition of geodetic reference frame

Add the following note below the table, where TBD is the number of the new section described above (the one added before §8.2.1).

`<celestialBody>`is described in TBD.

#### 3.2.2.3. InertialReferenceFrame

Add a new section using the existing `GeodeticCRS` as a template.
The definition of `InertialCRS` is similar to `GeodeticCRS` with
`GeodeticReferenceFrame` replaced by `InertialReferenceFrame`.

### 3.2.3. Changes to ISO 19111

This section describes proposed changes to ISO 19111 abstract model. If accepted, those changes would require the publication of an ISO 19111 amendment and/or an OGC corrigendum.

#### 3.2.3.1. Association to CelestialBody

The association to `CelestialBody` should be defined in the base `Datum` class
for allowing the celestial body to be defined for any kind of datum
not only inertial, but also geodetic, vertical, parametric, and more.
Doing so would require the addition defined in Clause 3.2.1.3 to be included in ISO 19111.

The association is defined as optional for compatibility with existing CRS definitions. If the celestial body is not provided, the default value is unspecified. It may be Earth, or it may be inferred from the context.

#### 3.2.3.2. Remove ObjectUsage for generalization

In the ISO 19111 model, most classes inherit a set of properties from the `IdentifiedObject` parent class.
Those properties are *name*, *alias*, *identifier*, and *remarks*.
But there is also one additional property, namely *domain*,
which is inherited only by the `Datum`, `CRS`, and `CoordinateOperation` classes.
ISO 19111:2019 does this restriction by defining those properties in an intermediate class named `ObjectUsage`.
ISO 19111:2007 did this restriction by repeating properties in the three above-cited classes,
in a way similar to the UML diagram provided in section Clause 3.1.

The following UML diagram shows the ISO 19111:2019 model.
The `ObjectUsage` contains only a `domain` property and is inserted between
the `IdentifiedObject` parent class and the `Datum`, `CRS`, and `CoordinateOperation` subclasses.
This insertion was done for preserving the same restriction as in ISO 19111:2007,
where only `Datum`, `CRS`, and `CoordinateOperation` could have a scope and domain of validity.

Figure 12 — Current ISO 19111:2019 model with object usage

Removing the restriction saying that only `Datum`, `CRS`, and `CoordinateOperation`
can have a scope or a domain of validity is proposed.
There is nothing inherently wrong in specifying a scope on most kinds of CRS-related objects.
For example:

A

`MinkowskiCS`definition may want to specify*“for use with special relativity”*as the scope.An

`Ellipsoid`definition may want to specify a limited geographic domain of validity if the celestial body has an irregular shape with different ellipsoidal approximations for different geographic areas.A

`PrimeMeridian`definition may want to specify a limited temporal extent if it is determined by an ephemeral feature, for example of the surface of a gas planet.A

`CoordinateSystemAxis`with direction such as “South along 60°E meridian” may want to specify*”for use at North pole”*as the scope.

The restriction can be removed by deleting the `ObjectUsage` class
(not to be confused with the `ObjectDomain` class, which is kept unchanged),
and moving the `domain` attribute up to the `IdentifiedObject` parent class.

#### 3.2.3.3. Remove EngineeringCS for generalization

The ISO 19111 Standard contains some coordinate systems (CSs) that are unions instead of classes.
The purpose for the CSs is not to imply a new set of geometric formulas,
but to restrict the classes of coordinate systems that can be associated to a CRS.
One of those unions is `EngineeringCS`, which is a union of all CS classes except
the ellipsoidal, vertical, parametric, and temporal coordinate systems.
While the use of unions met the intended goal of forbidding the association of
an Engineering CRS with, for example, an `EllipsoidalCS`,
it may actually forbid associations to any coordinate system that is not in the union list.
A closed universe of CSs may be desirable for some CRS types such as `GeodeticCRS`,
but `EngineeringCRS` may be a case where an open universe is desirable
for allowing associations to user-defined coordinate systems.
If an open universe is accepted, then the `EngineeringCS` union should be removed
and replaced by a requirement in the text saying that this CRS should not be
associated to ellipsoidal, vertical, parametric, or temporal coordinate systems.

This change proposal is not necessary for using `MinkowskiCS` as proposed in this ER.
This is because MinkowskiCS is defined as a subtype of the `CartesianCS` class,
which is a member of the `EngineeringCS` union.
However, that change proposal may become necessary if a user wants to use
the Schwarzschild metric (Annex E.7) instead of
Minkowski (Annex E.5) with an engineering CRS.

The above issue applies also to `GeodeticCRS`:
it may be associated to a `MinkowskiCS` as a specialization of `CartesianCS`,
but cannot be associated to other metrics unless the metrics are considered as specializations
of some CS classes enumerated in the `GeodeticCS` union.
However, the CS restriction in `GeodeticCRS` may be more important than in the `EngineeringCRS` case,
so this ER does not propose relaxing that restriction at this stage.

#### 3.2.3.4. Remove temporal origin

The `TemporalDatum` class contains a mandatory `origin` property of type `dateTime`.
By default, the origin uses the proleptic Gregorian calendar of the Earth.
However, there is no absolute time in the context of special relativity.
Specifying a time is done by declaring that an event happened simultaneously with the clock showing some numbers.
But two events that are simultaneous according to one observer may not be simultaneous according to another observer.

Time origins were typically used for computing the time offset between two temporal reference systems. For example, when converting from one CRS having its origin in 1970 to another CRS having its origin in 2000, the operation can be done by subtracting 30 years to the temporal coordinate. It may be more robust to provide such value as a coordinate operation defined in an EPSG-like database, like other datum shifts in the spatial domain, instead of inferring the operation from temporal datum properties.

## 3.3. Coordinate transformations

The ISO 19111 framework for Coordinate Operations is not constrained to the Earth.
An ISO 19111 coordinate operation describes the relationship between two CRSs
without assumption about the frame types (inertial, geodetic, *etc.*).
Different operation subclasses exist,
but this hierarchy is for tasks such as describing the kind of errors to expect
and for chaining operations together.
A class of particular interest is `Transformation`,
which contains the following properties
(non-exhaustive list).

`sourceCRS`: The CRS of source coordinate tuples (before transformation).`targetCRS`: The CRS of target coordinate tuples (after transformation).`interpolationCRS`: The CRS in which coordinates are interpolated.`method`: The coordinate transformation formulas which may expect parameters.`parameterValue`: Values to assign to the parameters expected by above-cited method.`domain`: The scope and the ISO 19115 extent where the transformation is valid.`coordinateOperationAccuracy`: Accuracy as an ISO 19157 (data quality) object.

The following UML diagram shows the *spirit* of ISO 19111 `Transformation` and related classes which is not an exact representation of the ISO 19111 model as some classes are omitted
and replaced by attributes for simplicity, sometimes in a different location for emphasis.
For example, ISO 19111 puts `coordinateOperationAccuracy` in the `CoordinateOperation` parent class,
but the UML below shows it in the `Transformation` class in order to highlight that it is of particular relevance there.
Note that this framework contains a `transform(CoordinateSet)` operation,
which performs the actual task of transforming a set of coordinate tuples.

Figure 13 — Spirit of ISO 19111 coordinate transformation framework

The interpolation CRS is an interesting concept. It is often either the source or target CRS but can also be different. For example, if the source and target CRS are both attached to bodies orbiting around each other or around a larger body, it may be convenient to perform the interpolations in the CRS of the barycenter of the system because the orbiting bodies are subject to accelerations, which can make linear interpolations unsuitable. By contrast, if the barycenter has negligible accelerations, then linear interpolations in the CRS of that barycenter may be better approximations.

The source and target CRS exist in the GML schema but not the interpolation CRS because the concept was introduced in an ISO 19111 revision published after GML was designed. However, this is not a problem for the use cases considered in this ER, because the data to interpolate are encoded as Moving Feature files. Those data shall be expressed in the interpolation CRS (because the data are the values to interpolate), so the natural consequence is that the Moving Feature CRS defines the interpolation CRS.

An operation can be applied to a subset of coordinate tuples.
For example, if an operation works only on the spatial coordinates (*x*, *y*, *z*),
it does not mean that this operation cannot be used with four-dimensional (*x*, *y*, *z*, *t*) coordinates.
ISO 19111 has a concept of “pass-through” operation, which can be combined with any other operation for applying
the latter on some coordinates (e.g., the first 3), then pass-through the remaining coordinates (e.g., *t*) unchanged.
Thus, `PassThroughOperation` can be combined with existing operations for creating new operations with larger numbers of dimensions.
It is possible to create one pass-through operation working on the spatial dimensions of four-dimensional coordinate tuples,
another pass-through operation working on the temporal dimension of the same tuples,
then chain them together as described in Clause 3.3.1.
An example is illustrated below, with ISO 19111 class names in box titles.