GNSS

[gwbres]

Summary

I would like ANISE to propose options to deal with GNSS orbits.

In GNSS navigation, we resolve (x, y, z, dt) by gathering (sv_x, sv_y, sv_z, sv_dt) from 4 satellite vehicles.
(sv_x, sv_y, and sv_z) are streamed over radio signal by each individual vehicle and expressed in ECEF with specific Ellipsoid shape that is tied to each constellation.

This proposal adds new methods to attach reference Frames, defines a few constant values to build the most common Ellispoid shapes, and a few macros to build Orbits from (sv_x, sv_y, sv_z) directly, in the correct coordinate system

Architectural Changes

Minor modifications to Frame, Ellipsoid and Orbit structures

New Features

No change, but all of this could be wrapped in a gnss feature if you'd like to

Improvements

No change

Bug Fixes

No change

Testing and validation

I have no idea how to test that, other than updating my applications to actually use it

Documentation

Ellipsoid definitions come with a link to standard specs

[gwbres]

Typical GNSS specs define the flattening and the semi-major axis. I had to search for the semi-minor axis radius. I used one of your formulas (M+m)/2, to obtain the polar radius, which is rarely given

[gwbres]

I presume the best thing to do, would be to propose new [Frame] constants, similarly to EARTH_J2000, for example EARTH_WGS84 (following existing names), or better (IMO) GPS_WGS84 because it is more classical. If we had those, it would give a direct coordinate system to work with.

But I don't know if it can relate to the existing NaifID system.

I'll let you take a look at the current state, and let me know what your ideal solution is

[gwbres]

What is the current behavior of ANISE, when two Orbits are considered and they do not have the same shape ?
In my applications, this scenario can happen when using azimuth_elevation_range_sez() where I presume, we should pay attention that both orbits should be expressed in the same frame ?

[ChristopherRabotin]

What is the current behavior of ANISE, when two Orbits are considered and they do not have the same shape ? In my applications, this scenario can happen when using azimuth_elevation_range_sez() where I presume, we should pay attention that both orbits should be expressed in the same frame ?

If the frames of two different orbits have different shapes, it should only affect the computation of the latitude, longitude, and altitude because all of these are computed with respect to the geoid. The equality between two orbits does not look at the shape of the frames, only the orientation and center. PartialEq calls eq_within, which does that frame check: https://docs.rs/anise/latest/src/anise/math/cartesian.rs.html#312-319 .

[gwbres]

moved to rtk-rs/gnss#8