RFC: track API

[tkurki]

There have been sporadic, uncoordinated efforts towards having a common API for accessing track related data. With the advent of History API it is high time to formalise an API and align the implementations.

Use cases

• display all self/all/some collection of vessels' tracks on a map or in a list, based on map bounding box (bbox) and/or timespan
  • note that bbox can be tiny or span the globe, affecting resolution
• select a track and display metadata about it
• track metadata:
  • timespan
  • length
  • bounding box
  • name
  • number of points?
  • SK context
  • vessel name
  • is self
• select a track on the map and zoom to it
• download a track's data (GPX, GeoJSON, PMTiles)

The following highlighted items are frequent Freeboard-SK actions.

• Upload one or more tracks and associated metadata
• View a list of the uploaded tracks by name / id
• Select tracks to view on map.
• Select a track and download it with metadata in GPX
• List tracks' metadata for a given timespan for self/all/some collection of vessels with geobounds

This relates to both History API, that allows querying navigation.position over time resembling a track API, as well as Resources API, that has similar constructs, namely routes, as first class citizens.

More related work

• https://github.com/SignalK/tracks
• https://github.com/tkurki/signalk-to-influxdb2
• https://github.com/tkurki/signalk-to-influxdb
• https://www.npmjs.com/package/signalk-trackviewer
• https://github.com/panaaj/signalk-pmtiles-plugin?tab=readme-ov-file#charts-containing-track-history

[JonyIvy]

At first look it seems that the basic functions for data retrieval are already in the History API and most of the points made above seem to be more high-level / application related and should therefore rather be implemented by each consumer/app.

From a data-retrieval point of view, the bbox filter would be very useful though, maybe this can be added to the History API?

Regarding the metadata:

• timespan: Can be easily deduced from the last - first timestamp of the points. This is then only the timespan for this section of track (limited by time window or bbox), not the track itself. It's hard to know without user interaction when the track starts and when it ends, as position data recording is continous.
• length, bbox, # of points: can be easily calculated (by the consumer/plugin/app, using existing geodata libraries) given the points.
• name: where should that come from? Tracks are only a number of points (so far).
• vessel name: can be part of the query. Though probably a waste of space to include in every data point.

[tkurki]

Added point about simplification.

[JonyIvy]

Simplification of the track (removing points close to each other or all in a straight line that seem redundant for the general shape of the track) is dependent on use case. If for example you just want to have an overview where you went during your last vacation, the track can be simplified (a lot), which saves data, but if you want to collect data for bathymetry, you will want to keep more points. If you need the exact length of the track, you shouldn't simplify at all because that would reduce the length.

So that needs to be optional and configurable. And it is already offered by geodata libraries, so no need to re-invent. signalk-trackviewer uses turf.js for simplification. It would be convenient to have simplification from the API, but it could also be handled separately.
Last time I checked, influxdb2 did not offer simplification of geo-coordinates. If it did, I would be all for having simplification as part of the API.

[tkurki]

it could also be handled separately

If you zoom out in time and space so that "tracks on the map" use case covers lots of data simplifying in the client becomes very inefficient and sampling misses detail. You want to push this upstream to the server or db that may have native simplification and/or aggregation.

Imho database X not having feature Y should not be a factor in developing this. More so as Influxdb2 is definitely not the latest and greatest.

[JonyIvy]

So Influxdb2 is no help here and the options are: Simplify on the server or on the client.

I don't know if simplifying on the server is more efficient than on the client. The only clear disadvantage of doing it on the client is the transfer of too much data (but in our case usually WiFi or LAN, so not too terrible). In my case the clients (smartphone, tablet, notebook) have faster CPU and the same or more RAM than the server (pretty much loaded up RPi 4).

Of course if you could have streaming simplification on the server, in other words simplifying the track on the fly while receiving it from the database, that would be an advantage for server-based. But I don't think the algorithms can work this way. AFAIK you need the whole data set and run the simplification on that.

Then think three people on board using FB and zooming around the chart. Three times the load on the server. Wasn't one fun part of webapps that you can outsource the computing to CPUs that are powerful, mostly idle and powered by someone else's electricity?

Thinking FB, it could get the full track (time based) and cache that data, then simplify the parts of the track that it really needs to display. What is bad for performance in Javascript apps is really too many points on the map rather than just holding them in RAM. When the map is panned or zoomed, FB could go into its own cache and get the data there. No extra server request for panning and zooming.

I'm not trying to push this in one or the other direction, just brainstorming.

[JonyIvy]

Just did a test with trackviewer to see what amounts of data we are talking about.

Two weeks recorded track, ~30.000 points, ~300 nm:
270kB data transfer in 2.7 seconds (-> the limitation doesn't seem to be the network connection, rather the db query on the server).

The simplification time in the client (Macbook) is not noticeable (ran tests with and without simplification). Probably the time for simplification is compensated be the reduced rendering time of the fewer points. (simplification reduced from 30.000 to 640 points)

[panaaj]

@tkurki Some additional current Freeboard use cases:

• Retrieve tracks for vessels (other than self) within a given radius.
• Retrieve track for self at varying resolution for the following time spans:
  1. the last hour
  2. the previous 23 hours (prior to 1.)
  3. beyond 24 hours

The Track API response should contain track segment properties to enable the ability to render a track based on depth, temperature, etc.

[dirkwa]

I've taken over maintenance of SignalK/tracks and have been modernising it against a live boat. Rather than argue about interface shapes, I want to put a concrete user workflow on the table, because I think the reason this thread has been hard to close is that "track API" has been standing in for several different things.

The workflow

1. Position is recorded automatically — by a history provider, or by the tracks plugin itself.
2. I see where I've been, drawn on the plotter.
3. I pick a piece of that and save it as a named track. Now it exists as an object, not a live trail.
4. I turn it into a route, and optionally reverse it — I want to get back out of the reef pass the way I came in.
5. I send it to a friend as GPX so they can follow the same line.

And one that isn't about my own boat at all:

6. I click any AIS vessel — say the local ferry threading a pass I don't know — say "record track", and later reuse its line as my route.

I checked TimeZero, which is about as mature as commercial navigation software gets: own-ship trail recorded at 1 s intervals, kept for 30 minutes to 20 days, right-click "Create Route", and a "Track Back" action that converts and reverses in one step for retracing your way back out. Clicking an AIS target and recording its track is a normal thing to want, and Signal K already has every AIS target in the data model.

The recording half of that already works today, server-side: on my boat the tracks plugin is currently accumulating 115 distinct contexts — every vessel in AIS range, not just self. What's missing is the step after: being able to say "keep that one".

Why this belongs on the server, not in a chart plotter

The obvious place to build "save this track" is inside the plotter that draws it, and I think that would be a mistake.

A saved track is a boat asset, not a browser asset. If it lives in Freeboard, it exists on the tablet Freeboard was open on. It isn't there on the phone, it isn't there in a different plotter app, and no other plugin can reach it — an anchor-watch plugin can't ask "what was my track while I was on this anchor", a logbook plugin can't attach a passage to a leg, a route planner can't offer "start from a track you've saved".

Signal K solved that shape already for routes and waypoints: they are server-side resources, so every client sees the same ones and any plugin can use them. Tracks are the odd one out. Freeboard's own code shows the consequence — the GPX export builds a track from selfTrail, which the source describes as "vessel trail from indexedDB". That is per-browser storage, and it is the only reason a track today can't be shared between two devices on the same boat.

So the ask isn't "give Freeboard a track feature". It's: put tracks where routes already are, and then Freeboard, any other plotter, and any plugin get them for free.

What's already there, and the one thing that isn't

Most of this workflow already exists in pieces:

• Freeboard-SK has a GPX module (src/app/modules/gpx/) whose save dialog already has a tracks slot next to routes and waypoints.
• Route reversal already exists — course.service.ts activateRoute(id, startPoint, reverse) and a navigation/course/activeRoute/reverse endpoint.
• Recording is solved twice over, by history providers and by the tracks plugin.

But look at what Freeboard actually puts in that GPX file today (gpxsave-dialog.facade.ts:95):

sktracks[uuid] = new SKTrack();
sktracks[uuid].feature.properties.name = `Vessel trail: ${Date().toString()}`;
sktracks[uuid].feature.geometry.coordinates.push(res.tracks[i]);

The name is invented from the clock at export time, and the id is the vessel's uuid rather than the track's — because there is no track object to take an id or a name from.

The gap is that tracks is not a Signal K resource type. SignalKResourceType is 'routes' | 'waypoints' | 'notes' | 'regions' | 'charts', and @signalk/signalk-schema's groups/resources.json has no tracks group either. Routes are first-class: named, persistent, listable, shareable by any client or plugin. Tracks are live geometry with no identity.

What I think that means for this RFC

The use-case list in the issue body mixes two genuinely different problems, and I'd argue they want different homes:

Transient — a query over time-series data. "Show me where vessels have been, in this area, over this period." No identity, no persistence; the answer is computed per request. This is what the tracks plugin does now, and the part History genuinely cannot do is the spatial half — packages/server-api/src/history.ts has no spatial predicate, and every query is scoped to a single context, so "which vessels were near me" isn't expressible at any resolution. That's a discovery problem, not a filtering problem, and adding a bbox filter to History wouldn't fix it.

Persistent — a resource. A named track someone chose to keep, convert, export, share. That is the same kind of object as a route, and it wants resources/tracks with the same lifecycle: PUT to save, GET to list, DELETE to remove, and GPX in and out for free once it's a resource. Crucially it is also the half that has to be server-side, because it is what makes a track visible to a second device, a second plotter, or another plugin at all.

The conversion between the two — "save this stretch of trail as a track", whether it's my own or an AIS target's — is the single step nothing currently provides, and I think it's the highest-value thing to specify. Once a track is a resource, "create route from track" is a small operation on two resource types, and GPX export is already written.

On simplification: worth noting @JonyIvy's measurement isn't hypothetical. Freeboard already simplifies client-side — skstream.worker.ts:460 runs Douglas-Peucker on every band except the last hour. So resolution is about transfer volume rather than render cost. That doesn't kill the server-side case (@tkurki's zoom-out argument stands, and a database that aggregates natively should be free to), but it makes simplification an optimisation a provider may offer rather than the justification for the API.

On pmtiles: I'd leave it out. It answers "render this efficiently at zoom N", which is a different question from "give me an object I can name, convert and send to a friend."

Two things worth specifying explicitly

Both bit me in implementation, and both were invisible to unit tests because my fixtures encoded the shape I assumed rather than what providers actually return.

Geometry encoding. Querying navigation.position through the History API, signalk-questdb returns {latitude, longitude} objects while a GeoJSON-shaped [lon, lat] array is what a consumer might reasonably expect. Consumers currently have to sniff. Whatever a track API returns, the encoding should be pinned down rather than left per-provider.

bbox axis order. The tracks plugin parses lat,lon,lat,lon; the OpenAPI in tracks#10 documents west,south,east,north. They disagree, and the mismatch returns an empty result with a 200 — an unfriendly failure. GeoJSON order is the more defensible default for a new API and I'm happy to change the plugin to match whatever is decided here. Related: a bbox crossing the antimeridian (west > east) should be specified rather than rediscovered — the plugin handles it now because the boat I test against sits at 177°E.

Where I can help

The plugin has a storage interface with two implementations (in-memory and SQLite, sharing a contract test suite), so I'm happy for it to be the reference implementation of whatever the spatial half looks like, and to do that work.

My suggestion is that resources/tracks is the more valuable half to nail down first, and it's also the cheaper one — it reuses an existing, proven resource lifecycle rather than adding a new provider registry to @signalk/server-api, which is public and released in lockstep with the server.

[dirkwa]

Correction to my comment above, with thanks to @joelkoz who spotted it.

I wrote that "tracks is not a Signal K resource type" and built the argument on it. That is half wrong, and it's the load-bearing half.

What's accurate: tracks is not a standard type — SignalKResourceType is still 'routes' | 'waypoints' | 'notes' | 'regions' | 'charts' and @signalk/signalk-schema's groups/resources.json has no tracks group.

What I got wrong: I concluded there is therefore no persistent server-side track object. There is. GET /signalk/v2/api/resources/tracks returns 200 on my server right now, because the built-in resource-provider carries tracks as a custom resource type:

"custom": [
  { "name": "tracks",     "description": "Freeboard GPX track imports." },
  { "name": "infolayers", "description": "Freeboard map overlays." },
  { "name": "groups",     "description": "Freeboard resource groups." }
]

I never configured that by hand — Freeboard registers it itself (app.facade.ts:119 CUSTOM_RESOURCES, each gated behind a feature key). So the storage half of what I was asking for already ships.

And the data contract already lines up with what the tracks plugin produces. src/app/types/resources/custom.ts:13:

export interface TrackResource {
  feature: MultiLineStringFeature;   // name + description in feature.properties
}

A saved track is a GeoJSON Feature with MultiLineString geometry. The tracks plugin's v1 endpoints already return MultiLineString, and since a recent change they return genuinely multiple segments rather than a single-element array. So the geometry needs no conversion — wrap it in a Feature, add a name, PUT it.

Worth stating plainly since the naming collides: these are two different things.

/signalk/v1/api/tracks	the tracks plugin — live and AIS track history, transient, spatially queryable, no identity
/signalk/v2/api/resources/tracks	resource-provider — saved tracks, persistent, named, full CRUD

Freeboard already uses both, from separate code paths (skstream.worker.ts for the former, resources.service.ts for the latter).

What survives, and what changes. The workflow I described is unchanged, and it needs less building than I claimed. Recording exists — the plugin is accumulating 115 contexts on my boat, every AIS target included. Storage exists. The geometry shapes match. The missing piece is only the join: "take this stretch of trail — mine or that ferry's — and save it as a resources/tracks entry."

So my ask gets smaller and more concrete. Rather than a new resource type, two things worth this thread's opinion:

1. Should tracks be promoted from custom to standard? Today it exists because Freeboard declares it, which is why its description reads "Freeboard GPX track imports." If other plotters and plugins are to build on it, an app-neutral definition seems better than one client's custom type that others must mirror exactly.
2. Where does the save operation belong — the tracks plugin writing to resources/tracks, or a client doing it? I lean towards the server side, so a track saved on the tablet is on the phone too, but I don't think that has to be settled to make progress.

My apologies for the noise; better to correct it here than to let it sit in a spec thread.

[dirkwa]

Following on from my last two comments — and with thanks to @joelkoz, whose correction sent me looking properly. I've now measured rather than assumed, and it has changed my proposal substantially. Two of my earlier claims were wrong and I want to retract them clearly before making the case.

Retractions

1. I said "which vessels were near me" is "not expressible as a History query at any resolution". That is false.

getContexts() exists and enumerates vessels — 3.3 ms against a million rows on my boat. And signalk-questdb has a recordOthers option that records every AIS vessel, not just self; the vessels.self-only result I first saw was my own config, not a limitation. What History actually lacks is only a spatial predicate in the interface. The underlying stores handle it fine.

That claim was the main pillar of my argument for a separate track API, and it doesn't hold.

2. I implied the spatial query needs a purpose-built index. It doesn't.

Measured against QuestDB, ~1M position rows, median of 7 runs:

Query	Plain lat/lon	Native GEOHASH + within()
bbox → which vessels	26.7 ms	18.1 ms
bbox → last position per vessel	65.0 ms	60.6 ms
bbox + 24h time window	4.7 ms	—

Two things stand out. QuestDB does have real spatial support (GEOHASH columns, within()) which I initially missed — but it's only a modest win, and geohash cells are a fixed grid, so an arbitrary bbox still needs a covering-plus-post-filter pass. More importantly, the time window does nearly all the work: 4.7 ms once a time range is applied, because QuestDB partitions by time.

Which points at something I had backwards. Tracks are fundamentally a time query, not a spatial one. A plotter asks "give me tracks from date to date", or "last 30 days", or "last year", or "all". Bounding box is a secondary filter, not the organising principle. I had been designing around the spatial half because that was the part History couldn't express, rather than the part users actually ask for.

The problem, restated

Recording positions is solved — twice. A history provider does it, and the tracks plugin does it. What is not solved is that both are retention-bounded by design and a track you want to keep is not.

• questdb: retentionDays
• tracks plugin's own store: retentionDays
• resources/*: no retention code exists at all — resources are permanent

So "keep this track" is not a convenience feature. It is the only way a track outlives the retention window. That is a genuine architectural reason for a separate store, and it is different from the reason I gave earlier.

Where resources/tracks already is

tracks already exists as a custom resource type in the bundled resource-provider, described as "Freeboard GPX track imports." Freeboard registers it itself (app.facade.ts CUSTOM_RESOURCES), which is why it appears without anyone configuring it. GET /signalk/v2/api/resources/tracks returns 200 today.

The stored shape already matches what a track API would produce — a GeoJSON Feature with MultiLineString geometry, name and description in feature.properties.

But there's a trap in formalising it, which is the crux of this comment.

Query parameters are only validated if (isSignalKResourceType(...)). Verified live just now:

GET /resources/tracks?duration=30d   -> 200   (custom: params pass through)
GET /resources/routes?duration=30d   -> 400   (standard: additionalProperties)

So promoting tracks to a standard type without declaring its query parameters would actively break time-ranged queries that work today. Formalisation and time parameters have to land together.

Proposal

1. tracks becomes a standard Signal K resource type — added to SignalKResourceType and the schema, with an app-neutral definition. Today it exists only because one client declares it, and its description says so.

2. Its schema declares from / to / duration, reusing the History API's existing vocabulary rather than inventing a second one. This is what makes "last 30 days" / "last year" / "all" expressible, and per the trap above it is not optional if tracks becomes standard.

3. The listing is bounded by that window, so the common query is small by construction. Worth discussing: whether an unbounded "all" should return geometry inline or metadata plus a link. A multi-year own-vessel track at 60 s is ~525,000 points / ~14 MB, and the current file-based provider reads and parses every resource file in full to build a listing — I measured 205 ms and 15 MB of I/O just to show twelve track names. A documented default window may be wiser than unbounded.

4. The backing store for tracks should be time-series shaped, not file-per-resource. The file provider is genuinely good for a handful of hand-made routes and waypoints — human-readable, no database, backs up with the config directory — and I am not suggesting replacing it. But it is the wrong shape for half-a-million-point time series, and it has no way to return part of a resource, so a client wanting last week of a year-long track pays for the whole year.

Usefully, this needs no fighting over ownership: the bundled provider registers per type, from its own config (standard and custom lists). Dropping tracks from that list frees the type for a purpose-built provider while the other five types carry on untouched. No migration, nobody's waypoints move.

What I'd contribute

I maintain SignalK/tracks, which now has a storage interface with two implementations behind a shared contract suite, gap-based segmentation (a track that stops overnight shouldn't draw a line across the anchorage), and a SQLite store. I'm happy for it to become the own-vessel track database behind resources/tracks — recording self forever with size and age limits, and serving time-ranged queries — and to do that work.

I'd note the deliberate scope: own vessel forever, not every AIS target forever. One vessel at 60 s is ~14 MB/year, which is nothing. 121 vessels is not. AIS track history is what a history provider with recordOthers is already good at, on a retention window.

The use cases that motivated all this, for reference — see where you've been, keep a stretch worth keeping, turn it into a route, reverse it to get back out the way you came, share it as GPX, and do the same with another vessel's track (record the local ferry through a pass you don't know). Freeboard already has GPX import/export, a Tracks list, and route reversal. Most of the client half exists. What's missing is a track that is a real, persistent, time-queryable object rather than a browser-local trail.

Happy to be told the store belongs somewhere else entirely — the part I'd most like agreement on is points 1 and 2, since they are what everything else depends on.

[joelkoz]

I just dug around a little more myself. The confusing part for me is that there are three things in flight, and I was having a little trouble keepings things straight and determining what the status of things are. This is where I think things stand:

1. The "tracks plugin" (the thing you are now maintaining). This is basically a "v1" tracks API, and it only works if this plugin is installed. This seems to be the data store for track data for both "self" and AIS targets. This has a finite window of data storage

2. The "tracks resource" - this is the resource defined by FSK using the v2 resource provider. Currently, the only thing this does is stores named tracks imported from GPX or GeoJSON files

3. The proposed "tracks API", which is a new thing that currently doesn't exist. Proposed by @tkurki here.

If I understand your latest comment, you want to take the "tracks resource" from 2 above and instead make is a time based query. Does that sound right?

Here are some things to consider:

1. Currently, the resource-provider plugin is used by FSK as the store for imported tracks. If you import a GPX file or a GeoJSON file, they are stored as that resource. When that resource is queried, the returned value has the following shape:

{
  "9f2c1a54-3b7e-4d81-9c2a-5e8f1b0d7a63": {
    "feature": {
      "type": "Feature",
      "geometry": {
        "type": "MultiLineString",
        "coordinates": [[[-81.0501, 24.5553], [-81.0494, 24.5570]]]
      },
      "properties": { "name": "Reef pass", "description": "Local knowledge — followed the ferry" },
      "id": ""
    },
    "timestamp": "2026-06-05T22:33:14.000Z",
    "$source": "resources-provider"
  }
}

The "key" of that object is a generic uuid that represents the track.

The "v1 track" supplied by the plugin has this shape instead:

{
  "vessels.urn:mrn:imo:mmsi:367123450": {
    "type": "MultiLineString",
    "coordinates": [[[-81.0512, 24.5498], [-81.0503, 24.5521]]]
  },
  "vessels.urn:mrn:imo:mmsi:338204567": {
    "type": "MultiLineString",
    "coordinates": [[[-81.0730, 24.5810], [-81.0722, 24.5834]]]
  }
}

Here, the "key" property is vessel identifier.

In the resource provider version, there is a wrapper of data that is required by the resource API. The geometry property of that resource data matches the structure of the json body on each vessel property from the v1 tracks plugin version.

The challenge is going to be either backward compatibility and/or migration.

The big question I have about your current proposal is that there is already a mismatch between the two models, and I think you are actually asking for a third model. Its a valuable model, but a third variation none the less. In the current "resource" model, a track is named collection of coordinates with no time element - there is no data about what time the coordinate was recorded, nor what vessel recorded it. Each track is, however, a discrete named collection. In the current v1 plugin model, we know what vessel recorded it, but again there is no time element (at least, not in the data structure). Nor is there discrete named collection - unless you consider the vessel Id to be the name, in which case it supports only a SINGLE collection vs. multiple.

Put another way, the resource version is simply "this is an arbitrary path", but you can have 1 or more collections of those paths - each with a user supplied name. The v1 tracks gets a little more specific with "this is an arbitrary path taken by a specific vessel", but it drops the "named collection" aspect. Your proposal requires we add a time element to each coordinate, so we can answer a query of "this is the path taken by this vessel during this time period".

So let's assume we fix the data collection and format so either model has both elements the vessel Id and the time each coordinate was recorded. We still have a mismatch in the proposed query model. What happens if I do a "clear track" to start recording a new track. How is the fact that "yesterday was track A, and now I am looking at/recording track B" saved? The old model handles this. A strictly time based model does not. Now - maybe we don't really need this delineation: maybe it is simply a UI issue. A "clear track" is really just saying "ignore coordinates recorded prior to the "last clear date and time." That solves everything except the migration issue: what do we do with the current track sets? When someone imports a GPX file, what date/time is assigned to each coordinate?

As a side note: the resource provider API allows for multiple plugins to register to provide a single resource type. It is not necessary to remove "tracks" from the current resource provider to get a second plugin to ALSO supply resources. Thus, signalk/tracks could register as a tracks resource provider without the need to remove the current tracks resource. If we want to avoid migration issues, we should think about a model where the existing, non vessel Id with no time element can co-exist with the new one. For example, maybe we add a second array named feature.geometry.timestamp that sits beside feature.geometry.coordinates. If that is there, times are available. If it is not, it is the old "tracks"? This may be more trouble than its worth. What to do with the installed base's data is an open question.

[joelkoz]

A thought: if the data store model becomes "vessel id, timestamp, coordinate", a "named collection" could be represented simply by storing { collectionName, vesselId, startTime, endTime } (that is, "My saved track" could mean "all coordinates for vessel 1234 for Aug 12 between 1:00 pm and 2:00 pm"). We could pull that out of the properties property. When a track is queried using a time span, if a the query timespan covers more than one named collection, the provider would simply break it up and return the multiple collections.

This is a little awkward, but it would allow for backward compatibility.

Another thing to consider: the plugin that understands and provides this format does not have to be the same plugin that stores it. If users currently have the QuestDB or the InfluxDB plugins, and/or the v1 tracks plugin, an uber plugin could query those and store its data in those vs. having to be its own store. This again may be a little awkward, but it does keep things backward compatible. If the uber plugin can draw from the various sources, users would get the benefit immediately. Another approach - the signals-tracks plugin could just check to see if there is a history API provider, and if so, it queries that to synthesize some of these data sets vs using its own data store.

[panaaj]

For what it's worth, the format for track "resources" was chosen as it was a minimal implementation aligned to the format of other resource types.

It was always considered / treated as a custom resource type to address a real requirement at the time but that would "eventually" be replaced by a solution, as being discussed here.

IMHO the tracks solution should be considered green field and not unduly influenced by the FSK track resource implementation.

[joelkoz]

IMHO the tracks solution should be considered green field and not unduly influenced by the FSK track resource implementation.

@panaaj - in your opinion - does that mean that the existing tracks can be completely ignored? Or that we should just not look retain any of its shape simply for backward compatibility and instead lean towards migration? You more than anyone are probably in the best position to judge how much traction the existing track system has (pardon the pun). Has it been around long enough to be deeply embedded in anyone's workflow?

One easy solution we could take - just name the new track API resource track vs. tracks. That would allow the legacy tracks resource to stay in place and we simply just deprecate it. The other approach I mentioned is to have the "new" and the "old" track system co-exist on the same resource name and just use duck typing to figure out what kind of object we are looking at.

I suppose the most fundamental question for everyone to vote on is "what exactly is a track?". Is it a single collection of points for a specific vessel where each point has a timestamp so we can extract subsets of it (i.e. more like a vessel position history)? Or is the more important element a unique name and a collection of positions, which makes them more like a high resolution route?

I tend to agree with @dirkwa in that a track is best represented as a position history for a specific vessel. Any other organizing elements exist simply to distinguish one subset from another. What that does is makes the grouping optional. I don't HAVE to name ANY of my tracks. A "smart track" system could automatically organize and present these pseudo collections by day, by area, by "continuous motion without anchoring".

Any else have an opinion way way or another?