Interactive visualization for basic GeoPose and a transform library - in progess

[janerivi]

To support intuitive understanding of the parametres of Basic GeoPose

Currently implemented:

• can change the polar vs the equatorial radius
  • Lengths are relative in this visualization with equatorial radius starting equal to 1 and the polar radius is smaller in the same proportion as the WGS84 ellipsoid - allowing lat,lng coordinates to hit the right spot on the texture map in its initial configuration.
• can change the gps lat,lng coordinates for the LTP-ENU frame of reference
• a visual representation of the frame a reference box with colored East North Up Axis
• move around the globe with mouse

Started

• separate module for GeoPose transforms and other related mathematical operations.

Planned:

• Orientation params supported and visualize together with the LTP-ENU frame to get complete visualization of a GeoPose
• support height above ellipsoid
• ability to manipulate two or more GeoPoses
• Visualize the transforms between them

[MikelSalazar]

Great, did you use the code snippet I presented at ISMAR? (just to verify that there was no issue with it).

I am interested to see how you plan to represent the orientation on top of the position (Maybe as a simplified weather vane?) Because I have been struggling with how to properly convey those two visual elements together.

[janerivi]

No, I started from scratch to get the math under my skin. However your code snippet is for a sphere while I have created my code for the wgs84 ellipsoid where you have different polar vs equatorial radius. From far a way its almost impossible to notice the difference, but when you get close the north/south difference can be many many kilometres if you are not close to the poles or equator. Since I intend to use the library for placing buildings within a few cm I cannot risk having the calculations off by many kilometres because of the discrepency between geocentric and geodetic latitude.

[3DXScape]

Nice work and great graphics! I first encountered the GeoPose domain in the early days of distributed interactive simulation (DIS) for military planning, rehearsal, and analysis. This is the area partly covered by the CDB SWG in OGC now. In DIS, there are thousands of independent simulation nodes, each holding a local replica of reality and sharing changes with the other participants over a network - local or long-haul. The problem of accurately sharing changes in reality is called "fairness" or "fair fight" in DIS. Most of the information about change involves poses, with many nodes maintaining a local model of the pose of all of the moving parts of their reality with an accuracy of a few cm - thousands of models of thousands of objects. In the 1990's, it was hard to do all of this in real time. Here's a sketch of what we used (in Java, for language neutrality reasons though typically implemented in C++), along with a estimate of the cost of computation: Burchfiel-Smyth-Topocentric-1990.pdf As J-E notes, it is important to use a close approximation to the earth's shape if independent agents and elements are to meet accurately in virtual space. From my experience, shared algorithms are important to reach this goal. .

[cperey]

Status update, please?