Interface TracksRequest

Only return tracks that pass through this box within the window.

Intersection, not containment, and not "where the vessel is now": a vessel that crossed the box an hour ago and has since left still matches.

What comes back of a matching track is set by TracksRequest.clip.

Return only the parts of each track inside bbox.

A client showing a view gets the points it can draw, not every point of every vessel that once crossed it. Each stretch inside the box becomes its own segment, so a track that leaves and re-enters is not joined across the outside. Each segment keeps the recorded point just outside the box at either crossing, so the line reaches the edge of the view without interpolated points. A box crossing the antimeridian clips the same way. Clipping comes before resolution, maxPoints and simplification, so those budgets are spent on the part that is returned.

Resolved by the server before a provider sees it: true when bbox is given unless the client sent clip=false, which returns matching tracks whole. Absent when there is no bbox, since there is nothing to clip to.

Contexts to return tracks for. Defaults to the own vessel when neither contexts nor a bounding box is given.

A bare id is qualified with vessels.; other prefixes are accepted so that aircraft — SAR aircraft appear in AIS — can be queried too.

Window ending at to, as an alternative to giving from.

Douglas-Peucker tolerance in metres. Implies simplify.

Start of the window.

Include geometry. Defaults to true; set false to return metadata only.

Upper bound on the number of points returned per track.

A budget rather than a fidelity contract, for clients that must bound transfer and rendering cost regardless of how convoluted a track is.

Signal K paths to return alongside each position, as arrays nested to match coordinates in the same way coordTimes is.

A client colouring a track by speed, or deriving a route from a recorded passage, otherwise has to query the History API for those paths and join the two responses by timestamp — the row-alignment problem coordTimes exists to remove, reintroduced one level down.

Optional for a provider: one that cannot co-record other paths returns the geometry alone and omits them from TrackProperties.appliedProperties, so a client can tell what it actually received rather than inferring it from absent data.

Values are matched to the nearest sample of that path, not to one sharing the position's timestamp. Paths arrive from different talkers on their own cadences — position and speed over ground typically a couple of hundred milliseconds apart — so an equality join returns null for every point while appliedProperties still claims success. A provider that buckets should match within a tolerance of its bucket width; a value that genuinely has no nearby sample is null.

Minimum spacing between returned points.

Normalised to hours and below before it reaches a provider, so total({ unit: 'milliseconds' }) is always safe on it — Temporal.Duration refuses that for day-and-larger units without a reference date, since their length is timezone-dependent. Windows here are absolute, so P1D means 24h and arrives as PT24H. Years and months are rejected: a month is 744h from January and 672h from February, so it does not describe a spacing. So is anything below a millisecond, which is the finest granularity a timestamp carries.

Simplify the geometry, dropping points that do not change the line's shape beyond epsilon.

With a bounding box and no explicit epsilon, an implementation should choose a tolerance suited to the size of the box.

Include the recording time of each point as properties.coordTimes.

End of the window. Defaults to now when from or duration is given.