Approved

OGC Draft Standard

OGC GeoPose 1.0 Data Exchange Draft Standard
Carl Stephen Smyth Editor
Version: 1.0.0
OGC Draft Standard

Approved

Document number:21-056r10
Document type:OGC Draft Standard
Document subtype:Implementation
Document stage:Approved
Document language:English

License Agreement

Permission is hereby granted by the Open Geospatial Consortium, (“Licensor”), free of charge and subject to the terms set forth below, to any person obtaining a copy of this Intellectual Property and any associated documentation, to deal in the Intellectual Property without restriction (except as set forth below), including without limitation the rights to implement, use, copy, modify, merge, publish, distribute, and/or sublicense copies of the Intellectual Property, and to permit persons to whom the Intellectual Property is furnished to do so, provided that all copyright notices on the intellectual property are retained intact and that each person to whom the Intellectual Property is furnished agrees to the terms of this Agreement.

If you modify the Intellectual Property, all copies of the modified Intellectual Property must include, in addition to the above copyright notice, a notice that the Intellectual Property includes modifications that have not been approved or adopted by LICENSOR.

THIS LICENSE IS A COPYRIGHT LICENSE ONLY, AND DOES NOT CONVEY ANY RIGHTS UNDER ANY PATENTS THAT MAY BE IN FORCE ANYWHERE IN THE WORLD. THE INTELLECTUAL PROPERTY IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. THE COPYRIGHT HOLDER OR HOLDERS INCLUDED IN THIS NOTICE DO NOT WARRANT THAT THE FUNCTIONS CONTAINED IN THE INTELLECTUAL PROPERTY WILL MEET YOUR REQUIREMENTS OR THAT THE OPERATION OF THE INTELLECTUAL PROPERTY WILL BE UNINTERRUPTED OR ERROR FREE. ANY USE OF THE INTELLECTUAL PROPERTY SHALL BE MADE ENTIRELY AT THE USER’S OWN RISK. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR ANY CONTRIBUTOR OF INTELLECTUAL PROPERTY RIGHTS TO THE INTELLECTUAL PROPERTY BE LIABLE FOR ANY CLAIM, OR ANY DIRECT, SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING FROM ANY ALLEGED INFRINGEMENT OR ANY LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR UNDER ANY OTHER LEGAL THEORY, ARISING OUT OF OR IN CONNECTION WITH THE IMPLEMENTATION, USE, COMMERCIALIZATION OR PERFORMANCE OF THIS INTELLECTUAL PROPERTY.

This license is effective until terminated. You may terminate it at any time by destroying the Intellectual Property together with all copies in any form. The license will also terminate if you fail to comply with any term or condition of this Agreement. Except as provided in the following sentence, no such termination of this license shall require the termination of any third party end-user sublicense to the Intellectual Property which is in force as of the date of notice of such termination. In addition, should the Intellectual Property, or the operation of the Intellectual Property, infringe, or in LICENSOR’s sole opinion be likely to infringe, any patent, copyright, trademark or other right of a third party, you agree that LICENSOR, in its sole discretion, may terminate this license without any compensation or liability to you, your licensees or any other party. You agree upon termination of any kind to destroy or cause to be destroyed the Intellectual Property together with all copies in any form, whether held by you or by any third party.

Except as contained in this notice, the name of LICENSOR or of any other holder of a copyright in all or part of the Intellectual Property shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Intellectual Property without prior written authorization of LICENSOR or such copyright holder. LICENSOR is and shall at all times be the sole entity that may authorize you or any third party to use certification marks, trademarks or other special designations to indicate compliance with any LICENSOR standards or specifications. This Agreement is governed by the laws of the Commonwealth of Massachusetts. The application to this Agreement of the United Nations Convention on Contracts for the International Sale of Goods is hereby expressly excluded. In the event any provision of this Agreement shall be deemed unenforceable, void or invalid, such provision shall be modified so as to make it valid and enforceable, and as so modified the entire Agreement shall remain in full force and effect. No decision, action or inaction by LICENSOR shall be construed to be a waiver of any rights or remedies available to it.

None of the Intellectual Property or underlying information or technology may be downloaded or otherwise exported or reexported in violation of U.S. export laws and regulations. In addition, you are responsible for complying with any local laws in your jurisdiction which may impact your right to import, export or use the Intellectual Property, and you represent that you have complied with any regulations or registration procedures required by applicable law to make this license enforceable.



I.  Abstract

GeoPose 1.0 is an OGC Implementation Standard for exchanging the location and orientation of real or virtual geometric objects (“Poses”) within reference frames anchored to the earth’s surface (“Geo”) or within other astronomical coordinate systems.

The standard specifies two Basic forms with no configuration options for common use cases, an Advanced form with more flexibility for more complex applications, and five composite GeoPose structures that support time series plus chain and graph structures.

These eight Standardization Targets are independent. There are no dependencies between Targets and each may be implemented as needed to support a specific use case.

The Standardization Targets share an implementation-neutral Logical Model which establishes the structure and relationships between GeoPose components and also between GeoPose data objects themselves in composite structures. Not all of the classes and properties of the Logical Model are expressed in individual Standardization Targets nor in the specific concrete data objects defined by this standard. Those elements that are expressed are denoted as implementation-neutral Structural Data Units (SDUs). SDUs are aliases for elements of the Logical Model, isolated to facilitate specification of their use in encoded GeoPose data objects for a specific Standardization Target.

For each Standardization Target, each implementation technology and corresponding encoding format defines the encoding or serialization specified in a manner appropriate to that technology.

GeoPose 1.0 specifies a single encoding in JSON format (IETF RFC 8259). Each Standardization Target has a JSON Schema (Internet-Draft draft-handrews-json-schema-02) encoding specification. The key standardization requirements specify that concrete JSON-encoded GeoPose data objects must conform to the corresponding JSON Schema definition. The individual elements identified in the encoding specification are composed of SDUs, tying the specifications back to the Logical Model.

The GeoPose 1.0 Standard makes no assumptions about the interpretation of external specifications, for example, of reference frames. Nor does it assume or constrain services or interfaces providing conversion between GeoPoses of difference types or relying on different external reference frame definitions.

II.  Keywords

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

ogc, ogcdoc, OGC document, pose, geopose, augmented reality, ar, mixed reality, xr, reference frame


III.  Preface

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium shall not be held responsible for identifying any or all such patent rights.

Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the standard set forth in this document, and to provide supporting documentation.

IV.  Security considerations

No security considerations have been made for this document.

V.  Submitting Organizations

The following organizations submitted this Document to the Open Geospatial Consortium (OGC):

VI.  Submitters

All questions regarding this submission should be directed to the editor or the submitters:

Name Affiliation
Nicolas Blanc School of Management and Engineering Vaud, HES-SO University of Applied Sciences and Arts Western Switzerland
Kyoung-Sook Kim National Institute of Advanced Industrial Science and Technology
Jeremy Morley Ordnance Survey
Christine Perey Open AR Cloud Association
Mahmoud Sakr Université Libre de Bruxelles
Scott Simmons Open Geospatial Consortium
Carl Stephen Smyth OpenSitePlan, USA
Jan-Erik Vinje Open AR Cloud Association

VII.  Participants in development

The following individuals contributed to the GeoPose 1.0 development:

Table 1 — Participants in Development

Name Institution
Nazih Fino Global Nomad
Josh Lieberman Open Geospatial Consortium
Mikel Salazar Augmented Interaction
Maxime Schoemans Université Libre de Bruxelles
Marco Tillmann Blackshark.ai

VIII.  Acknowledgements

The GeoPose Standards Working Group (SWG) wishes to thank the 3D Information Management (3DIM) Working Group of the OGC as well as Augmented City, Immersal, Trevor F. Smith, Transmutable, Khronos Group, SEDRIS, Roger Lott and Chris Little for their support and insight.

OGC GeoPose 1.0 Data Exchange Draft Standard

1.  Scope

The OGC GeoPose 1.0 Standard defines requirements (rules) for the interoperable exchange of the location and orientation of real or virtual geometric objects (poses) within reference frames anchored to the earth’s surface (Geo) or within other astronomical coordinate systems.

The Standard specifies:

The GeoPose Standard is based on an implementation-neutral Logical Model (LM). This LM is a formalization of a Conceptual Model (CM). The CM consists of a linked set of terms and definitions, defining a domain of discourse for the various geometric, geographic, and physical concepts related to GeoPoses. The LM formalizes the relationships between the implementable parts and aspects of the CM. The LM further establishes the structure and relationships between GeoPose components and also between GeoPoses data objects themselves in composite structures.

Note that the concrete GeoPose data objects defined by this standard correspond to only certain classes and properties of the LM. These classes and properties are identified as implementation-neutral Structural Data Units (SDUs). SDUs are aliases for the implementable elements of the LM. SDUs are grouped to define the implementation-neutral form of the GeoPose Standardization Targets: the specific implementation that the Standard addresses. For each Standardization Target, each implementation technology will have the definition of the encoding or serialization specified in a manner appropriate to that technology.

The GeoPose 1.0 Standard defines only one of many possible encoding methods for implementation of any or all of the eight Standardization Targets: JavaScript Object Notation (JSON). Each Standardization Target has a Internet-Draft draft-handrews-json-schema-02 definition. Most of the GeoPose standardization requirements are that concrete JSON GeoPose data objects shall conform to the corresponding JSON-Schema definition. The individual elements identified in the encoding specifications are SDUs that refer to one or more classes or attributes of the LM.

The GeoPose 1.0 Standard excludes assumptions about the interpretation of external specifications such as reference frames. Further, the Standard does not assume or constrain services or interfaces providing conversion between GeoPoses of difference types or relying on different external reference frame definitions.

2.  Conformance

Conformance with this standard shall be checked using all the relevant tests specified in Annex A of this document. The framework, concepts, and methodology for testing, and the criteria to be achieved to claim conformance are specified in the OGC Compliance Testing Policies (https://portal.ogc.org/files/?artifact_id=55234) and Procedures and the OGC Compliance Testing web site (https://www.ogc.org/compliance). GeoPose 1.0 JSON encodings are specified via Internet-Draft draft-handrews-json-schema-02 and most of the requirements are that conforming encoded data objects shall validate against the corresponding schema. The GeoPose schemas are available from the OGC’s schema repository at https://schemas.opengis.net/geopose

All requirements classes and conformance classes described in this document are owned by the standard(s) identified.

2.1.  Modularity

This standard describes eight standardization targets. These targets are independent and a conforming implementation may implement one or more of the targets.

2.2.  Conformance classes

This OGC® standard identifies eight conformance classes. One conformance class is defined for each corresponding set of Structural Data Units (SDUs) where each SDU is linked to the Logical Model as an alias for a class or attribute. Additionally, each of the eight standardization targets is represented by a conformance class as defined by a corresponding requirements class.

The tests in Annex A are organized by requirements class. An implementation of a conformance class must pass all tests specified in Annex A for the corresponding requirements class.

No conformance class has a dependency on another conformance class.

The Logical Model is the root normative part of this standard.

2.3.  Standardization targets

There are eight independent standardization targets. Each addresses the specific requirements of one or more individual use cases. The Basic and Advanced Targets share in the use of an EPSG 4979/3D WGS-84 outer frame (Clause 4.2.7) but differ in the level of options and flexibility in specification of the inner frame (Clause 4.2.8). The Composite Targets offer approaches to packaging sequenced or linked Frame Transforms.

The eight targets are denoted by bold terms in the following categories:

  1. Basic — Satisfy most use cases — EPSG 4979 Outer Frame

    1. Local Tangent Plane East, North, Up (LTP-ENU) inner frame (Clause 4.2.8) oriented by Yaw, Pitch, and Roll (YPR) rotations about z, y, x axes: Basic-YPR Target

    2. LTP-ENU inner frame (Clause 4.2.8) oriented by unit quaternion: Basic-Quaternion Target

  2. Configurable inner frame (Clause 4.2.8) oriented by unit quaternion — Flexible enough for complex use cases: Advanced Target

  3. Composite — Efficient structures for linked and sequential GeoPoses

    1. Linked linear sequence of poses: Chain Target

    2. General linked poses: Graph Target

    3. Sequence

      1. Series

        1. Time series with constant time spacing: Regular Time series Target

        2. Time series with per-GeoPose time: Irregular Time series Target

      2. Open-ended sequence of time-stamped GeoPoses: Stream Target

3.  Normative references

The following documents are referred to in the text in such a way that some or all of their content constitutes requirements of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.

T. Bray (ed.): IETF RFC 8259, The JavaScript Object Notation (JSON) Data Interchange Format. (2017). https://www.rfc-editor.org/info/rfc8259.

Austin Wright, Henry Andrews, Ben Hutton, Greg Dennis: Internet-Draft draft-handrews-json-schema-02, JSON Schema: A Media Type for Describing JSON Documents. (2019). https://www.ietf.org/archive/id/draft-handrews-json-schema-02.txt.

Austin Wright, Henry Andrews, Ben Hutton: Internet-Draft draft-handrews-json-schema-validation-02, JSON Schema Validation: A Vocabulary for Structural Validation of JSON. (2019). https://www.ietf.org/archive/id/draft-handrews-json-schema-validation-02.txt.

ISO: ISO 19101-1:2014, Geographic information — Reference model — Part 1: Fundamentals. International Organization for Standardization, Geneva (2014). https://www.iso.org/standard/59164.html.

ISO: ISO 19103:2015, Geographic information — Conceptual schema language. International Organization for Standardization, Geneva (2015). https://www.iso.org/standard/56734.html.

ISO: ISO 19109:2015, Geographic information — Rules for application schema. International Organization for Standardization, Geneva (2015). https://www.iso.org/standard/59193.html.

ISO: ISO 19111:2019, Geographic information — Referencing by coordinates. International Organization for Standardization, Geneva (2019). https://www.iso.org/standard/74039.html.

ISO: ISO 19115-1:2014, Geographic information — Metadata — Part 1: Fundamentals. International Organization for Standardization, Geneva (2014). https://www.iso.org/standard/53798.html.

ISO: ISO 19157:2013, Geographic information  — Data quality. International Organization for Standardization, Geneva (2013). https://www.iso.org/standard/32575.html.

ISO: ISO/TS 19139:2007, Geographic information — Metadata — XML schema implementation. International Organization for Standardization, Geneva (2007). https://www.iso.org/standard/32557.html.

ISO: ISO 8601-1:2019, Date and time — Representations for information interchange — Part 1: Basic rules. International Organization for Standardization, Geneva (2019). https://www.iso.org/standard/70907.html.

ISO: ISO 8601-2:2019, Date and time — Representations for information interchange — Part 2: Extensions. International Organization for Standardization, Geneva (2019). https://www.iso.org/standard/70908.html.

Joan Masó and Lucy Bastin: OGC 15-097r1, OGC® Geospatial User Feedback Standard: Conceptual Model. Open Geospatial Consortium (2016). https://docs.ogc.org/is/15-097r1/15-097r1.html.

Gerhard Gröger, Thomas H. Kolbe, Claus Nagel, Karl-Heinz Häfele: OGC 12-019, OGC City Geography Markup Language (CityGML) Encoding Standard. Open Geospatial Consortium (2012). https://portal.ogc.org/files/?artifact id=47842.

Jiyeong Lee, Ki-Joune Li, Sisi Zlatanova, Thomas H. Kolbe, Claus Nagel, Thomas Becker: OGC 14-005r3, OGC® IndoorGML. Open Geospatial Consortium (2014). https://docs.ogc.org/is/14-005r3/14-005r3.html.

N. Freed, N. Borenstein: IETF RFC 2045, Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies. (1996). https://www.rfc-editor.org/info/rfc2045.

T. Berners-Lee, R. Fielding, L. Masinter: IETF RFC 3986, Uniform Resource Identifier (URI): Generic Syntax. (2005). https://www.rfc-editor.org/info/rfc3986.

INSPIRE: D2.8.III.2 Data Specification on Buildings — Technical Guidelines. European Commission Joint Research Centre.

ISO/IEC: ISO/IEC 19505-2:2012, Information technology — Object Management Group Unified Modeling Language (OMG UML) — Part 2: Superstructure. International Organization for Standardization, International Electrotechnical Commission, Geneva (2012). https://www.iso.org/standard/52854.html.

ISO/IEC: ISO/IEC 19507:2012, Information technology — Object Management Group Object Constraint Language (OCL). International Organization for Standardization, International Electrotechnical Commission, Geneva (2012). https://www.iso.org/standard/57306.html.

Khronos Group Inc.: COLLADA — Digital Asset Schema Release 1.5.0

Cliff Kottman and Carl Reed: OGC 08-126, Topic 5 — Features. Open Geospatial Consortium (2009). https://portal.ogc.org/files/?artifact id=29536.

Cliff Kottman: OGC 99-108r2, Topic 8 — Relationships Between Features. Open Geospatial Consortium (1999). https://portal.ogc.org/files/?artifact id=894.

Thomas H. Kolbe, Tatjana Kutzner, Carl Stephen Smyth, Claus Nagel, Carsten Roensdorf, Charles Heazel: OGC 20-010, OGC City Geography Markup Language (CityGML) Part 1: Conceptual Model Standard. Open Geospatial Consortium (2021). https://docs.ogc.org/is/20-010/20-010.html.

Clemens Portele: OGC 07-036, OpenGIS Geography Markup Language (GML) Encoding Standard. Open Geospatial Consortium (2007). https://portal.ogc.org/files/?artifact id=20509.

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

4.1.  Basic concepts

4.1.1. conceptual model

CM ADMITTED

model that defines concepts of a universe of discourse

Note 1 to entry: A conceptual model is explicitly chosen to be informed by, but be independent of design or implementation concerns.

[SOURCE: ISO 19101-1:2014, Clause 4.1.5]

4.1.2. logical model

logical information model ADMITTED

LM ADMITTED

information model that specifies the structures and relationships between data elements but is independent of any particular technology or implementation environment

[SOURCE: ISO 13972:2022, Clause 3.1.8]

4.1.3. structural data unit

SDU ADMITTED

element of the logical model (Clause 4.1.2) expressed in concrete data objects encoded using specific encoding or serialization technologies

4.2.  Spatial concepts

4.2.1. position

OGC direct position ADMITTED

set of coordinates of a point in a 3D Euclidean space and associated reference frame (Clause 4.2.5)

4.2.2. orientation

rotational relationship between two reference frames (Clause 4.2.5)

4.2.3. pose

representation of a frame transform (Clause 4.2.6) mapping the space of an outer frame (Clause 4.2.7) to the space of an inner frame (Clause 4.2.8)

Note 1 to entry: A pose (Clause 4.2.3) may be associated with additional non-geometrical properties such as time of observation or validity. Poses in computer graphics often have an outer frame (Clause 4.2.7) defined by a parent node in a scene graph and an inner frame (Clause 4.2.8) define by a position (Annex D.26) and an orientation.

4.2.4. GeoPose

pose (Clause 4.2.3) whose associated outer frame (Clause 4.2.7) or a pose chain (Clause 4.2.17) whose associated outermost frame (Clause 4.2.9) is a topocentric frame (Clause 4.2.12) defined by an extrinsic frame specification (Clause 4.2.14) related to the ephemeris object (Clause 4.2.11) planet Earth.

4.2.5. reference frame

system of location and measurement often defined by a frame specification (Clause 4.2.13) usually including a coordinate system to be used within a corresponding space

4.2.6. frame transform

pair of reference frames (Clause 4.2.5) and a bi-continuous coordinate transformation relating points in the corresponding spaces

Note 1 to entry: The two reference frames (Clause 4.2.5) are called outer frame (Clause 4.2.7) (domain) and inner frame (Clause 4.2.8) (range). Only an outer frame (Clause 4.2.7) may have an extrinsic frame specification (Clause 4.2.14).

Note 2 to entry: A frame transform (Clause 4.2.6) functions as a directed edge in a frame graph (Clause 4.2.16) representation of the transformational relationship between reference frames (Clause 4.2.5).

4.2.7. outer frame

outer reference frame ADMITTED

first of two reference frames (Clause 4.2.5) associated with a frame transform (Clause 4.2.6)

Note 1 to entry: In the NASA SPICE system, the outer frame (Clause 4.2.7) is referred to as the from frame (Clause 4.2.5). In the ROS SDF documentation, the outer frame (Clause 4.2.7) is referred to as the Parent frame (Clause 4.2.5). In ISO 19162, the outer frame (Clause 4.2.7) is referred to as the base frame (Clause 4.2.5).

4.2.8. inner frame

inner reference frame ADMITTED

second of two reference frames (Clause 4.2.5) associated with a frame transform (Clause 4.2.6)

Note 1 to entry: An inner frame (Clause 4.2.8) may not be a topocentric frame (Clause 4.2.12).

Note 2 to entry: In the NASA SPICE system, the inner frame (Clause 4.2.8) is referred to as the to frame (Clause 4.2.5). In the ROS SDF documentation, the inner frame (Clause 4.2.8) is referred to as the child frame (Clause 4.2.5). In ISO 19162, the inner frame (Clause 4.2.8) is referred to as the derived frame (Clause 4.2.5).

4.2.9. outermost frame

outer frame (Clause 4.2.7) of the first frame transform (Clause 4.2.6) in a pose chain (Clause 4.2.17)

4.2.10. innermost frame

inner frame (Clause 4.2.8) of the last frame transform (Clause 4.2.6) in a pose chain (Clause 4.2.17)

4.2.11. ephemeris object

physical object or manifestation of a physical object that can be characterized by an externally-defined (possibly time-dependent) location and orientation in a 3-dimensional space

4.2.12. topocentric frame

topocentric reference frame ADMITTED

frame (Clause 4.2.5) that has an extrinsic frame specification (Clause 4.2.14) associated with a location on or near the surface of a natural body, such as planet Earth

Note 1 to entry: This definition is sourced from the NASA SPICE system.

Note 2 to entry: In connection with a GeoPose, one way that a topocentric frame (Clause 4.2.12) may be realized is by a local tangent plane east-north-up frame (LTP-ENU) (Annex D.24) attached to the surface of a body, to a gravitational equipotential surface (geoid (Annex D.21) in the case of planet Earth), or to a mathematical surface such as an ellipsoid (Annex D.16) approximating a geoid (Annex D.21).

4.2.13. frame specification

data that completely and uniquely defines a reference frame (Clause 4.2.5)

Note 1 to entry: In the context of poses (Clause 4.2.3), there are extrinsic frame specification (Clause 4.2.14) defined by an external data source, and derived frame specification (Clause 4.2.15) defined by a transformation from another reference frame (Clause 4.2.5).

4.2.14. extrinsic frame specification

extrinsic specification ADMITTED

relates a reference frame (Clause 4.2.5) to an ephemeris object (Clause 4.2.11) or other external reference, which may be based on joint properties of a group of objects

Example

The center of mass of the Earth-Moon system.

4.2.15. derived frame specification

derived specification ADMITTED

relates a reference frame (Clause 4.2.5) to another reference frame (Clause 4.2.5) by a frame transform (Clause 4.2.6) or its inverse

4.2.16. frame graph

reference frame graph ADMITTED

directed acyclic graph representation of the transformational relationships between reference frames (Clause 4.2.5)

Note 1 to entry: In the frame graph, reference frames (Clause 4.2.5) are the nodes or vertices of the graph. Frame transforms (Clause 4.2.6) are the edges of the graph, directed from the outer frame (Clause 4.2.7) to the inner frame (Clause 4.2.8). Note that there may be zero, one, or many paths between two distinct vertices, i.e. frames (Clause 4.2.5). Multiple paths correspond to real-world situations with, for example, redundant line-of-sight links in point-to-point radio networks used in communication systems.

4.2.17. pose chain

directed path in a frame graph (Clause 4.2.16) connecting an outermost frame (Clause 4.2.9) to an innermost frame (Clause 4.2.10)

Note 1 to entry: The sequence of frame transforms (Clause 4.2.6) in a pose chain (Clause 4.2.17) may be combined in a single composite transformation.

Note 2 to entry: There may exist multiple pose chains (Clause 4.2.17) linking the same outermost frame (Clause 4.2.9) and innermost frame (Clause 4.2.10) and the corresponding composite transformations may not agree. This is intentional, representing real-world configurations and capabilities of sensors and communication links.

4.3.  Sequence and stream concepts

4.3.1. sequence

GeoPose sequence ADMITTED

set of poses (Clause 4.2.3) ordered by valid time (Clause 4.5.1) and pertaining to the same underlying physical object or construct

Note 1 to entry: A pose (Clause 4.2.3) in a sequence is called a “member pose”.

Note 2 to entry: In a sequence, each successive member pose (Clause 4.2.3) must have a valid time (Clause 4.5.1) after its predecessor.

4.3.2. inter-pose duration

time duration (Clause 4.4.5) between consecutive poses (Clause 4.2.3) in a sequence (Clause 4.3.1)

4.3.3. closed sequence

closed pose sequence ADMITTED

sequence (Clause 4.3.1) of fixed length with specific meta-data that fully characterize the sequence and its member poses (Clause 4.2.3)

4.3.4. regular sequence

regular GeoPose sequence ADMITTED

closed sequence (Clause 4.3.3) with a constant inter-pose duration (Clause 4.3.2)

4.3.5. irregular sequence

irregular GeoPose sequence ADMITTED

closed sequence (Clause 4.3.3) with a variable inter-pose duration (Clause 4.3.2)

Note 1 to entry: Each pose (Clause 4.2.3) in an irregular sequence (Clause 4.3.5) has an associated valid time (Clause 4.5.1).

4.3.6. GeoPose stream

irregular sequence (Clause 4.3.5) of unbounded length

4.3.7. header

sequence header ADMITTED

metadata essential for interpretation of the following members of a sequence (Clause 4.3.1)

4.3.8. transition model

metadata that indicates whether or how it may be possible to estimate poses (Clause 4.2.3) in the interval between consecutive poses (Clause 4.2.3) in a sequence (Clause 4.3.1)

4.3.9. trailer

sequence trailer ADMITTED

metadata essential for validation of the preceding members of a sequence (Clause 4.3.1).

4.4.  Temporal concepts

4.4.1. temporal frame

specification for the interpretation of points on a time line (Clause 4.4.2) as instants (Clause 4.4.3) in relation to a specified epoch (Clause 4.4.6)

4.4.2. time line

time axis ADMITTED

one-dimensional Euclidean space whose points represent an ordered sequence of instants (Clause 4.4.3) directed from the past to the future

4.4.3. instant

specific point on a time line (Clause 4.4.2)

4.4.4. interval

timespan between two instants (Clause 4.4.3) on a time line (Clause 4.4.2), interpreted in context of the associated temporal frame (Clause 4.4.1)

4.4.5. duration

one-dimensional signed distance between the bounding instants (Clause 4.4.3) of an interval (Clause 4.4.4)

Note 1 to entry: The magnitude of a length value depends on the temporal frame (Clause 4.4.1).

Note 2 to entry: A duration is semi-open: it includes the earlier instant (Clause 4.4.3) but not the later instant (Clause 4.4.3).

4.4.6. epoch

specified instant (Clause 4.4.3) that can be used as a reference point to calculate temporal relationships (Clause 4.4.7) and durations (Clause 4.4.5) between instants (Clause 4.4.3).

4.4.7. temporal relationship

relationship between two instants (Clause 4.4.3)

Note 1 to entry: Temporal relationships are only valid within the context of a specific temporal frame (Clause 4.4.1).

Note 2 to entry: GeoPose supports three temporal relationships: “before”, “coincident”, and “after”.

4.5.  Temporal database concepts

4.5.1. valid time

time line (Clause 4.4.2) where the time of changes in the existence or validity of real-world objects or property values are located.

Note 1 to entry: Instants (Clause 4.4.3) in valid time (Clause 4.5.1) mark the temporal location of real-world transitions in existence, property values, or their validity.

Note 2 to entry: This term may refer to instants (Clause 4.4.3) or to time lines (Clause 4.4.2).

4.5.2. transaction time

time line (Clause 4.4.2) where the time of changes in the presence or validity of the representations of real-world objects or their properties in an information system are located

Note 1 to entry: Instants (Clause 4.4.3) in transaction time (Clause 4.5.2) mark the temporal location of actions that create, update, or delete representations of objects or properties.

Note 2 to entry: This term may refer to instants (Clause 4.4.3) or to time lines (Clause 4.4.2).

4.5.3. bi-temporality

property of a data representation that denotes that it carries both valid time (Clause 4.5.1) and transaction time (Clause 4.5.2)

5.  Conventions

This section provides details and examples for conventions used in this document.

5.1.  Identifiers

The normative provisions in this document are denoted by the URI

http://www.opengis.net/spec/GeoPose/1.0

All requirements and conformance tests that appear in this document are denoted by partial URIs which are relative to this base.

5.2.  Use Cases, Concepts, Logical Model, Standardization Targets, Encodings

5.3.  UML Notation

The logical structure of the elements used in the GeoPose Standard is presented in this document in diagrams using the Unified Modeling Language (UML) static structure diagram (see Booch et al. [10]). The UML notations used in this standard are described in the diagram in Figure 1.

Figure 1 — UML notation (ISO 19103:2015)

All associations between model elements in GeoPose are uni-directional. Thus, associations in GeoPose are navigable in only one direction. The direction of navigation is depicted by an arrowhead. In general, the context an element takes within the association is indicated by its role. The role is displayed near the target of the association. If the graphical representation is ambiguous though, the position of the role has to be drawn to the element the association points to.

In order to enhance the readability of the GeoPose UML diagrams, classes are depicted in different colors. The following coloring scheme is applied:

Figure 2 — Data Types

Classes painted in grey represent data types.

Figure 3 — Blue Color Denotes Abstract or More General Classes

Classes painted in blue are internal less-derived elements that are not themselves directly encoded as concrete data objects.

Figure 4 — Yellow Color Denotes Structural Data Units

Classes painted in yellow correspond to Structural Data Units or have properties that are represented in Structural Data Units and in encodings of those SDUs. Only data types and classes painted yellow are encoded as concrete data objects.

Figure 5 — Green Color Denotes Enumeration

Enumerations are painted in green.

Figure 6 — White Color Denotes a Note or Constraint

The color white is used for notes and OCL constraints that are provided in the UML diagrams.

6.  Conceptual model

6.1.  General

ISO 19101-1:2014 defines a universe of discourse to be a view of the real or hypothetical world that includes everything of interest. That standard defines a conceptual model to be a model that defines concepts of a universe of discourse.

The goal of this GeoPose Standard is to establish and document a common set of concepts that spans the targeted use cases. This does not attempt to redefine application concepts, but merely to present a common set of concepts from and to which their concepts can be understood and mapped.

The GeoPose Conceptual Model (CM) is a graph of related concepts. One technology-independent realization is given by the GeoPose Logical Model (LM).

The GeoPose CM consists of linked definitions of terms denoting concepts expressed in the GeoPose LM and Structural Data Unit (SDU) specifications for the standardization targets.

The CM describes a (non-normative) domain of discourse for terms used in defining a precise and normative LM expressed as a Unified Modelling Language (UML) class diagram.

The scope of the standardization targets is a subset of the scope of the LM. The scope of the LM is a subset of the scope of the CM. The standardization targets are mutually independent implementations of subsets of the LM.

6.2.  Temporal concepts and reference frame

The only temporal frame used in this GeoPose standard is “Unix Time”: seconds since the Unix Epoch of 1 January 1970 measured by a virtual “Unix clock”, ticking once per “Unix second”, and omitting any corrections such as leap seconds.

Times before 1 January 1972 are not precisely related to another temporal frame but the value at UTC 1 January 1972 was +63,072,000. This allows precise conversion to and from modern temporal frames.

NOTE  This standard does not reference a calendar and encoded values are representations of the count of seconds, rather than a calendar-relative date and time. These times may be converted to UTC and expressed as text (e.g. with ISO 8601-1:2019 and ISO 8601-2:2019) relative to a specific calendar but this is outside the scope of this standard.

Temporal concepts defined in this document are intended to align with terms used in W3C CR-owl-time-20200326.

6.3.  Document structure

The structure of the GeoPose Standard document flows from:

  • use cases to the definition of a conceptual domain of discourse comprehensive enough to support those use cases,

  • a realization of a portion of that conceptual domain with an implementation-neutral but specific and normative logical data model expressed in UML, and

  • the normative derivation of specific structural data units that represent abstract implementation and standardization targets.

These Structural Data Units (SDUs) are abstract: they are independent of implementation or delivery technology and serialization or encoding formats. GeoPose 1.0 specifies one of many possible realizations of the structural data units in JSON.

A key aspect of the GeoPose Standard is that specific use cases are tied to the standardization targets, which prescribe the structure and content of GeoPose data objects. Corresponding implementation examples appear in other documents.

Of course, GeoPose must incorporate or align with other relevant existing standards and common practices. The goal is to fill an interoperability gap in existing standards without reinventing technology in a way that encourages interoperability.

Figure 7 — Document Structure Overview

6.4.  Use Case Summary

The GeoPose use cases involve interactions between information systems or between an information system and a storage medium. The essential role of a GeoPose is to convey the position and orientation of a real or virtual object. The possibility of chained transformational relationships and cross-linkages between chains affords representation of complex pose relationships and a way to bring a collection of related GeoPoses in a common geographic reference frame.

Each use case is identified by a unique ID, has a brief description, and a list of the relevant standardization targets.

6.4.1.  Augmented and Mixed Reality [AR]

Augmented Reality (AR) integrates synthetic objects or synthetic representations of real objects with a physical environment. Geospatial AR experiences can use GeoPose to position synthetic objects or their representations in the physical environment. The geospatial connection provides a common reference frame to support integration in AR.

Table 2 — GeoPose use cases for Augmented and Mixed Reality

IDDescriptionStandardization Target
/geopose/1.0/use_case/ar/01Stored representation of synthetic objectsBasic-YPR, Basic-Quaternion, Advanced
/geopose/1.0/use_case/ar/02Positioning information to support integration of synthetic object data in a representation or visualization of the physical environmentBasic-YPR, Basic-Quaternion, Advanced
/geopose/1.0/use_case/ar/03Report of position and orientation from a mobile device to an AR network serviceAdvanced (time)
/geopose/1.0/use_case/ar/04Input to visual occlusion calculationsBasic-YPR, Basic-Quaternion
/geopose/1.0/use_case/ar/05Input to ray-casting and line-of-sight calculationsBasic-YPR, Basic-Quaternion, Chain
/geopose/1.0/use_case/ar/06Input to proximity calculations Basic-YPR, Basic-Quaternion,/geopose/1.0/use_case/ar/07

6.4.2.  Autonomous Vehicles [AV]

Autonomous vehicles are mobile objects that move through water, across a water surface, in the air, through the solid earth (tunnel boring machine), on the land surface, or in outer space without real-time control by an independent onboard operator. A pose captures the essential information in positioning and orienting a moving object. Sensors attached to mobile elements have their own poses and a chain of reference frame transformations enables common reference frames to be used for data fusion. The possibility of relating the vehicle to other elements of the environment via a common reference frame is essential.

Table 3 — GeoPose use cases for Autonomous Vehicles

IDDescriptionStandardization Target
/geopose/1.0/use_case/av/01Provide accurate visual positioning and guidance based on one or more services based on a 3D representation of the real world combined with real time detection and location of real world objectsBasic-YPR, Basic-Quaternion
/geopose/1.0/use_case/av/02Calculate parameters such as distances and routesBasic-YPR, Basic-Quaternion, Regular Timeseries, Irregular Timeseries, Stream
/geopose/1.0/use_case/av/03Record the trajectory of a moving vehicle.Regular Timeseries, Irregular Timeseries, Stream

6.4.3.  Built Environment [BE]

The built environment consists of objects constructed by humans and located in physical space. Buildings, roads, dams, railways, and underground utilities are all part of the built environment. The location and orientation of built objects, especially those whose view is occluded by other objects is essential information needed for human interaction with the built environment. A common reference frame tied to the earth’s surface facilitates the integration of these objects when their representations are supplied by different sources.

Table 4 — GeoPose use cases for the Built Environment

IDDescriptionStandardization Target
/geopose/1.0/use_case/be/01Specify the position and orientation of visible objects and objects that are underground or hidden within a construction.Basic-YPR, Basic-Quaternion
/geopose/1.0/use_case/be/02Compactly and consistently specify or share the location and pose of objects in architecture, design and construction.Basic-YPR, Basic-Quaternion

6.4.4.  Synthetic Environments [SE]

Synthetic environments contain collections of moving objects, which themselves may be composed of connected and articulated parts, in an animation or simulation environment that contains a fixed background of air, land, water, vegetation, built objects, and other non-moving elements. The assembly is animated over some time period to provide visualizations or analytical results of the evolving state of the modelled environment. Synthetic environments support training, rehearsal, and archival of activities and events. The location and orientation of the movable elements of a scene are the key data controlling animation of in a synthetic environment. Since there may be multiple possible animations consistent with observations, storage of the sequences of poses of the actors, vehicles, and other objects is a direct and compact way of representing the variable aspects of the event. Access to one or more common reference frames through a graph of frame transformations makes a coherent assembly possible.

Table 5 — GeoPose use cases for Synthetic Environments

IDDescriptionStandardization Target
/geopose/1.0/use_case/se/01Record pose relationships of all mobile elements in an environmentGraph
/geopose/1.0/use_case/se/02Control animation of mobile elements in an environment using stored pose time sequencesGraph, Regular Timeseries, Irregular Timeseries, Stream

6.4.5.  Image Understanding [IM]

Image understanding is the segmentation of an image or sequence of images into inferred 3D objects in specific semantic categories, possibly determining or constraining their motion and/or geometry. One important application of image understanding is the recognition of moving elements in a time series of images. A pose is a compact representation of the key geometric characteristics of a moving element. In addition to moving elements sensed by an imaging device, it is often useful to know the pose of the sensor or imaging device itself. A common geographic reference frame integrates the objects into a single environment.

Table 6 — GeoPose use cases for Image Understanding

IDDescriptionImplementation Target
/geopose/1.0/use_case/im/01Instantaneous and time series locations and orientations of mobile objectsBasic-YPR, Basic-Quaternion, Advanced, Regular Timeseries, Irregular Timeseries, Stream
/geopose/1.0/use_case/im/02Instantaneous and time series location and orientation of an optical imaging device using Simultaneous Location And Mapping (SLAM)Basic-YPR, Basic-Quaternion, Advanced, Regular Timeseries, Irregular Timeseries, Stream
/geopose/1.0/use_case/im/03Instantaneous and time series estimation of the changes in location and orientation of an object using an optical imaging device (Visual Odometry)Basic-YPR, Basic-Quaternion, Advanced, Regular Timeseries, Irregular Timeseries, Stream
/geopose/1.0/use_case/im/04Instantaneous and time series location and orientation of an optical imaging device used for photogrammetryRegular Timeseries, Irregular Timeseries, Stream

7.  Logical Model

7.1.  General

The Frame Transform is the core abstraction in the GeoPose Standard. The Frame Transform is a representation of the transformation taking an Outer Frame coordinate system to an Inner Frame coordinate system. This abstraction is constrained in GeoPose v1.0 to only allow transformations involving translation and rotation. The intention is to match the usual concept of a pose as a position and orientation. The formalism that expresses a GeoPose Frame Transform is a pair of Reference Frames, Outer and Inner, each defined by a Frame Specification. The Logical Model relates these elements to represent different types of GeoPose data objects and also defines structures built of time series and linked GeoPoses.

7.2.  UML Logical Model

The normative expression of the UML model is a Sparx Systems Enterprise Explorer project (“eapx”) file located at:

The Logical Model consists of four top-level packages: Core, Time, Sequence, and Targets. The Targets package contains two detail packages: Basic and Composite. The Composite package is in turn subdivided into a Linked package and a Sequence package. The Basic GeoPose targets depend on only the Core package. The Advanced GeoPose target also depends on the Time Package. Composite GeoPoses depend on all four top-level packages.

The coloring of the classes indicates their role in the logical design. Note that the classes and data types defined in the Target packages are the source of structural data units (SDUs) that may be realized as concrete data objects.

7.2.1.  Core

The Logical Model Core contains the essential elements specific to the GeoPose modelled as a transformation between an anchoring Outer Frame and one or more derived Inner Frames. This is described in Figure 8.

Figure 8 — Core logical model

7.2.2.  Time

The time logical model is based on W3C CR-owl-time-20200326.

Only relevant classes, properties, and associations are included. GeoPose v1.0 has a very restricted idea of time position, limited to seconds of UNIX Time. This is described in Figure 9.

Figure 9 — Time logical model

7.2.3.  Sequence

The sequence logical model defines a method for packaging of GeoPose data, where multiple GeoPoses in a sequence share the same outer frame (Clause 4.2.7) and there is a time-dependent changing inner frame (Clause 4.2.8). This is displayed in Figure 10.

Figure 10 — Sequence logical model

7.2.4.  Targets

The Logical Model’s Targets package specify the design of logical data objects and data types that are directly expressed in GeoPose data objects.

The Basic-YPR, Basic-Quaternion, and the Advanced GeoPose SDUs represent single GeoPose objects.

Figure 11 — Basic and Advanced Structural Data Units

The Chain and the Graph GeoPose composite structures respectively represent linear or branching frame transformation relationships.

Figure 12 — Chain and Graph Structural Data Units

The Stream and each of the two Series composite structures represent time series of a single evolving GeoPose.