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):
- Norkart AS
- Open Site Plan
- Open AR Cloud Association
- Ordnance Survey
- School of Management and Engineering Vaud, HES-SO University of Applied Sciences and Arts Western Switzerland
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:
A basic form with no configuration options for common use cases,
An advanced form with more flexibility for more complex applications, and
Composite GeoPose structures to support time series chain, and graph structures.
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:
Basic — Satisfy most use cases — EPSG 4979 Outer Frame
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
LTP-ENU inner frame (Clause 4.2.8) oriented by unit quaternion: Basic-Quaternion Target
Configurable inner frame (Clause 4.2.8) oriented by unit quaternion — Flexible enough for complex use cases: Advanced Target
Composite — Efficient structures for linked and sequential GeoPoses
Linked linear sequence of poses: Chain Target
General linked poses: Graph Target
Sequence
Series
Time series with constant time spacing: Regular Time series Target
Time series with per-GeoPose time: Irregular Time series Target
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
ID | Description | Standardization Target |
---|---|---|
/geopose/1.0/use_case/ar/01 | Stored representation of synthetic objects | Basic-YPR, Basic-Quaternion, Advanced |
/geopose/1.0/use_case/ar/02 | Positioning information to support integration of synthetic object data in a representation or visualization of the physical environment | Basic-YPR, Basic-Quaternion, Advanced |
/geopose/1.0/use_case/ar/03 | Report of position and orientation from a mobile device to an AR network service | Advanced (time) |
/geopose/1.0/use_case/ar/04 | Input to visual occlusion calculations | Basic-YPR, Basic-Quaternion |
/geopose/1.0/use_case/ar/05 | Input to ray-casting and line-of-sight calculations | Basic-YPR, Basic-Quaternion, Chain |
/geopose/1.0/use_case/ar/06 | Input 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
ID | Description | Standardization Target |
---|---|---|
/geopose/1.0/use_case/av/01 | Provide 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 objects | Basic-YPR, Basic-Quaternion |
/geopose/1.0/use_case/av/02 | Calculate parameters such as distances and routes | Basic-YPR, Basic-Quaternion, Regular Timeseries, Irregular Timeseries, Stream |
/geopose/1.0/use_case/av/03 | Record 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
ID | Description | Standardization Target |
---|---|---|
/geopose/1.0/use_case/be/01 | Specify 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/02 | Compactly 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
ID | Description | Standardization Target |
---|---|---|
/geopose/1.0/use_case/se/01 | Record pose relationships of all mobile elements in an environment | Graph |
/geopose/1.0/use_case/se/02 | Control animation of mobile elements in an environment using stored pose time sequences | Graph, 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
ID | Description | Implementation Target |
---|---|---|
/geopose/1.0/use_case/im/01 | Instantaneous and time series locations and orientations of mobile objects | Basic-YPR, Basic-Quaternion, Advanced, Regular Timeseries, Irregular Timeseries, Stream |
/geopose/1.0/use_case/im/02 | Instantaneous 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/03 | Instantaneous 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/04 | Instantaneous and time series location and orientation of an optical imaging device used for photogrammetry | Regular 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.