1 of 16

GeoPose WP-07

“Uncertainty”

Steve Smyth

20 February 2025

Updated 28th April 2025, 7th and 22nd May 2025

2 of 16

Metadata

Targeted version: OGC GeoPose 1.2
Scope: new elements to convey numerical uncertainty estimates
Number of parts: 1
Status: [New|Progressing|Proposed|Accepted]
Expected proposal submission: Summer 2025

2

3 of 16

Summary: Item 1/1

Name: Uncertainty Specifier
Motivation (why): GeoPose developers have asked for a means to specify uncertainty measures, such as precision and accuracy, for numerical values in GeoPose components.
Description (what): An “Uncertainty Specifier” is a GeoPose object that establishes precision or accuracy values for GeoPose components containing numerical values. Any proposal must recognize that some encodings may be hierarchical (e.g. JSON) and some may be flat. Even within a a single level of a hierarchical encoding, there may be no reliable way to enforce and ordering of properties to ensure that values are seen before they are used.

3

4 of 16

A Proposed Model: Attributes of Numerical Properties

Class Diagram:

4

5 of 16

Bigger Buckets

The buckets that I have been describing are tiny and only hold a single number. The intended application of the number is hinted at by a designation of

accuracy (quality of approximating a true value),
precision (repeatability of measurements of a specific property by a specific sensor),
resolution (granularity of the encoding), and
confidence/credence (accuracy as applied to categories rather than numerical values)

5

6 of 16

Bigger Buckets

The motivation for small generic buckets is twofold:

Future-proofing: we will have components with approximate numerical values – mostly position and orientation, but new components might have new uncertain numerical properties.
Sensor-specific uncertainty: for example, a sensor might report multiple values e.g., heading, pitch, and roll, but with one of the values may become untrustworthy due to a failure. Tagging that value as inaccurate allows this to happen dynamically, and in terms of the transmitted values rather than a composite value in a more capable/bigger bucket. Infinite uncertainty =

6

7 of 16

Bigger Buckets

But larger buckets defining uncertainty of position or orientation definitely make sense too. There is a lot of experience with some approaches to describing spatial uncertainty where the “uncertainty descriptors” are more targeted and complex.

7

8 of 16

Global and Instance Properties

The Uncertainty Specifier extension defines a four of optional Uncertainty Scope Properties (UGPs), “precision”, “accuracy”, “resolution”, and “confidence” that are defined for every numerical or categorical property of GeoPose component. A UGP has a precision or accuracy Uncertainty Value (UV) representing bounds on deviation from the means of repeatable and true values, respectively. The standard could provide a non-normative suggestion that for a large number of repeated samples, 95% of such calculated confidence intervals would include the true value of the parameter. For a normal distribution, this could be a 2σ deviation from the true value of the mean. GeoPose only provides a container. Interpretation of the Uncertainty Values is application dependent.

General pattern: “<component>.<UGP>.<property name>”: <UV>
Example: “position.precision.h”: 2.0
Example: “position.accuracy.lat”: 0.00005

8

9 of 16

Instance Properties 1/2

The Uncertainty Specifier extension also defines a four optional Uncertainty Instance Properties (UIPs), “precision”, “accuracy”, “resolution”, and “confidence” for every numerical or categorical property of GeoPose component. UIPs identify UVs in the same way as for UGPs, but only apply to the containing single component object and may only appear within a component, as an optional but predefined, property.

9

10 of 16

Instance Properties 2/2

It is an implementation choice how Uncertainty specifications are associated either with a bounding object, i.e. present in UGPs are overridden by a component instance with a UIP denoting the same component property. Additionally, it is an implementation choice on how a UV should be determined if both a UCP and UIP are defined. The standard should suggest that a UIP should override a UCP, if both are present and the implementation does not explicitly specify conflict resolution.

General pattern: “.<UIP>.<property name>”: <UV>
Example: “precision.h”: 2.0
Example: “accuracy.lat”: 0.00005

10

11 of 16

Usage Notes 1/4

If the structure of an encoding is a hierarchical document, recommend that

If a specific instance of a component needs an Uncertainty Specifier, then add as a UIP an additional data member in that component.
If every component instance has different uncertainty, then each instance can have its own UIP.Uncertainty Specifier(s).
If all instances of a component within a containing object have the same uncertainty properties, then they can be specified once with single UGP value.

If the structure of an encoding is not hierarchical, then the encoding standard must specify whether and how UVs are represented. Example: define a header structure containing UGPs and ensure that it is seen before corresponding instances are read..

11

12 of 16

Usage Notes 2/4

12

precision - repeatability/deviation from mean of a large number of samples.

component name and uncertainty measure (2 sigma?)
Example: “precision”: {“position”: {“lat”: 0.00002, “lon“: 0.00002, “h”: 2.0}}
“Sticky” Rule: last seen values at this or higher nesting level is remembered so it does not have to be repeated until a change is needed

accuracy - degree of deviation from true value.

component name and uncertainty measure (2 sigma?)
Example: “accuracy”: {“position”: {“lat”: 0.00002, “lon“: 0.00002, “h”: 25.0}}
“Sticky” Rule

13 of 16

Usage Notes 3/4

13

resolution - A specification of the granularity on the reported values. For example, height might be reported with a granularity of 1 meter. Resolution is not related to the fidelity of a measurement's to a property’s true value, nor to the repeability of measurements of a sensed property.
confidence - A numerical value that describes the level of confidence for a categorical assignment. For example, this might be the confidence in a predicted semantic class. Example: confidence 0.65 that true semantic class is “door”.
default?

Standard might specify a global default for some or all component numerical properties so that precision and accuracy are always well-defined.
This has been mentioned but not vigorously defended.

14 of 16

Usage Notes 4/4

14

What about confidence in a predicted semantic category? Can we use an accuracy value to indicate confidence the the predicted category? Is that better than creating an additional property named confidence or credence or belief? Many people consider belief to be a binary value indicating the truth of an is-a statement. Overloading accuracy to quantify confidence in a belief is not a standard approach. This makes creation of a third type of uncertainty, maybe credence, seem reasonable.

15 of 16

Example

15

{

"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

},

"position": {

"lat": 45.6876012345,

"lon": -12.344162,

"h": 1354.9

}

16 of 16

Original Discussion and Motivation

16

Context refers to 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.

There might be a better name than “Sticky”, for example “hierarchical value inheritance” or “hierarchical context” or ….
Limiting the types to which the “Sticky” Rule applies limits the amount of context that must be stored in traversing a dataset.
Can be added to standard without breaking anything.
Can apply to any inheritable properties, including Jérôme’s original suggestion.
Requires parsing each entire branch to find possible Uncertainty Specifiers/