Submission Format

This page describes exactly what your submission zip needs to contain, and how to evaluate against the validation set before you submit.

1. Zip structure

The zip must contain exactly one top-level folder, named however you like (e.g. my_method). If the archive has more than one entry at its root, only one of them (chosen arbitrarily) is evaluated and the rest are silently ignored — so don't zip up multiple method variants together.

Below that folder, mirror the tour/city/snippet.txt layout of the validation split you downloaded:

my_method/
├── D/
│   ├── SomeCity00/
│   │   ├── 00019_2.txt
│   │   └── ...
│   └── ...
├── EE/
├── IT/
├── ND/
└── SF/

D, EE, IT, ND, SF are the five tours in the dataset. Each city and snippet file name must exactly match (case-sensitive) the ground-truth sequence it corresponds to — you get this for free by copying the folder structure of the validation annotations and writing your predictions into files with the same names.

2. Per-sequence file format

One .txt file per snippet, no header row. Each line is one box at one frame, comma-separated, always 11 values:

frame, track_id, bb_left, bb_top, bb_width, bb_height, confidence, class, X_3d, Y_3d, height_m

Field	Meaning
`frame`	Integer frame index, matching the frame indices used in the corresponding ground-truth file.
`track_id`	Integer. The same ID across frames means the same track. Only needs to be unique within one sequence file.
`bb_left, bb_top, bb_width, bb_height`	2D bounding box in pixel coordinates. Boxes with height ≤ 40 px are ignored by the evaluator.
`confidence`	Per-box confidence/score.
`class`	`pedestrian` or `rider` (case-insensitive). Only `pedestrian` is scored, but predicting `rider` too helps the matcher correctly discount near-miss pedestrian detections around riders.
`X_3d, Y_3d`	World coordinates in meters. Not used by the current metrics (HOTA/CLEAR/Identity, 2D mode) — write `nan` if you don't estimate these.
`height_m`	Estimated real-world object height in meters. `nan` is fine if unavailable.

Example file (e.g. my_method/SF/SomeCity00/00019_2.txt) — three tracks over two frames, one of them a rider included to help disambiguation, one with unknown 3D position:

15001, 1692, 436.97, 520.31, 40.94, 82.02, 0.269, rider, 1524.78, -3136.56, 1.37
15001, 1581, 1239.40, 516.90, 26.16, 84.02, 0.826, pedestrian, 1539.23, -3142.68, 1.72
15001, 1584, 1203.25, 528.86, 29.50, 73.01, 0.860, pedestrian, nan, nan, 1.52
15002, 1692, 439.94, 517.20, 41.22, 81.66, 0.391, rider, 1525.32, -3136.07, 1.37
15002, 1581, 1245.52, 508.99, 26.99, 85.85, 0.085, pedestrian, 1539.19, -3142.72, 1.72
15002, 1584, 1208.99, 521.58, 29.53, 74.79, 0.962, pedestrian, nan, nan, 1.52

Package it with, e.g.:

zip -r my_method.zip my_method/

3. Download a ready-made example

example_submission.zip contains the exact folder/file layout every submission needs to have — one .txt per sequence, in the right tour/city/snippet.txt place, for all 502 sequences. Each file has two lines of realistic-looking but entirely made-up detections (not real predictions and not ground truth), so uploading it as-is is a quick way to check that your packaging is correct: it should evaluate without errors and score close to zero. If your own zip is built the same way (same file names, same column layout) but with your actual predictions, it should evaluate too.

4. Submit

Once your local numbers look reasonable, go to the submission page and upload your zip.