The XCTrack task format, decoded.

A competition task is an ordered list of turnpoints — each a WGS84 position with a radius in metres — plus the rules that turn that geometry into a race: where the speed section starts, when its gates open, where it ends, and what shape the goal is.

XCTrack publishes two encodings of exactly that. The .xctsk file (version: 1) is verbose, pretty-printed JSON — the download format every competition tool reads: XCTrack, SeeYou Navigator, Airscore, FS. The task code (version: 2) is the same task squeezed into a single line so it survives being printed as a QR code on a briefing board and scanned off a phone screen.

The vocabulary

Roles are positional as well as declared: whatever its type, the last turnpoint in the array is the goal. There is no GOAL type — the goal's shape lives in a separate goal block.

Three byte strings can arrive at your parser. Dispatch on the first characters, not the file extension:

The two versions are not interchangeable inside their container: a version-1 body in an XCTSK: code, or a version-2 body in a .xctsk file, is malformed. Check the version field after parsing, and reject the mismatch rather than guessing.

{
  "taskType": "CLASSIC",
  "version": 1,
  "earthModel": "WGS84",
  "turnpoints": [
    {
      "type": "TAKEOFF",
      "radius": 400,
      "waypoint": {
        "name": "D01", "description": "Chabre launch",
        "lat": 44.3806, "lon": 5.7331, "altSmoothed": 1220
      }
    },
    {
      "type": "SSS",
      "radius": 4000,
      "waypoint": { "name": "B23", "lat": 44.4012, "lon": 5.7688, "altSmoothed": 980 }
    },
    {
      "radius": 2000,
      "waypoint": { "name": "A15", "lat": 44.5210, "lon": 5.9104, "altSmoothed": 1450 }
    },
    {
      "type": "ESS",
      "radius": 1000,
      "waypoint": { "name": "A07", "lat": 44.4455, "lon": 5.8102, "altSmoothed": 760 }
    },
    {
      "radius": 400,
      "waypoint": {
        "name": "G01", "description": "Goal field",
        "lat": 44.4301, "lon": 5.7955, "altSmoothed": 640
      }
    }
  ],
  "sss": { "type": "RACE", "direction": "EXIT", "timeGates": ["12:30:00Z", "12:45:00Z"] },
  "goal": { "type": "LINE", "deadline": "18:00:00Z" }
}

Read it as a route: launch at D01, start the clock leaving the 4 km B23 cylinder at 12:30, round A15, stop the clock at A07, then cross the goal line at G01. 1 018 bytes as laid out here. §04 is the same task in 350 characters.

Top level

A turnpoint

sss and goal

Version 2 is the same task with every key abbreviated to one letter, every enum turned into a small integer, and each turnpoint's four numbers packed into a single string. The result is short enough to scan.

XCTSK:{"taskType":"CLASSIC","version":2,"t":[{"z":"{v~a@wa{mGgkA_X","n":"D01","d":"Chabre launch","t":1},{"z":"_veb@ob_nGg|@_yF","n":"B23","t":2},{"z":"_kac@govnGsyA_|B","n":"A15"},{"z":"wxmb@kwgnGon@o}@","n":"A07","t":3},{"z":"{|jb@cwdnG_g@_X","n":"G01","d":"Goal field"}],"s":{"g":["12:30:00Z","12:45:00Z"],"d":2,"t":1},"g":{"t":1,"d":"18:00:00Z"}}

Five turnpoints, two start gates and a goal line in 350 characters. Paste it into the decoder in §08 — it is the same task as the file in §03.

Key map

Each v2 turnpoint packs longitude, latitude, altitude and radius — in that order — into z. Each value is scaled to an integer and encoded independently with Google's signed polyline algorithm, and the four results are concatenated with no separator. The decoder recovers exactly four integers or the turnpoint is malformed.

The algorithm, per value

• Take the scaled signed integer.
• Left-shift by one; if the original was negative, invert every bit (~(v << 1)). This moves the sign into bit 0.
• Emit the value five bits at a time, least-significant chunk first.
• Every chunk but the last is OR-ed with 0x20 as a continuation flag.
• Add 63 to each chunk and write it as an ASCII character — landing in the printable range ?–~.

Decoding runs it backwards: accumulate 5-bit chunks until one arrives without the continuation flag, then undo the zig-zag (v & 1 ? ~(v >>> 1) : v >>> 1). Because the chunks are self-delimiting, four values concatenate unambiguously.

Search by field name or meaning, or narrow by category. Each card shows the v1 key and its v2 counterpart.

Base XCTrack turnpoints are always cylinders. SeeYou Navigator added an optional per-turnpoint o object to describe other observation-zone shapes, and XCTrack reads it. It appears in both versions, and is announced by a top-level "o": {"v": 2} marker.

Reading it back

• No o object, or a1: 180 → plain cylinder.
• l: 1 with a12 → a line at that fixed bearing.
• l: 1 without a12 → a line auto-oriented perpendicular to the inbound leg. This is the default in both SeeYou and XCTrack.
• 0 < a1 < 180 → a sector. Tools that model only the FAI quadrant treat any such value as the 90° sector.

Drop in a .xctsk file, an XCTSK: code or an XCTSKZ: code. Everything is decoded in the page — polyline fields unpacked, roles resolved, gates listed. Nothing is uploaded.

• Longitude leads in z. lon, lat, alt, radius. Swapping the first two is silent — the task still parses.
• The goal has no type. The last turnpoint is the goal; its shape comes from the top-level goal block. Do not look for a GOAL value in type.
• No sss means no speed section — an open-distance or free task. Do not synthesise a start from the first turnpoint.
• Absent e is WGS84, not "unknown". Only e: 1 selects the FAI sphere.
• An empty gate array is a valid task, not a malformed one. "timeGates": [] (v1) and "g": [] (v2) both mean "the start time is not set yet". Check the type, not the length.
• Times carry no date, and Z is optional on input. Normalise to HH:MM:SSZ and reject out-of-range components rather than letting 25:00:00 through.
• XCTSKZ: is raw deflate, not gzip. No gzip header, no member framing — inflate it as a zlib stream, and translate URL-safe base64 first.
• A z field must yield exactly four integers. Three or five means a truncated or corrupted scan; fail the turnpoint rather than padding it.
• Cap what you accept. A task code is a scanned string from an unknown source: bound the input size and the inflated size before you parse. We-Fly caps both at 64 KB.

We-Fly imports .xctsk files and pasted codes in the competition-task library and the XC planner, and exports both forms.

Round trips are tested both ways against the other three task formats — see the competition-task formats guide for how .fsdb, .tsk and .cup map onto this same model.