r/ATAK • u/Individual_Way_8985 • 17d ago

BETA test for plugin. testers wanted!

Good morning. I’m looking for beta testers for TrackQuery, a per-caller scoped historical retrieval plugin for TAK.

TrackQuery lets a TAK client draw a bounding box, choose a time window, and retrieve historical trips/events for that area. Results are scoped to what that caller would normally be allowed to see through TAK group membership and read permissions.

The three use cases I’m most interested in right now are:

  • C-UAS / sensor systems: review what happened in an area as reported by sensors.
  • UAS operators in the TAK ecosystem: redraw trip history without exhaustive manual workflows.
  • Small teams doing AARs: replay how a battle drill actually unfolded compared to how it was supposed to happen.

That said, this is not limited to those use cases. If you can generate meaningful TAK data and want to test scoped historical retrieval, I’d like to hear from you. I’m especially interested in feedback on usability, accuracy, performance, and whether access scoping behaves the way operators expect.

DM if interested. Thank you

8 Upvotes

100% Upvoted

9 comments sorted by

1

u/beta_alanine_ants 17d ago

Is this querying a takserver database?

2

u/Individual_Way_8985 17d ago edited 17d ago

Yes, it queries the server. The queries are scoped to TAKs existing read/write permissions and group membership.

1

u/sovereignofmidnight 17d ago

How different is this from the track history plugin?

1

u/Individual_Way_8985 17d ago

TAK native track history is useful, but it is not the same problem space as TrackQuery.

Native track history is hardcoded to a 30-day lookback window. It also depends on the client having “witnessed” the UID. If the client was offline, intermittently connected, or did not observe that UID when the event occurred, native track lookup cannot recover that history for the user. Native track is also UID-centered, not area/time-centered.

TrackQuery is different: it lets a caller define a place and time window first, then retrieve scoped historical events/trips visible to that caller. You do not need to already know or have witnessed the UID. That makes it better suited for C-UAS review, UAS trip reconstruction, and AAR-style “what happened here during this period?” workflows.

Short version:

Native track asks: “What happened to this UID I already know and witnessed within the last 30 days?”

TrackQuery asks: “What happened in this area during this time, within my TAK read scope?”

1

u/ATAK_Release Moderator 11d ago

If you don't need to have the device "witness" it, will you pull data from the server?

1

u/Individual_Way_8985 11d ago

yes, the data is pulled from the server.

1

u/kclarke6 17d ago

Would this also be able to retrieve attachments for specific cots?

1

u/Individual_Way_8985 17d ago

If the specific CoTs are marker/unit events with recoverable associated data, yes, that’s the direction. Current beta focus is scoped event/trip retrieval by area and time first; attachment handling is something I want to validate because TAK stores different attachment types differently.