OGC Engineering Report

OGC Testbed-19 — Non-Terrestrial Geospatial Engineering Report
Sina Taghavikish Editor Rob Smith Editor Martin Desruisseaux Editor Jérôme Jacovella-St-Louis Editor Carl Stephen Smyth Editor Charles Heazel Editor
OGC Engineering Report


Document number:23-042
Document type:OGC Engineering Report
Document subtype:
Document stage:Published
Document language:English

License Agreement

Use of this document is subject to the license agreement at

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:

Rob SmithAway TeamContributor
Sina TaghavikishOpen Geospatial ConsortiumEditor
Charles HeazelHeazelTechContributor
Jérôme Jacovella-St-LouisEcereContributor
Carl Stephen SmythOpen Site PlanContributor
Martin DesruisseauxGeomatysContributor

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.

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

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

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

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

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


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


In a spatial coordinate reference system (Clause 2.3), the coordinate numbers are qualified by units.


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)


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)


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


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


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


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


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


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


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


See also Annex E.3.

2.13. Local Reference System

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


See also Annex E.4.

[SOURCE: ISO 19141]

2.14. Location

particular place or position (Clause 2.16)


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


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


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


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


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


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


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.


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 productTypeReification ofCover all the UML?
EPSG geodetic datasetDatasetISO 19111:2019No
ISO 19162:2019 — WKT 2EncodingISO 19111:2019No
ISO 19136:2007 — GMLEncodingISO 19111:2007Yes
OGC 09-083r4 — GeoAPI 3.0APIISO 19111:2007Yes
PROJ-JSON (community)EncodingISO 19111:2019To 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 projectImplementation ofLicenseSource code
Apache SISOGC 09-083 — GeoAPI 3.0.2Apache 2GitHub
PROJ-JNIOGC 09-083 — GeoAPI 3.0.2MITGitHub

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.

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

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

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

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

  3. 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 i j = [ 1 0 0 0 1 0 0 0 1 ]   (1)

Let p be the coordinate tuple of a point in space or space-time, and pi (or pj) be one of the coordinates of that tuple. For a small displacement dp, the small distance ds is given by:

d s 2 = i j g i j d p i d p j   (2)

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

d s 2 = ( + d x d x + 0 + 0 + 0 + d y d y + 0 + 0 + 0 + d z d z ) = 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 i j = [ 1 0 0 c o s ( ϕ ) ]   (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 i j = [ 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0 1 ]   (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.  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

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

datumInertialReferenceFrameMandatoryAssociation to the inertial datum used by this inertial CRS.


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.


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

celestialBodyCelestialBodyOptionalAssociation to the celestial body used by this inertial datum.
ellipsoidEllipsoidOptionalAssociation to the ellipsoid used by this inertial datum.
primeDirectionPrimeMeridianOptionalAssociation to the prime meridian used by this inertial datum.


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.


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.


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.


NASA SPACE uses the “Ephemeris Object” term instead of “Celestial body.”  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.  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

KeywordBNF elementClause in which defined
alias<alias keyword>TBD
celestialBody<celestial body keyword>TBD
inertialCRS<inertial CRS keyword>TBD
Minkowski<spatial cs type>7.5.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  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.  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.  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 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.  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.  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.  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.