Simple encoding for GeoPose sequences #73
Comments
|
I think you understand that each GeoPose represents a transformation between a domain ("outer") frame and a range ("inner") frame. I am just restating that for clarity. The Sequence forms are shorthand for representing a series of transforms between a single domain and multiple ranges. What I think you mean by a "sequence of outer frames" is the opposite: one inner frame (destination space) and many outer frames (source spaces). In GeoPose 1.0 only the Graph can represent multiple domains and a single range. Speaking in terms of use cases, this means that one can use a Sequence to represent a timeseries of observations of the look angle to the ISS from a fixed location on the earth's surface but only a Graph could represent a timeseries of observations of the ISS from multiple ground locations. Side note: after a year of writing code to use GeoPose in real work, I think it would be simpler and more general to achieve the goals of the Composite structures via linked data. I will present my experiences, workarounds, and proposals in Frascati. |
|
@3DXScape Talking about domain and range referring to outer and inner frames is quite confusing to me. Even in Coverages, there is often some flexibility about what one views about the domain and what is viewed as the range. To examplify how I understand the outer and inner frames, the outer frame could be the position in orbit of the ISS, anchored to a central module (e.g., Zarya) whereas the inner frames could be the position & orientation of some or all of the other modules, solar panels, Canadarm2 etc. relative to that outer reference frame anchored to the central module (or additional object nodes in the hierarchy). For time series, it should ideally be possible to have:
Regarding linked data, I believe it would be useful to be able to reference node IDs within, to specify the transform of only nodes whose internal pose changed (relative to their reference frame) at any given time, regardless of whether they are outer or inner. |
|
I am not certain but it seems like with regard to inner and outer frames, we are not talking about exactly the same concepts. Every GeoPose is associated with two spaces and one homeomorphism mapping continuously points of the the first (domain) to points of the second (range), as well as the inverse. At the suggestion of Josh Lieberman, we have been calling the first space or its associated frame of reference the "outer frame" and the second space or associated frame the "inner frame". "Inner" and "outer" are just labels for the two spaces. It could have been "domain" and "range", "from" and "to", or "one" and "two".
mapped by the frame transformation which is given in mathematical detail in the EPSG registry.:
to the ENU coordinate system of the inner frame
The Basic GeoPoses then make a final rotation of the ENU CS via the specified yaw, pitch, and roll or a unit quaternion. An Advanced GeoPose follows the same model except that the user can plug in the name of an authority, an ID that may select a family of dependent frames, and some parameters that define the specific frame transformation. This offloads the specification of the "outer frame" and the transformation from GeoPose, but places the burden of interpreting the frame specification onto the architect or developer of the code that will receive such data objects. It does open GeoPose up to arbitrary methods of frame and frame transform specification, but at the cost of extra code and deeper understanding by the producing or consuming developer. For the example of a Basic-Quaternion GeoPose
the functionally equivalent (and validated against the JSON-Schema) Advanced GeoPose would be
The "outer" frame for each is the same. The transformation for each is the same. The "inner" frame for each is the same. The final rotation for each is the same. |
|
@3DXScape You are right in that I was somewhat confusing the concept of a single inner frame, where the pose transforms the outer frame into that inner frame, with the graphs which if I understand correctly allow deeper levels of frames (and possibly, multiple frames of references at the same level?) i.e., I was considering more than two frames of references. Thanks for clarifying. To go back to the original question:
If the outer frame is the default geocentric Earth LTP-ENU, and the inner frame is relative to a local engineering coordinate system with an origin in the ISS Zarya module, is there an encoding currently defined in the Draft GeoPose 1.0 Standard to express the ISS position and orientation along a temporal axis without using the graphs? In this use case, the latitude, longitude, altitude is not the position on Earth from where the ISS was observed, but the position of the ISS along its orbit. |
|
@jerstlouis Yes. Use a Basic GeoPose. Talking through how I conceptualize it: If you use the default transformation from WGS 84 geodetic (outer) to LTP-ENU (inner) then you could use the orientation to capture the attitude of the ISS Zarya module with respect to (multiple) local tangent planes. This effectively uses the negative direction of gravity as a vertical reference, the projection of the earth's axis on the LTP as a Y axis, and the cross product of those two as the X axis. I think this makes sense in low earth orbit, since you are still fairly close to the WGS-84 reference ellipsoid. The frame transformation gets you to the location of the Zarya module (inner frame) and the orientation aligns the inner frame with the module. This would be a simple timeseries of Basic GeoPoses - organized however you wish and not using any of the Sequence structures , for example a JSON array: [<geopose>, <geopose>,...,<geopose>]. If you need to add a timestamp to each, the standard allows you to add privately-understood properties as long as you do not use a property name already used (i.e. in the JSON-Schema definition) except for the strict Basic-Quaternion GeoPose. You could also use the Advanced form, but that might be painful. One of the proposed changes for version 1.1 is to add an official optional timestamp to the Basic forms. |
|
Thank you @3DXScape , that does make a lot of sense, but it was very confusing to me that the standard defines sequences and time, yet does not have something pre-defined for that basic use case, and leaves it up to (non-standardized) user-defined constructs. I really wish the advanced forms (and future extensions) just added official optional properties to the basic GeoPoses, as you mention is planned for the timestamp. And I realize that I mixed up the outer and inner frame yet again... The inner frame is LTP-ENU, the outer frame is WGS84 geodetic -- somehow I keep bunding that transformation together as the top-level "outer thing" in my mind (will edit my earlier comment). |
|
Almost irrelevant side comment: Even though an accelerometer (or person) in the module would not directly sense the gravity vector because they are in free-fall, the magnitude of the acceleration vector is about 95% of the magnitude at the earth's surface, so it is well-defined. |
|
@3DXScape Actually I might still be confused with outer WGS84 geodetic / inner frame LTP-ENU. Since the pose does include an orientation (whether using YPR or quaternion), can't the (basic) GeoPose transform to a local engineering CRS that is NOT relative to LTP-ENU, but rather re-oriented?
I think this is partly why I was thinking of WGS84 geodetic / LTP-ENU combined as the "outer frame", and the inner frame the local engineering CRS with an origin at 0,0,0 and based on that re-orientation. |
|
@jerstlouis I think we all wish the timestamp in some form were in all of the forms. As I mentioned earlier, based on a years experience writing code using GeoPoses, I also now think there is a good case for adding some (optional, to preserve backwards compatibility) spatial and temporal links to the core forms and eliminate the need for the complexity of the Composite forms. |
|
@jerstlouis Good question about using an engineering CRS. There are two points supporting our choice:
|
|
@3DXScape To clarify, my question was not about the flexibility, but about the outer vs. inner frame concepts and terminology. I am a big fan of as simple as possible, so I like the basic GeoPose very much (whether quaternion or YPR). What is the outer and inner frame of the basic GeoPose? Would it be correct to say that the outer frame is geodetic WGS84, whereas the inner frame is a (potentially) rotated LTP-ENU (and not simply LTP-ENU, unless the orientation is YPR 0,0,0)? I was thinking of all this as the outer transformation. An inner transformation (from this rotated LTP-ENU) could further customize an engineering CRS e.g., changing the scale and translating the origin. This is what I initially assumed the inner frames of the advanced geopose would be about (and possibly defining not only multiple levels, but also multiple inner frames for different parts e.g., one local engineering CRS for each ISS module or for the docked Dragon). |
|
Yes, each frame is essentially a transformation. The outer frame defines an LTP-ENU in terms of a WGS84 Geographic CRS. The inner frame defines a body-centric coordinate system in terms of the LTP-ENU CRS (The body being the feature with the GeoPose property). Typically the body-centric and LTP-ENU CRS’ share an origin and only differ in their axis orientations. That way a basic GeoPose can be minimal but generalizable to more complex situations.
An AstroPose might have an additional outermost frame, for example, positioning the Earth in a celestial CRS. Two GeoPoses might have the same LTP-ENU outer frame (common to occupants of a train), but differ in inner frame displacement for two passengers.
—Josh
Josh Lieberman, Ph.D.
Director Innovation Programs | Open Geospatial Consortium (OGC)
Office: +1-617-431-6431 | @geospatialogist
***@***.*** ***@***.***> | ogc.org <http://ogc.org/> | @opengeospatial
… On Jan 24, 2023, at 2:07 PM, Jerome St-Louis ***@***.***> wrote:
@3DXScape <https://github.com/3DXScape> To clarify, my question was not about the flexibility, but about the outer vs. inner frame concepts and terminology. I am a big fan of as simple as possible, so I like the basic GeoPose very much (whether quaternion or YPR).
What is the outer and inner frame of the basic GeoPose?
Would it be correct to say that the outer frame is geodetic WGS84, whereas the inner frame is a (potentially) rotated LTP-ENU (and not simply LTP-ENU, unless the orientation is YPR 0,0,0)?
I was thinking of all this as the outer transformation.
An inner transformation (from this rotated LTP-ENU) could further customize an engineering CRS e.g., changing the scale and translating the origin. This is what I initially assumed the inner frames of the advanced geopose would be about (and possibly defining not only multiple levels, but also multiple inner frames for different parts e.g., one local engineering CRS for each ISS module or for the docked Dragon).
—
Reply to this email directly, view it on GitHub <#73 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABGFNBUBWMFXOSXT3BBEHTTWUAR5PANCNFSM6AAAAAAUCL732A>.
You are receiving this because you are subscribed to this thread.
--
Sign up for OGC News
<https://ogc.us4.list-manage.com/subscribe?u=704e02f81107a6caab1568067&id=4e4528fd9d>
|
|
@jerstlouis These were design choices. We wanted to keep the original concept from computer graphics (CG) of a pose as a combination of a position and an orientation. Our analog for position became (in a geographic context) the transformation of one frame to another and our analog for the orientation was simply (a slightly contentious subset of) the original CG formalisms for orientation. Frame transformation takes any point/position from the outer frame to a corresponding point/position in the inner frame, in analogy with how a vector in a CG pose can be thought of as defining a (simple translation) transformation taking one position (frame origin) to another (pose position). Bottom line: we chose to remain parallel with the original concept of pose in CG using a more generalized position concept and keeping the GC orientation concept. GeoPose is a pose. This also allows us to use existing repositories of standardized frame transformations (EPSG, NASA Spice, SEDRIS, IERS, various national mapping agencies), many expressed in proprietary formalisms, unchanged without either incorporating them in our standard directly or requiring (or providing) any standardized access mechanism. Functionally, our frame transform maps well to the frame specifications found in these various repositories. Practically, it is hard to implement many of the transforms in these repositories because the descriptions are often complex and require specialized of the concepts and architecture upon which they are based. |
|
@lieberjosh I liked that example:
and it inspired me to illustrate two quite out-of-this world comprehensive scenarios with a simple extension of the Basic GeoPose (which might not fully conform to the standard): In the first use case, you and me are on-board the first StarShip flight to Mars and this would describe (with additional poses in the sequence) both our position within the ship as well as the position of the ship in a barycentric celestial CRS along a temporal axis in a barycentric coordinate time (either of which I have next to no understanding): {
"crs": [
"http://www.opengis.net/def/crs/OGC/0/BarycentricCelestial",
"http://www.opengis.net/def/crs/OGC/0/BarycentricTime"
],
"sequence": [
{
"time": 2053283731.311,
"id": "http://example.com/nodes/StarShip/1",
"position": { "x": 141123089123.141, "y": 12553789123, "z": 54230981231.924 },
"quaternion": { "x": 0.5131, "y": 0.14325, "z": 0.65354, "w": 0.5376739680327 },
"nodes": [
{
"id": "http://example.com/nodes/StarShip/1/Passengers/Josh",
"position" : { "x": 10, "y": 40, "z": 4 },
"angles": { "yaw": 170, "pitch": 2, "roll" : 0 }
},
{
"id": "http://example.com/nodes/StarShip/1/Passengers/Jerome",
"position" : { "x": 12, "y": 42, "z": -6 },
"angles": { "yaw": -20, "pitch": 1, "roll" : 0 }
}
]
}
]
}In the second use case, Steve joined us on the next StarShip flight and we are now on-board the Mars Express high speed train. Steve is in a different wagon. Similar idea, the position of the passengers is relative to the wagon, and the position of each wagon is anchored to a CRS relative to the Mars ellipsoid, with longitude relative to the the Airy-0 crater. {
"crs": [
"http://www.opengis.net/def/crs/OGC/0/Mars",
"http://www.opengis.net/def/crs/OGC/0/MarsStandardTime"
],
"sequence": [
{
"time": 2053283731.311,
"id": "http://example.com/nodes/MarsExpress/1",
"nodes": [
{
"id": "http://example.com/nodes/MarsExpress/1/Wagons/1",
"position" : { "lat" : 30, "lon": 50, "h": 25 },
"angles" : { "yaw": 30, "pitch": 5, "roll" : -0.5 },
"nodes" : [
{
"id": "http://example.com/nodes/MarsExpress/1/Passengers/Josh",
"position" : { "x": 2.0, "y": 0.8, "z": -6 },
"angles": { "yaw": 1, "pitch": 2, "roll" : 0 }
},
{
"id": "http://example.com/nodes/MarsExpress/1/Passengers/Jerome",
"position" : { "x": 2.2, "y": 0.8, "z": -7 },
"angles": { "yaw": -1, "pitch": 1, "roll" : 0 }
}
]
},
{
"id": "http://example.com/nodes/MarsExpress/1/Wagons/3",
"position" : { "lat" : 29.998, "lon": 50.004, "h": 24.5 },
"angles" : { "yaw": 31, "pitch": 5.2, "roll" : -0.4 },
"nodes" : [
{
"id": "http://example.com/nodes/MarsExpress/1/Passengers/Steve",
"position" : { "x": -5, "y": 0.82, "z": 6 },
"angles": { "yaw": -2, "pitch": 1.5, "roll" : 0 }
}
]
}
]
}
]
}We can easily apply the transformation to local nodes at different hierarchy levels within one or more glTF model(s) defining the Mars Express train / wagon or StarShip, as well as the passengers. We could also easily extend this to rigged human 3D models with a bone skeleton / smooth skinning to accurately present the poses of the passengers. I hope this gives some ideas in expressing such complex scenarios in a simple encoding :)
These new properties and/or value interpretations might conflict with the current Draft Standard. |
|
@jerstlouis Thank you for the example. First, I am totally on board (pun) with the need for an id property. Second, in the CityGML glTF encoding prototype, with mobile agents running around a mostly static background, we found that we needed something almost identical to your "node". This concept maps well to the glTF node. Our implementation was specialized to the local tangent plane Cartesian coordinate system. Since it was, in essence, a normal CG pose in ENU coordinates, we called it "ENUPose" with a structure and usage just like your "node", except that the axes are named "east", "north" and "up". The ENUPose is, of course, not in the GeoPose 1.0 standard, just a lesson learned in a practical application. |
|
@3DXScape to clarify my two examples, in both of them, all of these are extended Basic GeoPoses / nodes:
The axes/parameters of the Scaling and Translation can fit into this as well, and any additional kind of transformations / reference frames should fit well too. Regarding:
Each node (including the root object that I think of as a node) can have or not a sequence, so that different temporal resolution and redundant or interpolated positions are not necessary (only key-frames). |
|
@jerstlouis Thanks for the details + I had not thought about the east and north no longer being east and north! |
|
The output is here. |
|
Thank you @3DXScape that is really helpful, I will want to include this in the ER :) |
|
One of the reasons I like to build things and use code to communicate is that I often do a better job than with natural language. Thanks for continuing this helpful discussion! You will note that I did not address temporal CRS at all. We just didn't go there in v 1.0, even though it is definitely relevant. You could argue that UNIX Time has a well-defined relationship to most other temporal scales so we are just forcing the complexities of dealing with that out of our scope. This can be patched with temporal coordinate conversion. But once you reach high relative velocities, large distances, or accelerated frames (including strong gravity) then a lot of assumptions about being able to sort time-stamped GeoPoses into time order go out the window. It is fun to work on though. |
|
Thanks @3DXScape . About the UNIXTime:
Well there may (or not) be a well-defined relationship between objects in a galaxy far, far away or going close to light speed, and UNIX Time, but it might be quite impractical in terms of local scenarios, or in terms of numeric range / precision. So I think it is essential to be able to support other temporal reference system, and to be able to express every position (if necessary) as within a spatio-temporal continuum. This is why the |
|
There was a discussion in another forum, where you might or might not have been present on whether a GeoPose is an observation (i.e. has its own identity) or a property of an observed entity. I don't think it matters. The PoseID identifies the a distinguished point in the entity's geometry and the timestamp disambiguates multiple observations or properties of the same point on the same entity. The ID is determined by the entity, not the GeoPose data object. Maybe calling it PoseID is confusing but there may well be different IDs for different reference points in the geometry of a single entity. |
|
@3DXScape to add to that, it's a property / observation or statement about at least three points in the geometry to establish an orientation. But my main point is that the hierarchy between the poses (parent pose / pose) may match the model nodes hierarchy one-to-one (making it easy to pose the model), but the object nodes / geometry (e.g., a glTF model) separately does have its own hierarchy. |
Is any encoding defined for a stream of a temporal sequence of GeoPose outer frames? I could not find any.
Something simple like:
[ { "validTime": 1630560671227, "position": {"lat": 47.7, "lon": -122.3, "h": 12.0 }, "angles": { "yaw": 5.514456741060452, "pitch": -0.43610515937237904, "roll": 0.0 } }, { "validTime": 1630560671237, "position": {"lat": 42.7, "lon": -123.3, "h": 11.5 }, "angles": { "yaw": 5.614456741060452, "pitch": -0.43610515937237904, "roll": 4.0 } }, { "validTime": 1630560671247, "position": {"lat": 44.7, "lon": -124.3, "h": 10.2 }, "angles": { "yaw": 7.614456741060452, "pitch": -0.23610515937237904, "roll": 3.0 } } ]As a related use case, consider the following ISS tracking positions (not including orientation, but i this case it is easy to deduct the orientation based on the direction of movement):
{ "sat": 25544, "tRef": 1674280079, "orbitData": [ { "t": 1674280020, "ln": 143.511, "lt": 17.213, "h": 419, "v": 7.662, "s": true }, { "t": 1674280080, "ln": 145.941, "lt": 20.143, "h": 419, "v": 7.662, "s": true } ] }(from https://www.astroviewer.net/iss/ws/orbit.php?sat=25544)
The text was updated successfully, but these errors were encountered: