Closed cperey closed 2 years ago
This message was received by Steve and Christine on Nov 23 2021. Mostly pertains to the OGC GeoPose Reviewers Guide. May possibly be relevant to the standard (e.g., vocabulary)
Made a few changes aligning the standard document where appropriate. Otherwise this relates to Reviewers Guide.
Hi Steve, Christine,
At 1:52 AM +0000 11/19/21, Carl Smyth wrote:
Your comments would be most welcome. An email to both of us will work.
Thanks.
The following comments are from Paul and myself, and mainly pertain to the Reviewers Guide, which we found here:
https://geopose.io/geopose/1.0/temp.html?#vg-introduction-section .
Unfortunately, we have not had a chance to even discuss our comments with each other and we were only able to each do a quick scan of the Reviewers Guide. I compiled Paul's comments with mine.
** General Impression from both myself and Paul:
The Reviewers Guide is a helpful document and easy to follow. I think this can be a valuable resource for other purposes beyond being a guide to GeoPose.
Some of the tables near the end (in 5.5) are a bit confusing because they seem to be repeating the template in separate areas.
There may be some inconsistency in use of some terms. I found one typo (I think) in 5.3.1 in 6DOF explanation, where "post entity" may have been meant to be be "pose entity".
References to ISO/IEC 18026 (the SRM standard):
As you know the current published SRM standard (2009) already supports both the specification of all the terms, as well as concepts and API for the computations of orientation/direction of objects.
The standard supports spatial reference frames that are used in Earth applications (such as GIS applications), in simulation (which in some use of simulations (but not all) are similar/same as computer graphics, including those used for 3D models or CAD), and in celestial bodies/objects (such as planets, moons/satellites, etc.).
There is also openly available implementations of the SRM in C/C++ and Java that cover all the capabilities specified in the standard (plus some more). These implementations have been tested for both accuracy and speed. The accuracy tests used the NGA Gold Data (developed by Craig). The speed tests are important, since real-time systems (including simulations, as well as games) can typically do thousands upon thousands of coordinate calculations in a given simulation farme (60 hz, for example).
Because of its breadth and depth and the standardized terminology established and used by the SRM, we thought it may be beneficial for GeoPose to use the SRM as a referenced international standard and leverage the already established terminology that dates back to late 90s.
In particular, the Guide uses the term "reference frame", which is what the SRM also uses -- except that the SRM specifically separates spatial and temporal reference frames. We think this would be useful for the GeoPose concepts, and therefore referencing and using the terms from the SRM can aid in explaining those concept with less ambiguity.
In SRM parlance, the term Spatial Reference Frame (SRF) is defined to denote a frame that is produced from combining a (abstract) Spatial Coordinate System with a given Object Reference Model (ORM) to specify coordinates in the object-space. A coordinate system alone does not do this, and only defines coordinates in the position-space (not tied to any actual object or object-space, whether the object is real or imagined/virtual). An ORM represents a model of the object -- such as Earth, or room/building, or vehicle, etc. -- and connects the position-space and object-space.
This definition of SRF allows the same coordinate system (for example lat, long, height) to be combined with different ORMs (such as Earth's WGS 84 or Mars model) and produce unique spatial reference frames. The relations between different reference frames then fall out nicely in mathematical sense. Coordinate conversions and coordinate transformations are more clearly defined based on these concepts.
This means an LTP (Local Tangent Plane) is not a coordinate system (as it may be noted in the GeoPose standard in various places), but rather it is a reference frame, and indeed a unique SRF when it is placed at a specific location on the Earth or on some body/object. This, I believe, is also consistent with the spirit of how the term "(Reference) Frame" is defined under Key Concepts (3.1) of the Guide. It may be more appropriate to include ISO/IEC 18026 as a published international standard than to rely on Wikipedia.
I personally think use of the concept of a reference frame (as it is done in the SRM) is more intuitive (once properly explained) than using terms such as coordinate reference system. CRS and SRS end up using too much of the terms coordinate and system and it can be confusing to many who are familiar with coordinate systems based on their prior exposures.
The characterization of the SRM in 5.4 can be improved, as noted earlier. Since the SRM is designed to support the specifications and computations of positions/coordinates, orientations, and distances within (as well as in-between) SRFs, we would suggest revisiting the the table in 5.4.
This may require some discussion between all of us. But in the meantime, we can say that for the given columns in the table in 5.4, the SRM (see 2009 Edition 2) supports the following concepts (which also remain in Edition 3):
For the "Graphic/Virtual Context" column:
Both Physical (such Earth, Moon, etc.) and Virtual (such as 3D model or abstract)
Please see in the SRM "Clause 1 Scope", "Clause 0 Introduction", and "Clause 4.1 Introduction" "Clause 4.2 Spatial Objects and object-space", where the following concepts (excerpted and combined here) are noted.
"All physical objects - including real world objects such as terrestrial and non-terrestrial
All abstract objects including engineering models, virtual worlds, modelling and simulation."
For the "Geographically-reference Local SRS" column:
Entry should be "Yes"
Please see Clause 10.5.2 Specification of local tangent frame SRFs (paraphrased here) for computation of Direction (orientation):
"Specifies a rectangular frame at a specified coordinate with axes aligned to coordinate-component curves at the specified point"
and also Clause 8.5.3 Local Space Rectangular 3D SRFT:
"Specifies a rectangular frame anywhere with any orthonormal axes orientation."
For the "Geodetic CRS" column:
The SRM supports Geodetic SRF for any Earth ellipsoid model.
Please see Clause 8.5.4 Celestiodetic SRFT:
"Generalizes Geodetic to include other planets and ellipsoidal bodies."
For the 6DOF as entity or attribute?" column:
Current (2009 Edition 2 of) SRM specifies Direction as a unit vector w.r.t. a local tangent frame SRF
In the upcoming Edition 3 of the SRM (which was originally near completion in 2011/12) there is an Orientation clause that specifies the orientation of one Local Space Rectangular SRF w.r.t. another with a rotation operator.
For the "Temporality":
Yes, UTC is specified in the SRM.
Please see Clause 4.6.2 Coordinated universal time.
Again, neither myself nor Paul have been able to read the entire Guide in the detail that it deserves, and the above comments are some quick (possibly incorrect) observations. So if our understanding or comments don't make sense, please let us know.
And as I mentioned earlier, some of these topics may benefit from phone/web discussions, as opposed to quick e-mails, especially since concepts of reference frame templates (SRFT), relations between (or bindings of) ORMs and Coordinate Systems, or extending the notions of "geodetic" to other (non-Earth) bodies may require some detailed discussion and/or further explanations.
We can also provide some comments on references to 1278 (DIS) standard, if you would like, especially since some of the concepts in DIS date back to SIMNET and have heavily influenced some of the SRM customer/user base.
Thanks for the opportunity to review and respond, and sorry for not being able to do a more detailed analysis.
Farid