search

opengeospatial / GeoPose

OGC GeoPose development.
Apache License 2.0
41 stars 16 forks source link

Discrepancies in Frame Specification IDs #58

Open ckwichael opened 1 year ago

ckwichael commented 1 year ago

Hi everyone,

I apologize if this is not the correct forum to raise this issue, but I am attempting to create an implementation based on the draft standard located here: https://docs.ogc.org/dis/21-056r10/21-056r10.html. While implementing the different frame specification types I have found a few things that I have questions about. I have been using the UML diagram located in section 7.2.1 of the standard as a guide but it seems to be missing the Translate-Rotate frame specification found in various examples throughout the document. It also seems like there are inconsistencies in the IDs given in the examples. In the Advanced SDU json example in section 9.2.4 the ID given for an ENU spec is LTP-ENU, but in the Graph SDU example (9.2.5) the ID is listed as /Extrinsic/LTP_ENU, but both use the same authority. There is a similar discrepancy with the Translate-Rotate spec: in the Graph SDU example the ID is /Intrinsic/Translate-Rotate, but in the Regular Series SDU example (9.2.7) it is listed as RotateTranslate.

I know that these are just examples to show the shape of the data and may not necessarily have 100% valid values, but I cant seem to find a comprehensive list of frame specifications with the data they use and their IDs for the /geopose/1.0 authority, does that exist anywhere?

3DXScape commented 1 year ago

The authority, id, parameters in the FrameSpecification are placeholders designed to accommodate incompatible external schemes. The standard does not give any guidance on the use of these fields nor any examples. I think it should and will add at least an ISO19111 definition for the frame transform from WGS84/EPSG 4326 to LTP-ENU and give it as an example for Advanced that is equivalent to Basic-Quaternion. A set of a dozen or so common frames would be nice to have.

The authority names should be internally consistent, even though they are just examples and not normative.

cperey commented 1 year ago

Thank you, @3DXScape

I believe you said (in a meeting a few minutes ago) that the discrepancies @ckwichael has found in IDs could, indeed, be errors to be corrected.

When @3DXScape has checked over, it would be fantastic to have any errors clarified (here or elsewhere).

ckwichael commented 1 year ago

Ah that makes sense. In my implementation I added a few interfaces and an authority provider so that any consumers of the library could implement any custom frame specifications that they wanted. Should the TransitionModel located in the StreamHeader also have a set of common models? If so should I add a new issue for that?

3DXScape commented 1 year ago

Values for the TransitionModel are in an enumeration in the UML model Sequence Package. The v1.0 choices are "Interpolated" or "None". I realize that "Interpolated" does not give you much information except to imply that the various components of the poses between samples are continuous in time. None implies discontinuity but this should be made explicit and probably made into a requirement. This is an area that could benefit from more explanation and a broader set of choices, including ones that are differentiable or use dynamical models of moving objects, Kalman filters, or "dead reckoning". An issue on "Transition Model Needs More Definition" would be helpful.

3DXScape commented 1 year ago

I looked at the authorities and IDs in the examples and realized that they are placeholders but look like they might be "official" names and IDs. I will create a "corrigendum 1" branch in the standard and make the authority, ID, and parameters at least internally consistent. It would be good to synchronize a "corrigendum 1" release of the standard with a request for the TC to move the standard out of "draft" status, perhaps this summer?