ANISE adds supports for SPICE files and introduces a new SPK type for storing covariance information. The purpose of this issue is to allow searching through navigation trajectories for navigation related events, e.g. "when does my covariance drop below X", current implementation only allows searching the estimated state not its covariance.
Requirements
Nyx shall be able to find specific orbit determination events in the results of an OD Process.
Test plans
How do we test that these requirements are fulfilled correctly? What are some edge cases we should be aware of when developing the test code.
Design
This is the design section. Each subsection has its own subsection in the quality assurance document.
Algorithm demonstration
If this issue requires a change in an algorithm, it should be described here. This algorithm should be described thoroughly enough to be used as documentation. This section may also simply refer to an algorithm in the literature or in another piece of software that has been validated. The quality of that reference will be determined case by case.
API definition
Define how the Nyx APIs will be affect by this: what are new functions available, do any previous function change their definition, why call these functions by that name, etc.
High level architecture
Document, discuss, and optionally upload design diagram into this section.
Detailed design
The detailed design *will be used in the documentation of how Nyx works.
Feel free to fill out additional QA sections here, but these will typically be determined during the development, including the release in which this issue will be tackled.
High level description
ANISE adds supports for SPICE files and introduces a new SPK type for storing covariance information. The purpose of this issue is to allow searching through navigation trajectories for navigation related events, e.g. "when does my covariance drop below X", current implementation only allows searching the estimated state not its covariance.
Requirements
Test plans
How do we test that these requirements are fulfilled correctly? What are some edge cases we should be aware of when developing the test code.
Design
This is the design section. Each subsection has its own subsection in the quality assurance document.
Algorithm demonstration
If this issue requires a change in an algorithm, it should be described here. This algorithm should be described thoroughly enough to be used as documentation. This section may also simply refer to an algorithm in the literature or in another piece of software that has been validated. The quality of that reference will be determined case by case.
API definition
Define how the Nyx APIs will be affect by this: what are new functions available, do any previous function change their definition, why call these functions by that name, etc.
High level architecture
Document, discuss, and optionally upload design diagram into this section.
Detailed design
The detailed design *will be used in the documentation of how Nyx works.
Feel free to fill out additional QA sections here, but these will typically be determined during the development, including the release in which this issue will be tackled.