Purpose of this page

The information below is published here to document some communication interfaces of the XCTrack, which are about to be stable as much as possible and hopefully used to interchange data with other programs or flying devices.

Displaying the file

On there is a small web application that lets you see and print the content of the XCTSK file in a human readable form.

Task transfer

To simplify task input into the flight instrument on the task briefing, XCTrack supports sharing the task using several means. You can share the task using:

The MIME type for sending the data should be application/xctsk.

Task definition format

For transfer between devices and for storing the task XCTrack uses the following format. The format is UTF-8 encoded JSON object with the following properties.

   "taskType":"CLASSIC",                            string,required
   "version": 1,                                    number,required
   "earthModel":                                    string, optional - one of "WGS84"(default) / "FAI_SPHERE"
   "turnpoints":[                                   array of objects,required
           "type":                                  string - one of "TAKEOFF" / "SSS" / "ESS"
           "radius":                                number,required
           "waypoint": {
              "name":                                  string,required
              "description":                           string
              "lat":                                   number,required
              "lon":                                   number,required
              "altSmoothed":                           number,required
       "timeOpen":                                  time
       "timeClose":                                 time
   "sss":{                                          optional (since 0.9.1)
       "type":                                      string - one of "RACE" / "ELAPSED-TIME", required
       "direction":                                 string - one of "ENTER" / "EXIT"; obsolete (see bellow)
       "timeGates":[...]                            array of times, required
   "goal":{                                         optional (since 0.9.1)
       "type":                                      string - one of "CYLINDER"/"LINE", optional (default CYLINDER)
       "deadline":                                  time, optional (default 23:00 local UTC equivalent)

Time format

Times are stored in UTC as 9 characters long JSON string of the form HH:MM:SSZ. The Z character at the end has no real meaning and its main purpose is to remind all the implementators and pilots who may read the task (e.g. if stored in the file) that the time is in UTC.

Task definition format 2 - for QR codes

The QR code needs efficient data representation; QR codes containing too much data are hard to scan on the phones in direct sunlight. Therefore we are using the following representation for QR codes only:

  "taskType": "CLASSIC",
  "version": 2,
  "t": [             List of turnpoints
        "z":         string, required - polyline encoded coordinates with altitude and radius
        "n":         string, required - name of the turnpoint
        "d":         string, optional - turnpoint description
        "t":         number, optional, one of 2 (SSS), 3 (ESS)
  "s": {             Start type, optional (since 0.9.1)
    "g": [..]        array of times, required - Time gates, start open time
    "d":             number, OBSOLETE, one of 1 (ENTRY), 2 (EXIT) (ignored when reading task, should be part of exported task for backwards compatibility)
    "t":             number, required, one of 1 (RACE), 2 (ELAPSED-TIME)
  "g": {            Goal type, optional (since 0.9.1)
    "d":            time, optional - Deadline (default 23:00 local time UTC equivalent 
    "t":            number, optional on of 1 (LINE), 2 (CYLINDER) (default 2)
  "e":    number, optional, 0 (wgs84, default), 1(fai sphere)

The turnpoint coordinates are 4 numbers (longitude, latitude, altitude, radius) compressed using Google’s polyline algorithm. See our implementation in this snippet. As google polyline algorithm is lossy, this can result in a difference of 0.8m. Given the FAI tolerance of minimum of 5m, this should be well within the tolerance margin.

XC / Waypoints task

Simple route from waypoints without cylinders. QR format is subset of competition task v2 with further simplifications:

  "T": "W",   taskType: Waypoints
  "V": 2,     version: 2
  "t": [      list of turnpoints
       "z":   string, required - polyline encoded coordinates with altitude
       "n":   string, required - name of the turnpoint

QR Code

The QR code is a JSON in either of the 2 formats preceded by a string XCTSK: . It is recommended to use the format 2 as it requires significantly less space.

Help us