Preparing search index...

    Interface TracksRequest

    interface TracksRequest {
        bbox?: TrackBoundingBox;
        contexts?: Context[];
        duration?: Duration;
        epsilon?: number;
        from?: Instant;
        geometry?: boolean;
        maxPoints?: number;
        properties?: Path[];
        resolution?: Duration;
        simplify?: boolean;
        times?: boolean;
        to?: Instant;
    }
    Index

    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.

    It selects tracks; it does not clip them. A matching track is returned whole, including the stretches outside the box, so a client gets the approach and the departure rather than a line that stops at an invisible edge. Providers must agree on this or the same query returns different geometry depending on which one answered.

    contexts?: Context[]

    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.

    duration?: Duration

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

    epsilon?: number

    Douglas-Peucker tolerance in metres. Implies simplify.

    from?: Instant

    Start of the window.

    geometry?: boolean

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

    maxPoints?: number

    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.

    properties?: Path[]

    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.

    resolution?: Duration

    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?: boolean

    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.

    times?: boolean

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

    to?: Instant

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