1 of 8

GeoPose 1.0 Change Request

“Links and Context”

Steve Smyth

13 December 2023

Updated 30 May 2024, 1st May 2025

Presented 18 June 2024 at OGC Member Meeting Montreal

2 of 8

“Links and Context” CR

Summary

Targeted standard: OGC GeoPose 1.2
Description:

Links: Define IDs and References to IDs to supported linked GeoPose modules.

Context: Define a “Sticky” rule way to eliminate need to repeat information that is not changing. Implement for Uncertainty (WP 07)

Motivation

The functionality of Composite GeoPoses can be supported with IDs and a method to refer to an ID (i.e. links). Links and Context were used informally in Testbed-19 by some of the non-terrestrial applications.

2

3 of 8

Links: IDs, and References

3

These are extensions and go in the direction of alternative implementations of the Compusite GeoPoses. My opinion is that they should not be an initial target for a minor and mostly backwards-compatible structuring of a GeoPose 1.x. as detailled in the OGC TB 19 Technical Report

Note that they can be implemented additional properties and remain in conformance with GeoPose 1.0. The downside is that the definition and usage of these extensions is not controlled by any standard.

4 of 8

Context Header/Default/Global 1/2

4

Context refers to a mechanism to avoid repeating information common to multiple GeoPose component instances. OGC Testbed 19 showed the advantages of using a context in specifying a coordinate reference system common to a sequence of GeoPoses. This is an attempt to generalize the concept.
TB-19 had an implementation of the “Sticky” Rule suggested by Jérôme St-Louis for coordinate reference system designation in OGC TB-19:

“Sticky” Rule: last seen value in an instance of a module at the current or higher nesting level is remembered/applied. This avoids repeating the module until a changed value is needed.
Implementable by designating certain objects as having “Sticky” behavior.

5 of 8

Context Header/Default/Global 2/2

5

The Sticky Rule approach requires complex rules if it is to worl with both hierarchical (e.g. JSON) and flat encodings.
After discussion, we have replaced the “Sticky” approach: provide context through “global or default and instance properties” that can be set as needed to apply to all members of a component class or a single instance, respectively. This avoids standardizing complex rules about hierarchies and dealing with encodings where the order of properties in an instance is not predetermined.

6 of 8

Context Header/Default/Global

6

After even more discussion, there is general agreement on the need for

a mechanism for defining (global?) values of component property that are constant for multiple component instances - goal is to reduce repetition of unchanging values and
a mechanism for setting instance-specific component property values, overriding any constant values set by the first mechanism

There appears to be agreement to use a naming convention like <component name>.<property name> to identify (global) properties
No agreement yet on what to call the (my new suggestion: global) and (my suggestion: instance) scopes. Class name implies object architecture, which is not possible with some encodings.
Has to work for both hierarchical (JSON) and flat (binary, ddil) encodings

7 of 8

Notes

7

Can be added to standard without breaking anything.
Can apply to any properties, including CRS as in Jérôme’s original suggestion.
The usable class/global properties are defined in the standard for

all components or
may be overridden in a specific component specification

Two class/global properties are proposed as context for v 1.2:

precision - a measure of the variability of sensed samples of a property
accuracy - a measure of the bias in sensed samples of a property

8 of 8

Hierarchical Example

8

{

"position.lat.precision": 0.00002,

"position.lon.precision": 0.00002,

"position.h.precision": 2.0,

"position.lat.accuracy": 0.00005,

"position.lon.accuracy": 0.00007,

"position.h.accuracy": 15.0,

"position": {

"lat": 45.6789012345,

"lon": -12.34566,

"h": 1357.9

},

"position": {

"lat": 45.6799012345,

"lon": -12.34564,

"h": 1357.9

},

"position": {

"lat": 45.6729012345,

"lon": -12.34464,

"h": 1357.8

},

"position": {

"lat": 45.6793012345,

"lon": -12.34564,

"h": 1353.1.

".h.accuracy": 15.0,

"h.precision": 1.0

},

"position": {

"lat": 45.6876012345,

"lon": -12.344162,

"h": 1354.9

}

setting global properties

setting instance properties