pub struct Route {
pub uuid: String,
pub name: Option<String>,
pub description: Option<String>,
pub waypoints: Vec<Waypoint>,
}Expand description
A route, in the order its waypoints are sailed.
Fields§
§uuid: StringSignal K’s UUID, and the identity everywhere else too – the same
choice waypoints::Waypoint::uuid’s own doc explains, for the
same reason: one id, whatever server holds it.
name: Option<String>What the mariner calls it.
description: Option<String>Anything they wrote about it.
waypoints: Vec<Waypoint>In the order they are sailed.
Implementations§
Source§impl Route
impl Route
Sourcepub fn new(uuid: impl Into<String>, waypoints: Vec<Waypoint>) -> Self
pub fn new(uuid: impl Into<String>, waypoints: Vec<Waypoint>) -> Self
A fresh, unnamed route through these waypoints. The caller
supplies the id: minting one needs randomness, and this layer
deliberately has no source of it, the same reasoning
waypoints::Waypoint::at’s own doc gives.
Sourcepub fn legs(&self) -> impl Iterator<Item = (&Waypoint, &Waypoint)>
pub fn legs(&self) -> impl Iterator<Item = (&Waypoint, &Waypoint)>
The legs, in order: each is the pair of waypoints it runs between. Empty for a route of fewer than two waypoints, which is a position rather than a plan.
Sourcepub fn distance_nm(&self) -> f64
pub fn distance_nm(&self) -> f64
Total distance in nautical miles, each leg a rhumb line – the
same convention nav_math::rhumb and this whole codebase’s own
charts already draw a route leg as.