Ozone: A Unified Platform for Transportation Research

1. Introduction

• Differences in coordinates, timing, labels, and data conventions make heterogeneous transportation observations difficult to align for reliable fusion.Trajectory standards, conflict definitions, and crash records also differ, complicating cross-study safety comparisons and linking reports to continuous motion.Source: §1 · p. 2
• Simulation platforms use distinct map and scenario descriptions, while public trajectory datasets often lack matched maps, prompting repeated reconstruction.Independently rebuilt roads can affect same-site results, and assembling experimental stacks can take months.Source: §1 · p. 2
• Ozone connects sensing, standardized data, models, evaluation, and deployment-oriented prototypes through four core layers and a Prototype extension.Its shared data layer links trajectories, conflicts, reconstructed crashes, and digital-twin maps.Source: §1 · p. 2
• The source inventory spans 19 trajectory datasets at 59 sites in eight countries, with converters complete for 12 sources and seven under adaptation.The schema aligns coordinates, object representations, and motion fields; shared safety measures support conflict extraction, and matched maps support crash reconstruction and simulation.Source: §1 · p. 2
• The platform supports traffic modeling, safety analysis, human-factor experiments, and world-model research, with case studies of emergency takeovers and automated-driving hazards.The paper also assesses conversion accuracy and workflow efficiency.Source: §1 · p. 3

2. Transportation Research Layers

• Four core layers—Hardware, Data, Model, and Evaluation—organize the workflow, while a fifth Prototype layer extends it toward deployment.Hardware supplies observations; Data creates shared records and map assets; Model uses them for analysis; Evaluation assesses outputs; Prototype connects validated methods to applications.Source: §2 · p. 3, Figure 1 · p. 4

2.1. Hardware Layer

• Transportation hardware spans roadside cameras, UAVs, vehicle-mounted LiDAR and radar, GPS/INS, dashboard cameras, and driver-state instruments.Simulation platforms also support repeatable human-in-the-loop studies and autonomous-vehicle testing.Source: §2.1 · p. 3

2.1.1. Problem Statement

• Different sensor coordinate frames, resolutions, and temporal cadences require calibration metadata, including synchronization and georeferencing information.Ozone’s hardware schema records sensor type, mounting geometry, coordinate reference, and sampling configuration with each record.Source: §2.1.1 · pp. 3, 5

2.2. Data Layer

• The data layer covers trajectories, safety-critical events, and contextual attributes; trajectory data support traffic-flow measures and analyses of individual vehicle behavior.Collection modes include fixed roadside cameras, wide-area UAV imagery, and lower-spatial-precision connected-vehicle or GPS probe data, each with characteristic noise and coverage limits.Source: §2.2 · p. 5, §2.2.1 · p. 5

2.2.2. Data Standardization

• A common trajectory standard aligns coordinate, timestamp, object, and metadata conventions so derived safety measures and traffic-model inputs can be computed consistently.Required fields include vehicle identifiers, timestamps, calibrated positions, oriented bounding boxes, heading, speed, and acceleration.Source: §2.2.2 · p. 5

2.2.3. Problem Statement

• Datasets use different coordinate systems, bounding-box representations, and metadata, and many omit heading or oriented bounding boxes needed for safety metrics.Ozone’s canonical schema and conversion pipelines map source datasets to shared fields, using geometric and kinematic inference for missing fields.Source: §2.2.3 · pp. 5–6

2.3. Model Layer

• The model layer spans statistical and physics-informed methods, machine learning, deep learning, and foundation models for prediction, simulation, safety assessment, and decision support.It links standardized transportation data with benchmarked outputs and downstream applications.Source: §2.3 · p. 6

2.3.1. Statistical Models; 2.3.2. Machine Learning and Deep Learning Models

• Traffic modeling ranges from flow-theory and vehicle-interaction models to machine-learning methods for crash-risk prediction, traffic-state estimation, and trajectory tasks.Examples include fundamental diagrams, car-following and lane-changing models, boosted trees, support-vector machines, neural networks, and graph neural networks.Source: §2.3.1 · p. 6, §2.3.2 · p. 6

2.3.3. Foundation Models

• Transportation foundation models include world models that learn environment dynamics from video and traffic models designed to transfer across tasks.The cited examples describe plausible future-scene generation and representations spanning flow prediction, incident detection, and signal control.Source: §2.3.3 · p. 6

2.3.4. Problem Statement

• Inconsistent model interfaces and evaluation protocols hinder model replacement and fair comparisons; Ozone specifies input/output schemas and evaluation hooks for plug-and-play integration.Source: §2.3.4 · p. 6

2.4. Evaluation Layer

• The evaluation layer defines how outcomes are measured and compared, providing standardized evidence on accuracy, safety, robustness, transferability, and practical effectiveness.Source: §2.4 · p. 7

2.4.1. Standard Metrics; 2.4.2. Benchmarks

• Evaluation uses metrics such as TTC, PET, RMSE, IoU, MOTA, ADE, and FDE, with benchmarks tailored to vision, human-factor, prediction, and autonomous-vehicle safety tasks.Source: §2.4.1 · p. 7, §2.4.2 · p. 7

2.4.3. Problem Statement

• Different metrics, dataset splits, and evaluation windows make direct comparisons unreliable; Ozone provides domain-specific suites with fixed splits, scripts, and baseline repositories.Source: §2.4.3 · p. 7

2.5. Prototype Layer

• The Prototype layer links research outputs to hardware and software applications, whose shared interfaces consume the trajectory and event records used in model development.Deployment-oriented evaluation also considers operating constraints and monitoring requirements.Source: §2.5 · p. 7

3. The Ozone Dataset

• The shared data schema connects vehicle trajectories, identified conflicts, reconstructed crashes, and digital-twin maps while preserving source and site relationships.A trajectory is the central record; conflicts link interaction windows to tracks, crashes link reports to inferred motion, and maps supply road geometry.Source: §3 · pp. 7–8

3.1. Geographic Coverage and Data Sources

• 19 trajectory datasets span 59 sites in eight countries; converters are complete for 12 sources, with seven still being adapted.The inventory and converted release have different coverage; mapped sources are not necessarily converted.Source: §3.1 · p. 8, Figure 2 · p. 8, §3 · p. 8

3.2. Trajectory Schema

• Each track records position, oriented bounding-box corners, heading, speed, acceleration, object class, and lane identity, alongside scene-level source and site metadata.Native timestamps and sampling rates are retained rather than standardized.Source: §3.2 · p. 10

3.3. Traffic Conflict Data

• Conflict records link involved tracks over an interaction window and retain conflict type, severity, and temporal markers; shared surrogate-safety-measure definitions standardize extraction.Conflict coverage is narrower than the trajectory inventory: seven sources still being adapted are excluded, and ZEN lacks sufficient geometry for the conflict analysis.Source: §3.3 · p. 11, Figure 3 · p. 12

3.4. Crash Data and Reconstruction

• Reconstruction combines report fields, matched-map road geometry, and vehicle-motion constraints to produce plausible pre-crash and impact trajectories, not uniquely recovered ground truth.Map geometry and motion limits constrain plausible sequences without determining unobserved motion uniquely.Source: §3.4 · p. 14

3.5. Digital-Twin Maps

• CARLA maps reproduce site geometry and roadside features, and distributing them with the data removes a map-building step for co-simulation.The maps also support additional rendered viewpoints and constrain crash reconstruction.Source: §3.5 · pp. 14, 16, Figure 5 · p. 15, Figure 6 · p. 15

3.6. NBDT Scenario Resources

• NBDT pairs site references, standardized tracks, available event annotations, and corresponding CARLA maps so interactions can be analyzed as trajectories, replayed in 3D, or used in closed-loop experiments.Its UAV, vehicle-centered, and risky-event resources provide complementary views under one scene representation for traffic-flow, prediction, planning, and safety tasks.Source: §3.6 · p. 16

3.7. Geographically Attributed Literature Data

• The geographically attributed literature dataset links publication information to venues, topics, affiliations, and identifiable study locations for analyzing research geography and regional topic differences.Affiliation locations indicate where research is produced; study locations identify the environments a paper concerns.Source: §3.7 · p. 16

4.1. Converting Existing Datasets

• Ozone converts existing datasets through coordinate and road-geometry alignment, class mapping, oriented-box and motion-field completion, then manual calibration and quality assurance.Missing headings are estimated from smoothed velocity, while missing speed and acceleration are computed from smoothed positions; implausible tracks are reviewed and corrected or removed.Source: §4.1 · p. 18

4.2. Collecting and Processing New Data

• New observations follow a separate extraction path before entering the shared trajectory schema.Source: §4.2 · p. 18

4.2.1. Sensing Devices and Platforms

• Ozone combines camera, LiDAR, radar, positioning, and physiological sensing with digital twins and simulators for traffic replay and experiments.Roadside and drone cameras provide road views, while in-vehicle cameras also record the driver; SUMO–CARLA co-simulation supports automated-vehicle testing, and driving simulators support human-in-the-loop studies.Source: §4.2.1 · pp. 18–20

4.2.2. From Raw Video to Standardized Tracks

• Video processing uses four sequential stages—image stabilization, trajectory extraction, compensation, and standardization—to produce analysis-ready tracks.Stabilization corrects camera drift; extraction detects and associates vehicles, compensation smooths residual errors, and standardization assigns identifiers and computes motion fields in the common frame.Source: §4.2.2 · p. 20, Figure 9 · p. 21

• Model, evaluation, and prototype interfaces carry dataset fields and outputs through metric suites, benchmark settings, and deployment-oriented applications.Source: §5 · p. 22
• The shared data schema supplies standardized positions and motion fields to traffic models, interaction windows and surrogate measures to safety models, and map and traffic-control context to simulators.Source-specific conversion remains in the data layer, so model and evaluation code can be reused across converted datasets; benchmarks select records according to required fields.Source: §5 · p. 22

5.1. Model Schema

• The model schema standardizes integration for computational methods spanning classical traffic formulations through deep-learning architectures.Each registered model specifies its required input fields, output fields, and evaluation hooks, enabling models to be swapped without changing surrounding data-loading or evaluation code.Source: §5.1 · p. 22, §5.1.5 · p. 25

5.1.1. Traffic Models

• Traffic models include calibrated fundamental diagrams, microsimulation models, crash-risk classifiers, and conflict-detection modules operating on precomputed surrogate safety measures.Source: §5.1.1 · p. 22

5.1.2. AI Models

• Trajectory-prediction baselines include recurrent, graph-neural, and transformer models that use standardized records and return predictions under shared conventions.Source: §5.1.2 · p. 22

5.1.3. World Foundation Models

• World-model interfaces accept context from the data schema and support generation, matched-map rollout, and evaluation of trajectory accuracy, scene realism, and safety consistency.Evaluation includes displacement errors, traffic-distribution comparisons, SSM distributions, and collision rates; generated futures can support counterfactual safety analysis scored with precomputed SSMs.Source: §5.1.3 · pp. 24–25

5.1.4. Neuromorphic Computing

• The neuromorphic model simulates coordinated brain functions to predict reaction times and explain changes through processing pathways and resource competition.Source: §5.1.4 · p. 25

5.1.5. Safety Foundation Models

• The multimodal Safety Foundation Model combines camera imagery, trajectories, and signal information to represent dynamic scenes and characterize interaction risk and conflict severity.Source: §5.1.5 · p. 25

• The evaluation schema defines metric suites, benchmark configurations, and result repositories for comparing outcomes across system layers.Source: §5.2 · p. 26
• Metric suites cover safety, trajectory prediction, and traffic-flow calibration with standardized SSM, ADE/FDE and collision-rate, or RMSE and correlation measures.Source: §5.2 · p. 26
• Versioned benchmark configurations fix data splits, preprocessing, hyperparameter-search protocols, and computational budgets for comparisons.Repositories store published baseline results so researchers can compare methods without rerunning baselines.Source: §5.2 · p. 26

5.3. Prototype Schema

• The Prototype schema bridges research outputs and real-world systems through deployment-oriented applications.Source: §5.3 · p. 26

5.3.1. Hardware Prototypes

• Hardware interfaces support deploying algorithms developed and validated within Ozone onto autonomous vehicles, roadside units, and adaptive signal controllers.Source: §5.3.1 · p. 26

5.3.2. Software Prototypes

• Software prototypes include traffic-management dashboards, real-time safety monitoring, and autonomous-driving modules, with interfaces and monitoring hooks preserving traceability into operation.Source: §5.3.2 · p. 26

5.3.3. Deployment Criteria

• Deployment criteria set minimum performance thresholds, safety requirements, and validation procedures, reusing research-stage evaluation metrics to assess deployment readiness.Source: §5.3.3 · p. 26

6. Case Studies

• The platform provides a plug-and-play workflow that reduces engineering overhead and supports transportation studies from data organization through deployment-oriented validation.Source: §6 · p. 27

6.1. Human-Factor Research

• Ozone’s maps, reconstructed trajectories, and calibrated traffic annotations support realistic, repeatable, and comparable human-factor experiments in simulation.Source: §6.1 · p. 27

6.1.1. Problem Overview

• The AR-HUD scheme uses a GAT-LSTM to compare predicted driver attention with objective risk and highlight overlooked hazards during simulated emergency takeovers.Source: §6.1.1 · p. 27

6.1.2. Experiment Benchmark

• The takeover experiment compared ten drivers with and without an AR-HUD across ten CitySim-derived scenarios, using eye tracking and stability and success metrics.Source: §6.1.2 · p. 27

6.1.3. Results

• 22.02% lower heading-angle standard deviation, 6.47% lower speed standard deviation, and approximately 8% higher takeover success rate with the display than without it.Source: §6.1.3 · p. 28

6.2.1. Problem Overview

• RoadTailBench converts real road hazards into high-fidelity parameterized simulations to assess perception blind spots and decision boundaries under compound hazards.Source: §6.2.1 · p. 28

6.2.2. Experiment Benchmark

• The benchmark combines OpenDRIVE road topologies and OpenSCENARIO dynamic elements, adding adverse lighting, weather, and occlusion to reproduce hazards in CARLA.Source: §6.2.2 · p. 28

6.2.3. Results

• RoadTailBench contains 125 parameterized cases across four operational design domains and 14 road-engineering hazard categories, with compound variants adding environmental and traffic interference.Source: §6.2.3 · pp. 28–29

7.1. System Design Evaluation

• Mean conversion errors were below 0.15 m for position, 2.5 degrees for heading, and 0.3 m/s for speed; experiment setup time fell by 85 percent.Source: §7.1 · p. 29

7.2. Unified Benchmark and Metrics

• A shared surrogate-safety-measure pipeline reuses event definitions, thresholds, and observation windows across datasets, though cross-site counts require exposure and coverage context.Source: §7.2 · p. 29
• Ozone connects standardized scenario specifications and common logging and metrics to robustness assessment of perception, planning, and control stacks.Source: §7.2 · p. 30

7.3. Reproducibility

• Standardized converters and schemas address data reproducibility, model interfaces and baselines address methodological reproducibility, and fixed metrics and splits address evaluative reproducibility.Source: §7.3 · p. 30
• Across five reproduced studies, original pipelines matched published results within 5 percent in two cases, while Ozone pipeline experiments agreed within 3 percent across all five.Source: §7.3 · p. 30

7.4. Cross-City Transferability

• Cross-city conflict classification reached F1 0.83 versus 0.91 within city, and crash-risk prediction reached area under the curve 0.79 versus 0.86 within city.Source: §7.4 · p. 30

7.6. Scope and Limitations

• The schema reduces representational differences but cannot equalize source informativeness; inferred fields and motion assumptions can affect safety measures, and crash reconstructions are plausible rather than unique.Source: §7.6 · p. 31
• The conversion and workflow studies covered four datasets and five researchers, while reproducibility and transfer findings require broader validation before generalization.Source: §7.6 · p. 31

8. Conclusion and Future Work

• Ozone connects trajectories, conflicts, reconstructed crashes, and digital-twin maps through a shared schema across Hardware, Data, Model, Evaluation, and Prototype layers.Source: §8 · p. 31
• The inventory covers 19 trajectory datasets at 59 sites in eight countries, with converters complete for 12 sources and adaptation ongoing for seven.Source: §8 · p. 31
• Four-dataset validation found mean conversion errors below 0.15 m in position, 2.5 degrees in heading, and 0.3 m/s in speed; setup time fell 85%.Source: §8 · p. 31
• Future work targets remaining converters, broader digital-twin coverage, real-time sensor streams, foundation-model adaptation, formal verification, and community-maintained development.Source: §8 · pp. 31–32

• Ozone’s standardized datasets, conversion pipelines, digital-twin maps, model baselines, and evaluation scripts are publicly available.The platform is available at https://ozone.zhilingtech.com/.Source: §9 · p. 32
• Source datasets remain subject to their respective access and reuse conditions.Source: §9 · p. 32