pub struct Track {
pub uuid: Option<String>,
pub name: Option<String>,
pub description: Option<String>,
pub color: Option<String>,
pub distance_m: Option<f64>,
pub points: Vec<Position>,
pub timestamp: Option<String>,
pub recorded_from: Option<String>,
pub recorded_to: Option<String>,
}Expand description
A recorded track, as the wire carries it.
Not a Signal K spec resource type – confirmed against
signalk-server’s own dist/api/resources/index.js: only
waypoints/routes/regions/notes/charts are ever registered
by the server itself. tracks only exists at all once a server’s own
@signalk/resources-provider plugin has been configured with it as a
“custom” collection – at which point it answers the exact same
generic GET/POST/PUT/DELETE shape every resource type here
does, this module’s own doc already explains why. No isSignalKResourceType
schema validates a write against this shape server-side the way one
does for routes/waypoints, so it is tracks’s crate’s own
choice, not a spec’s – see tracks::signalk’s own doc, which this
exists to serve, for the fuller reasoning and for why it is not
simply Freeboard-SK’s own (undocumented, display-only) tracks
convention adopted wholesale.
Fields§
§uuid: Option<String>The server’s own id, once it has one – the same None-until-
published convention Route::uuid uses, for the same reason.
name: Option<String>What the mariner calls it.
description: Option<String>Anything they wrote about it.
color: Option<String>A hex colour ("#rrggbb"), feature.properties.color, the same
place Waypoint::color already lives – but a free hex value
here rather than Waypoint::color’s own small named palette:
telling several tracks apart on one chart at once wants more
distinct choices than a waypoint marker’s four colours give.
distance_m: Option<f64>Total length, when the caller has one to send or the server sent
one back. Never trusted over a fresh local recomputation –
tracks::signalk’s own doc gives the same reasoning
routes::signalk’s already does for a route’s own distance.
points: Vec<Position>The line itself, in the order it was recorded. No per-point
names the way RoutePoint can carry one: a recorded point has
nowhere a name would come from, unlike a route’s own waypoints,
which a mariner placed and could label as they went.
timestamp: Option<String>When the server itself last saved this – the generic resource
wrapper’s own top-level timestamp, RFC 3339, confirmed live
("$source":"resources-provider" alongside it in a real GET
answer). None only for a Track not yet published, which has
no server-assigned timestamp to carry – one this crate wrote
itself never sends this back up; it is read-only, the server’s
own to set. Kept as the plain string rather than parsed: RFC 3339
UTC timestamps already sort correctly as plain text, and nothing
in this workspace pulls in a date/time crate merely to hold one.
recorded_from: Option<String>When recording actually started, RFC 3339 –
feature.properties.startTime. Unlike Self::timestamp, this
is the mariner’s own client’s to set, and is sent up on a
write.
recorded_to: Option<String>When recording actually stopped, RFC 3339 –
feature.properties.endTime. Same as Self::recorded_from.