Nagoya Urban Mobility (NUMo) Scenario

City-Scale SUMO Traffic Scenario of Nagoya, Japan

Hourly traffic volume of the scenario. Created by Toyota Motor Corporation by processing the FY2021 Nationwide Road Traffic Census, General Traffic Volume Survey (Ministry of Land, Infrastructure, Transport and Tourism), https://www.mlit.go.jp/road/census/r3/. See LICENSE.md.

NUMo is a road traffic simulation scenario, modeling the realistic vehicle mobility in Nagoya, Japan. The road traffic volume is thoroughly calibrated on 1,618 road segments across the city, while traffic light cycles are also aligned with the historical data. The model can be executed in an open-sourced road traffic simulator SUMO, which can easily be interfaced with various network simulators like OMNeT++ and ns-3. 1.6 million vehicle trips are simulated in a 24-hour period, making it one of the largest SUMO traffic scenarios that are open to the research community.

Attribute	Value
Area of interest	326 sq. km
Total edge length	1,494 km
Total lane length	3,300 km
Duration	24h
Number of junctions	7,833
Number of edges	11,520
Number of traffic lights	1,593
Number of departed vehicles	1,627,151
Number of collisions	0
Number of teleports	561

Publication

Takamasa Higuchi, Lei Zhong, Ryokichi Onishi. "NUMo: Nagoya Urban Mobility Scenario for City-Scale V2X Simulations," in Proceedings of the 2024 IEEE Vehicular Networking Conference (VNC), Kobe, Japan, 2024, pp. 17-24, doi: 10.1109/VNC61989.2024.10575975.

Release notes

• v1.1 — Adds a headless SUMO container and clarifies the licence terms; the scenario data is unchanged from v1.0.
• v1.0 — The initial public release.

Usage

Follow the SUMO official documentation to install the SUMO road traffic simulator. The NUMo scenario has been generated and validated with the SUMO version 1.19.

A simulation can be executed with the following command:

sumo -c nagoya.sumocfg

If you want to enable the SUMO GUI, use the following command instead:

sumo-gui -c nagoya.sumocfg

Running in a container

If you would rather not install SUMO on your host, docker/Dockerfile builds a minimal headless image with the SUMO 1.19 runtime. Build it from the repository root:

docker build -t numo -f docker/Dockerfile .

The scenario files are not baked into the image; mount the repository at /scenario instead, so that a simulation can be executed with the following command:

docker run --rm -v "$PWD:/scenario" numo

SUMO options given after the image name are appended to sumo -c nagoya.sumocfg. This is a city-scale scenario, so make sure Docker has enough memory available and expect a full 24-hour run to take a long time. To smoke-test the setup first, limit the simulated period and write a trip info file:

docker run --rm -v "$PWD:/scenario" numo --end 3600 --tripinfo-output out/tripinfo.xml

Output files are written into the mounted directory as root by default; add --user "$(id -u):$(id -g)" to have them owned by you instead. To run a different configuration file or any other SUMO tool, override the entrypoint, for example:

docker run --rm -v "$PWD:/scenario" --entrypoint netconvert numo --help

The image is headless and does not include an X display, so sumo-gui needs a local SUMO installation.

Recording floating car data

Per-vehicle trajectories are written by SUMO's FCD output, which is enabled with --fcd-output and needs no change to nagoya.sumocfg:

docker run --rm -v "$PWD:/scenario" --user "$(id -u):$(id -g)" numo --fcd-output out/fcd.xml

By default this records the position, speed, angle, lane and lane offset of every vehicle at every simulation step, which for a city-scale scenario produces far more data than is usually wanted: one record is about 150 bytes, so with tens of thousands of vehicles on the network the output grows by several megabytes per simulated second. Sample a subset of the fleet and/or record it less frequently instead:

docker run --rm -v "$PWD:/scenario" --user "$(id -u):$(id -g)" numo \
    --device.fcd.begin 28800 --end 32400 \
    --fcd-output out/fcd.xml --fcd-output.geo \
    --device.fcd.probability 0.05 --device.fcd.period 10

• --device.fcd.probability equips the given fraction of vehicles (0.05 = 5%) with an FCD device; only equipped vehicles are recorded, and without the option every vehicle is equipped. A vehicle is drawn once, when it is inserted, and keeps the device for its whole trip. The draw uses the simulation's random number generator, so it stays the same between identical runs but changes with --seed/--random; --device.fcd.deterministic takes an exact one-in-N sample in insertion order instead, which is unaffected by the seed.
• --device.fcd.period sets the recording interval in seconds.
• --device.fcd.begin is the time at which recording starts; the simulation itself still runs from its configured start. The example above therefore simulates from midnight but only writes the 08:00–09:00 window (28800–32400 s).
• --fcd-output.geo writes WGS84 longitude/latitude instead of the network's local metric coordinates.
• --fcd-output.attributes restricts the emitted attributes, e.g. --fcd-output.attributes x,y,speed, and --fcd-output.acceleration or --fcd-output.signals add further fields. See the FCD output documentation for the full list.
• Use --device.fcd.begin rather than --begin to select a time window. Vehicles are only inserted from --begin onwards, so a later --begin drops every trip that should already have departed: the network starts out empty and the traffic volumes no longer match the calibration until it has filled up. --end is safe — it just stops the run once the window of interest is over — but the run still has to simulate everything before --device.fcd.begin, so a short recording window is not a short run.

The FCD file can be converted to CSV with SUMO's xml2csv.py, which is included in the image:

docker run --rm -v "$PWD:/scenario" --user "$(id -u):$(id -g)" \
    --entrypoint sh numo -c \
    '"$SUMO_HOME"/tools/xml/xml2csv.py out/fcd.xml -o out/fcd.csv'

The single quotes matter: SUMO_HOME is set inside the image, so it has to be expanded by the container's shell rather than by your own.

Each row of the CSV is one <vehicle> record with the enclosing <timestep> attributes prefixed onto it, i.e. timestep_time;vehicle_id;vehicle_x;…. The columns are separated by a semicolon, which is xml2csv.py's default; add -s , for commas.

Licenses

The SUMO network file nagoya.net.xml, the route files under routes/ and the traffic-light programs in nagoya_waut.add.xml are databases derived from the OpenStreetMap and from Japanese open data. Each of those files, taken as a whole, is a database made available under the ODbL 1.0, and different terms apply to their individual contents. The container build files under docker/ are licensed under the MIT License, and all other files under CC BY 4.0.

See LICENSE.md for the authoritative terms, including the attribution notices that redistribution has to carry.

OpenStreetMap attribution

Those three groups of files contain information from OpenStreetMap, which is made available under the ODbL.

© OpenStreetMap contributors