Competition

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 tools.xcontest.org 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,optional
              "lat":                                   number,required
              "lon":                                   number,required
              "altSmoothed":                           number,required
           }
           "extensions": [{..},{..}]               optional extensions; if used, they MUST be in the same order as
                                                   the "extensions" field on the root object. The "id" field is not
                                                   repeated here. Use short key/value to save space in the QR code.
       },
       ...
   ],
   "takeoff":{
       "timeOpen":                                  time,optional
       "timeClose":                                 time,optional
   },
   "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)
       "finishAltitude":                            number, optional, meters AGL - elevated goal altitude
   }
   "extensions" : [                                 optional, list of manufacturer extensions
      {"id":"XCT1", ...},                           each extension is a JSON object with obligatory "id" key
      {"id":"...",...}                              that should idenitify the extension (i.e. manufacturer + version)
   ]                                                The key/values should be kept short as they can be used in QR code as well
}

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)
        "x":         list of extensions, optional
    },
    ...
  ],
  "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)
    "fa":           number, optional, finish altitude
  }
  "e":    number, optional, 0 (wgs84, default), 1(fai sphere)
  "to":   time, optional - Take-off open time
  "tc":   time, optional - Take-off close time
  "x":[{"id":..},..] optional, list of extensions
}

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.

The QR code can be also compressed using zlib format and converted using base64 encoding to ascii. This must be prefixed with a string ‘XCTSKZ:’. It is recommended that the software accepts both XCTSK and XCTSKZ and is able to produce QR code in both formats. In the future we prefer to use the XCTSKZ encoding.

XCTrack
Help us
Development
Interfaces