# ApolloScape dataset-api: per-task folders for autonomous driving research

> The ApolloScape dataset-api repository is a research toolkit rather than a library: each task folder carries its own download links, evaluation criteria and demo code, while the shared setup pulls in a pinned 2018 era Python stack.

**ApolloScapeAuto/dataset-api** — The ApolloScape Open Dataset for Autonomous Driving and its Application.

- Repository: https://github.com/ApolloScapeAuto/dataset-api
- Website: https://apolloscapeauto.github.io/dataset-api/
- Stars: 621 · Forks: 142
- Language: Jupyter Notebook
- License: Apache-2.0
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/apolloscapeauto-dataset-api

## A directory of datasets, one per research task

The repository is not a package with a public API despite the name. It is a directory of task folders, and the top level makes that obvious: trajectory_prediction, 3d_detection_tracking, scene_parsing, lane_segmentation, self_localization, car_instance, stereo and inpainting each sit side by side, with examples, utils and a shared requirements file. Each folder holds its own download links, notes on data structure, evaluation criteria and demo code for visualising that dataset, which is the practical value of the layout. A researcher working on trajectory forecasting reads one folder, a researcher working on 3D lidar detection reads another, and neither has to unpick a unified schema that never existed. The broader description calls it a research-oriented dataset and toolkit supporting perception, navigation, control and simulation, and the topics attached to it name 3D lidar, 3D car instance, trajectory prediction and video inpainting. This is a bench for academic work, not a production data pipeline.

## Downloads are plain tarballs and zips on two mirror hosts

There is no downloader script and no credentials to configure. The documentation says full download links are in each folder, and the example commands are plain wget calls against object storage. Two hostnames are used for the same road data, one on a cdn subdomain and one on a bj subdomain:

```bash
wget https://ad-apolloscape.bj.bcebos.com/road01_ins.tar.gz
wget https://ad-apolloscape.cdn.bcebos.com/trajectory/prediction_train.zip
```

The first command pulls an instance-segmentation archive for road01 and the second pulls a trajectory prediction training archive. Expect large files and no resume logic beyond what wget gives you. Because the archives are hosted as public URLs, the security question is not access control but provenance: these are research datasets distributed by a company project, and the licence terms of the data itself are a separate question from the licence of the code. The repository is Apache-2.0, which is permissive for the tooling, but the README does not spell out data redistribution terms in a section you could point to. The README also links each paper's own dataset page, for example apolloscape.auto/inpainting.html and apolloscape.auto/trajectory.html, so the project webpages are a second route to the same hosted data and this repo acts as a convenience index over them.

## requirements.txt pins numpy 1.14.3 and Cython 0.28.3

The shared dependency file is the sharpest constraint in the repository. It pins setuptools 38.2.3, opencv_python 3.4.0.12, Cython 0.28.3, matplotlib 2.2.2, numpy 1.14.3 and Pillow 5.1.0. Those version numbers date the toolkit to roughly 2018, and they matter more than a normal lockfile because numpy 1.14 and Pillow 5.1 predate Python 3.7 and later releases and do not build on modern interpreters or on current macOS and Windows toolchains. The consequence is that installing this environment on a current machine is likely to require a container, an older Python, or a local wheel build. The presence of Cython suggests parts of the toolkit compile extensions, so a pure pip resolution on a fresh machine may also need a compiler present. The demo code inside each task folder is where the actual imports live, and the per-folder requirements, where they exist, take priority over the root file for that particular dataset.

## source.rc is how the utility helpers reach PYTHONPATH

The two line setup in the documentation is short:

```bash
pip install -r requirements.txt
source source.rc
```

The second command is the interesting one. The documentation explains that it includes the necessary packages and the current path in PYTHONPATH so several utility functions can be used. In other words the toolkit exposes helpers through an environment variable rather than an installed entry point, and the script has to be sourced into your shell rather than executed in a subshell. If you run it in a subprocess, or in a CI job that does not source it, the utils directory will not be importable and the demo scripts will fail on imports. The file lives at the top level of the repository, next to the shared requirements file, and it is the single piece of glue between the folders and the demo code. Anything you automate around this toolkit has to reproduce that sourcing step, and it is worth checking the contents of source.rc in your checkout before you assume it only sets PYTHONPATH.

## The README is organised around papers you are expected to cite

The citation section is not an appendix here, it is the reason the repository exists in this form. Four works are listed with authors, venues and links: Depth Guided Video Inpainting for Autonomous Driving at ECCV 2020, TrafficPredict for trajectory prediction of heterogeneous traffic agents at AAAI 2019, The apolloscape open dataset for autonomous driving and its application in IEEE transactions on pattern analysis and machine intelligence, and the CVPR 2019 WAD Challenge on Trajectory Prediction and 3D Perception as an arXiv preprint. Each entry points to a PDF, a project webpage, and in two cases a dedicated dataset page for inpainting and for trajectory and 3D perception. The dataset pages and the demo videos are linked from the same README, which tells you the intended workflow: take a task folder, download its archive, reproduce the evaluation criteria that accompany the corresponding paper, then cite it. The tasks themselves map to those papers, so the taxonomy is a paper taxonomy rather than a product taxonomy.

## Perception tasks only, so it is the wrong tool for a driving stack

Look at the folder names and the boundary is clear. Everything here is a perception or prediction problem: 3D lidar object detection and tracking, 3D car instance understanding, scene parsing, lane or lanemark segmentation, stereo depth estimation, online self localization, trajectory prediction and video inpainting. What is absent is equally telling. There is no planning module, no controller, no simulator harness, no vehicle interface and no ROS node. The parent project is broader, and the README even points at Apollo as a high performance architecture for developing, testing and deploying autonomous vehicles, but this repository holds datasets and evaluation scripts, not a runnable car. If your plan is to build an end to end driving stack, this is the wrong repository and the perception datasets are one component of a much larger assembly. If your plan is to train or benchmark a perception model against published criteria, the per-folder structure is exactly the shortcut you want, and the alternative of assembling your own copies of each dataset and each evaluation script is the work this repo saves you.

## One release in 2022, and a last push in April 2026

The maintenance picture is thin and should shape how you depend on this. The repository is not archived, but the only GitHub release is v1.0, named for the apolloscape website and toolkit, dated 2022-09-28. The last push was on 2026-04-04, so the code has seen more recent commits than the release list suggests, yet nothing has been cut as a tagged version in more than four years, and the README does not describe a versioning or release policy. No CI configuration is shown at the top level, and the.gitmodules file points at submodules, so submodules need initialising before the utils and task code is complete. Code under Apache-2.0 can be vendored, modified and redistributed with attribution and the notice file, which is the friendly part of the picture for anyone building on top of it. The unfriendly part is the dependency pins, which tie you to a 2018 numerical stack unless you patch the requirements file.

## Conclusion

Adopt dataset-api when you need the ApolloScape perception and prediction datasets with the original evaluation criteria and demo code in one place. Do not adopt it as a maintained engineering dependency, since the last push was on 2026-04-04 and the only release is v1.0 from 2022-09-28, and check the pinned numpy 1.14.3 and Cython 0.28.3 against your own environment first.

## FAQ

### How do I download data from the ApolloScape dataset-api repository?

Each task folder contains its own full download links, and the archives are fetched with plain wget calls against the ApolloScape object storage hosts. The README shows road01_ins.tar.gz and the trajectory prediction training archive as examples.

### How do I set up the ApolloScape toolkit environment?

Install the shared dependencies with pip install -r requirements.txt and then run source source.rc so the current path and required packages are added to PYTHONPATH, which makes the shared utility functions importable for the demo code.

### Which Python versions work with the ApolloScape requirements.txt?

The file pins numpy 1.14.3, Pillow 5.1.0, Cython 0.28.3 and opencv_python 3.4.0.12, which are versions from around 2018 and do not build on current interpreters without work. Expect to use an older Python or a container.

### What tasks does the ApolloScape dataset cover?

The folders cover trajectory prediction, 3D lidar object detection and tracking, scene parsing, lane segmentation, self localization, 3D car instance, stereo and video inpainting. Each folder also carries evaluation criteria and demo code for visualising that dataset.

### What licence applies to the ApolloScape dataset-api code?

The repository code is licensed Apache-2.0, which allows modification and redistribution with attribution and preservation of the notice. The README does not set out separate terms for redistributing the downloaded dataset archives.

## Sources

- [ApolloScapeAuto/dataset-api on GitHub](https://github.com/ApolloScapeAuto/dataset-api)
- [License: Apache-2.0](https://github.com/ApolloScapeAuto/dataset-api/blob/master/LICENSE)
- [Project website](https://apolloscapeauto.github.io/dataset-api/)
- [README](https://github.com/ApolloScapeAuto/dataset-api/blob/master/README.md)
- [Releases](https://github.com/ApolloScapeAuto/dataset-api/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/apolloscapeauto-dataset-api