Use Case Needs Multiple Vertical Measurements

[cperey]

The use case is a GeoPose representing the position and orientation of a vehicle.

In case of an air vehicle, depending on what sensors are present on board, you may get a combination of the following

• GPS altitude
• Barometric altitude (altitude above mean sea level)
• Altitude above the ground

In case of a underwater vehicle, depending on sensors you may get a combination of the following:

• IMU altitude (relative to starting GPS position)
• Depth (relative to mean sea level)
• Altitude above the sea floor

My understanding is that a geopose has a single vertical measurement.

Is it possible to address this in an upcoming version of the standard?

Teodor Hanchevici Senior Software Lead Kongsberg Geospatial

Phone 613.271.5535 teodor.hanchevici@kongsberggeospatial.com kongsberggeospatial.com

[3DXScape]

Every place the word "relative" appears, there is actually a new reference frame. In effect, there is one pose with multiple expressions, each as contained in a different frame. This can be represented by the Graph structure but maybe we should consider a more specialized structure in a new version.

[lieberjosh]

The issue raised of multiple observations by multiple sensors of the same observed property -- is true of every observed property everywhere all the time. O&M exists to provide formalism to this process. Very rarely are multiple measurements of the same phenomenon at the same time by multiple instruments just reported "as is". A procedure uses these measurements to arrive at the best estimate of the desired property value, with O&M to document where that value came from and how. In some cases it might make sense to report multiple geoposes each representing a different combination of measurements. It would then be useful to more explicitly provide geopose provenance. In most cases, though, interest will largely be in the quality of the estimated geopose judged from consistency between different types of measurements. Someone on the other hand who wants to do their own interpretation of raw sensor measurements probably does not have a lot of use for the summary nature of a geopose stream.

[thanchevici]

If understand correctly, the vehicle will have multiple poses with redundant information (2D position). The pose is defined as with respect to a 3D coordinate reference. This makes me believe that using geopose in my case may not be the right approach. From a communication and encoding perspective, it seems wasteful to send the information multiple times. We are trying to standardize on a data model, so creating a simple data object may be the way to go.

[janerivi]

Thanks for your question @thanchevici!

GeoPose is intended to encode and share the geospatial position and orienation of any real or digital object as a type of frame transform realative to the earth (or potentially other real world entities for advanced geopose), regardless of use-case. That GeoPose might originate from observations and sensor data, but it might also be declared for instance in a planning scenario where you manipulate virutal objects in relation to the world. We want to maximize interoperability between systems and between industries and have opted for a minimalist approach focusing on translation and rotation / rigid frame transform.

For that reason we initially encourage adopters of GeoPose to separate the aspects that does't directly encode the position and orientation (GeoPose) outside the "clean" GeoPose object.

If you have specific needs in addition to expressing position and orientation for your use case, one way you could do that could be to wrap GeoPose inside a larger object that also contains those other properties you might need in your particular case.

There are a lot of aspects that might be relevant in partiuclar use-cases that might not be relevant at all in other use-cases. We do not wish to burden other implementer with handling properties they might not need.

Examples of things that might be associated with a clean GeoPose could the accuracy of the GeoPose values (if geopose is estimated from sensor data), timestamps, relevant sensor readings, other height measurements (above terrain, barometric ++), , dimensional properties such as, size/bounding box, accelleration, rotational speed.

Of all of those examples geopose accuracy and timestamp has frequently been brought up in discussions. It might be so common that we might include it in encoding targets of future GeoPose versions by popular demand.

For future version of the standard we might also add binary encoding targets. That is especially useful if one is going to communicate regular or irregular streams or series, graphs, chains etc of a lot of GeoPoses rather than just individual GeoPoses.

Below is an illustration (not sure if it makes sense in your case) of how a "clean" GeoPose could be wrapped inside a bigger object that encodes additional relevant properties alongside the GeoPose

{
  "geoPose":{
            "position": {
                  "lat": 47.7,
                  "lon": -122.3,
                  "h": 11.5
            },
            "quaternion": {
                  "x": 0.20054473382601948,
                  "y": -0.08111675703887213,
                  "z": 0.3660908114262869,
                  "w": -0.9050852994339209
            }
      },
  "geoPoseAccuracy": {
      "positionErrorMeters": 0.3,
      "rotationErrorDeg":0.9
  },
  "timeStampUnixEpochMS": 1671233472113,
  "sensorReadings":{
          "barometricAlt": 5.523,
          "barometricErrorEstimate: 2
          "heightAboveTerrain": 23.235534,
          "heightAboveTerrainAccuracy": 0.02
  } 
}