navcore_fix/lib.rs
1//! Own-ship state: assembling and ranking it.
2//!
3//! Three parts, in the order a fix passes through them.
4//!
5//! [`FixBuilder`] accumulates readings -- a position, then a course --
6//! and reports when enough have arrived to form a complete
7//! [`VesselState`]. It does not track where a reading came from: a
8//! Signal K delta, an NMEA 0183 sentence and a recorded passage are all
9//! handled identically, which keeps this logic independent of any one
10//! protocol.
11//!
12//! [`Sources`] ranks multiple candidate positions -- for example a
13//! networked instrument against a local GPS receiver -- and treats a
14//! value that has stopped arriving as no longer current. See its own
15//! module doc for the ranking rules.
16//!
17//! [`VesselState`] is what a client renders: a position, a course
18//! predictor, and a heading line when a compass is available. The
19//! geometry is computed once here rather than by each client.
20//!
21//! [`Simulator`] produces a synthetic [`VesselState`] for a client to
22//! render before a real data source is available.
23//!
24//! # Polar accumulation is out of scope
25//!
26//! `signalk-polar-builder`, a Signal K server plugin, publishes a
27//! vessel's performance polar under `performance.activePolarData`, the
28//! same path a client reads for an imported polar (see
29//! `signalk::polar`). A client-side accumulator duplicating that would
30//! be a second, unsynced answer to the same question that resets on
31//! restart, so this crate does not implement one.
32
33mod sources;
34mod vessel;
35
36pub use sources::{Fix, Freshness, Sources};
37pub use vessel::{
38 FixBuilder, SimulatedWind, Simulator, VesselState, format_latitude, format_longitude, simulated_wind,
39};