CityPulse: Real-Time Traffic Data Analytics and Congestion Prediction

Idriss Djiofack Teledjieu; Irzum Shafique

REVIEW 3 major objections 4 minor 8 references

CityPulse: Real-Time Traffic Data Analytics and Congestion Prediction

T0 review · 3 major / 4 minor · reviewed 2026-08-15 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read A containerized Kafka-Spark pipeline can classify 11 million traffic records in near real time without physical sensors.

desk verdict A competent Docker/Kafka/Spark engineering demo whose congestion-prediction claims are undercut by circular ML labels; the throughput work is plausible but unrepeatable as reported. read the letter →

arxiv 2506.01971 v1 pith:ZOIFNOQL submitted 2025-05-15 cs.DC

Idriss Djiofack Teledjieu , Irzum Shafique This is my paper · ORCID

classification cs.DC

keywords Real-timetrafficanalyticsApacheKafkaSparkStructuredStreamingDockerizedbigdatapipelineSyntheticCongestionclassificationRandomForestKMeansclustering

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

CityPulse is a proof-of-concept that claims a sensor-free, Dockerized pipeline can deliver real-time traffic congestion analytics on modest hardware. The paper's central assertion is that 11 million synthetic traffic records can be streamed through Kafka, transformed by Spark Structured Streaming, and classified into Low, Medium, and High congestion with macro F1 above 0.95. The authors also report sustained throughput above 300,000 records per minute with only a 10% latency increase under full load. The significance would be that municipalities without dense sensor networks could still build data-driven traffic monitoring systems using open-source components.

What carries the argument

The mechanism that carries the argument is the separation of streaming processing from persistence: Spark writes intermediate results to a temporary local storage layer before the data warehouse commit, which the paper says reduces write I/O pressure and adds fault tolerance. Batch-wise Kafka ingestion (batches of 500 records at the producer level, 500,000 at the stress-test level) keeps consumer lag bounded. Congestion labels are produced by unsupervised KMeans on engineered features — v Vel, v Acc, Space Headway, Time Headway — and these labels then train a 100-estimator Random Forest that gives the reported macro F1.

What would settle it

Deploy CityPulse on a corridor where independent ground-truth congestion labels exist (e.g., loop detectors or GPS probe speeds) and compare its predicted class to observed congestion without retraining; if macro F1 drops far below 0.95, the synthetic-data claim fails to transfer. A second check is whether the three KMeans clusters separate into distinct speed and headway ranges that a traffic engineer would agree are low, medium, and high.

Watch

Extended reading notes

Core claim

On its own terms, the paper claims that synthetic data can stand in for physical sensors: a completely containerized stack (Kafka, ZooKeeper, Spark, Flask, React) ingests 11 million simulated vehicle records, labels them by KMeans clustering into three congestion classes, and trains a Random Forest that maintains macro F1-scores above 0.95 across sequential batches. The temporary storage layer between Spark and the warehouse is credited with keeping write efficiency and fault tolerance high enough to reach roughly 320,000 records per minute while memory stays at 8.2 GB of 12 GB. The conclusion is that meaningful real-time traffic insights are achievable without physical sensor infrastructure or cloud providers.

Load-bearing premise

Everything depends on the assumption that the 11 million synthetic records behave like real city traffic and that the KMeans-generated cluster labels really mean low, medium, and high congestion.

Editorial extensions

If this is right

A city without loop detectors or cameras could deploy CityPulse with simulated or proxy data streams and still receive near-real-time congestion classifications.
Operators should prefer chunked ingestion: pushing all records at once adds about 10% processing time, while 500,000-record batches keep throughput consistent.
A four-feature Random Forest model (velocity, acceleration, time headway, space headway) is enough to keep classification accuracy stable across data batches, so heavy deep-learning infrastructure is not needed for this classification step.
The same Docker-based deployment can be reproduced elsewhere because every component is open-source and only the data source and configuration would change.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

The reported F1 scores validate that the classifier reproduces the KMeans labels; they do not by themselves validate that those labels match real-world congestion, so an independent ground-truth check is needed before deployment.
The 320,000-record-per-minute figure was measured on clean synthetic records; real GPS or mobile streams contain noise, gaps, and duplicate readings, so operational throughput should be expected to be lower.
A natural extension is domain adaptation: train on the synthetic distribution, then fine-tune on a small labeled real-world sample, which would reveal how much of the learned congestion signal transfers to actual roads.
Publishing the synthetic data generator would let other teams test whether the KMeans cluster boundaries correspond to traffic-engineering speed thresholds; that test would settle whether the claimed sensor replacement is credible.

Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

The paper is a straightforward engineering demo: a Dockerized Kafka-to-Spark streaming pipeline that ingests synthetic traffic records, does some cleaning and feature engineering, runs KMeans to assign congestion labels, trains a Random Forest on those labels, and serves results via Flask/React. That is legitimately useful as a reference architecture for a low-cost municipal deployment, and the authors are transparent about the trickiest operational choices, like chunked ingestion and a temporary storage layer. If the throughput numbers are real, the system does what it claims: about 320K records/min on a 12 GB machine with stable CPU/RAM. The writing is clear and the pipeline description is reproducible in principle, though no code or data is provided to confirm it. The soft spots are real and central. The ML evaluation is circular: the Random Forest's labels are KMeans cluster IDs computed on the very same four features the classifier is trained on. High agreement is expected and tells you nothing about whether the clusters correspond to actual congestion. The report frames this as 'congestion prediction' and even claims the system can replace physical sensors, which is an overclaim. The synthetic data source [MAH22] is cited but not described, so we don't know whether the simulated distributions resemble real urban traffic or whether they contain artificial cluster structure that inflates separability. The performance metrics are single-point numbers with no test methodology, no repeat runs, and no confidence intervals, which makes the 10% latency increase hard to assess. And the paper never engages with any external ground truth, so the 'meaningful insights' conclusion has no support. That said, I don't think this is a dishonest paper. It's an honest engineering report that conflates cluster reproduction with prediction. The fix is straightforward: reframe the ML section as an assessment of how well a supervised model can learn the KMeans partition, or better, validate on real sensor labels or human-annotated congestion states. Also release the code and data, or at least describe the synthetic data generation in detail. Who's this for? Researchers or practitioners building similar low-cost traffic analytics pipelines in resource-constrained settings, and anyone teaching a course on streaming systems looking for a worked example. It deserves a serious referee not because the current claims hold, but because the architecture is plausible and the evaluation flaws are fixable in revision. I'd send it to peer review with strong guidance to the authors that the ML claims need to be reworked or removed, not merely patched.

Referee Report

3 major / 4 minor

Summary. The paper describes CityPulse, a proof-of-concept, Dockerized pipeline for real-time traffic data analytics. The system ingests 11 million synthetic traffic records through Kafka, processes them with Spark Structured Streaming, applies KMeans clustering to assign congestion labels (Low, Medium, High), trains a Random Forest classifier on four engineered features (v_Vel, v_Acc, Space Headway, Time Headway), and serves results through a Flask backend and React frontend. The paper reports a peak throughput near 320,000 records per minute, an average end-to-end latency of 3.2 seconds per 100,000-record batch, and macro F1-scores above 0.95 for the congestion classifier. The central claim is that CityPulse demonstrates that meaningful real-time traffic insights and congestion monitoring can be achieved without physical sensor infrastructure, particularly in resource-constrained regions such as Cameroon.

Significance. If the reported results held, CityPulse would provide a useful open-source reference architecture for containerized stream processing and a low-cost template for traffic analytics in settings with limited sensing infrastructure. The paper's integration of Kafka, Spark, Docker, and visualization, along with its explicit attention to chunked ingestion and bottleneck mitigation, are constructive engineering contributions. However, the significance is heavily conditional: the machine learning evaluation is internally circular, and the performance claims are not backed by a reproducible measurement methodology. The systems integration work may be of interest to practitioners, but the headline claim about sensor-free, meaningful congestion prediction is not supported by the evidence presented.

major comments (3)

[Sections 3.3 and 6.2] The congestion classification evaluation is circular. Section 3.3 states that the labels are 'Congestion level (generated via KMeans)', and Section 6 states that 'Congestion labels (High, Medium, Low) were initially generated through unsupervised KMeans clustering' and then used as training targets for the Random Forest. Because the same four features (v_Vel, v_Acc, Space Headway, Time Headway) are used both to form the KMeans clusters and to train the classifier, the reported macro F1-scores above 0.95 measure how well the Random Forest reproduces the KMeans partition of that feature space. They do not measure the model's ability to predict actual road congestion, since no external ground truth, sensor data, or independently annotated labels appear anywhere in the evaluation. Consequently, the claims in Section 6.5 and Section 7 that the system can provide 'meaningful real-time traffic insights' and replace physical sensors are unsupported by the presented evidence.
[Sections 5.1 and 3.4] The performance results are reported as single point values without the methodology needed to assess them. The paper gives 'Peak Throughput: ∼320,000 records/min', 'Average End-to-End Latency: 3.2 seconds per batch (100,000 records)', and 'a 10% increase in processing time' without stating the hardware configuration, operating system, software versions, number of repeated runs, or variance across runs. These omissions make it impossible to determine whether the reported throughput and latency are stable, reproducible, or specific to one favorable run. This weakens the 'cost-effective and reproducible analytics solution' contribution claimed in the abstract and Section 7.
[Sections 3.2, 5, and references [MAH22]] The synthetic data used in all experiments is described only as '11 million synthetic traffic records [MAH22]' that emulate 'vehicle congestion, GPS coordinates, and weather conditions'. The paper does not describe the data generation procedure, the distributions of the simulated variables, or the mechanism by which the synthetic records are supposed to correspond to real urban traffic phenomena. Since the entire downstream analysis and the conclusion about sensor-free insights depend on this synthetic dataset, the external validity of the results cannot be evaluated. At minimum, the authors should characterize the synthetic data and validate that its cluster structure corresponds to meaningful congestion levels rather than artifacts of the generator.

minor comments (4)

[Section 3.3] The text 'n estimators= 100' should read 'n_estimators = 100' to match the Python scikit-learn parameter name.
[Sections 3.4, 5.3, and abstract] The paper interchangeably says '10% increase in latency' and '10% increase in processing time'; these are different measurements and should be defined consistently.
[Section 6.3] The stability evaluation over '20 sequential data batches' does not state whether these batches were held out from the training data, how the train/test split was made, or whether any batch overlapping occurred; this information is needed to interpret the reported stability.
[Section 5.3] The comparison between full ingestion and chunked ingestion reports only relative behavior ('10% increase in processing time') without absolute values, making the practical benefit of chunked ingestion difficult to quantify.

Circularity Check

2 steps flagged · score 8.0 of 10

The >0.95 macro F1 is circular: KMeans cluster IDs on the same four features are used as 'congestion' labels for the Random Forest, so the evaluation measures cluster reproduction rather than real-world congestion prediction.

self definitional [Section 3.3 (Modeling and Prediction) and Section 6 (Machine Learning Evaluation)]
"Congestion labels (High, Medium, Low) were initially generated through unsupervised KMeans clustering, and used as training targets in the supervised model."

The training targets are not independent ground truth: KMeans assigns cluster IDs from the same four engineered features (v Vel, v Acc, Space Headway, Time Headway) that are then used as Random Forest inputs. The reported macro F1 above 0.95 therefore quantifies how well the Random Forest reproduces the KMeans partition of the feature space, not how well it predicts actual traffic congestion. No external sensor data, human-annotated labels, or independently measured congestion levels enter the evaluation, so the 'congestion prediction' claim reduces by construction to cluster imitation.
fitted input called prediction [Section 6.5 (Summary) and Section 7 (Conclusion)]
"These results demonstrate the feasibility of using simulated data for training predictive traffic models in the absence of physical sensors."

This is the load-bearing conclusion behind the abstract's claim that 'even without physical sensors... meaningful real-time traffic insights can be generated.' It rests entirely on the Section 6.2 agreement between the Random Forest and the KMeans-generated labels. Since those labels were manufactured from the same features being classified, the experiment cannot show real-world congestion prediction; it only shows that a supervised model can approximate the unsupervised clustering that defined its targets. The system's throughput and latency results are empirical, but the sensor-free 'meaningful insights' conclusion is supported only by this circular evaluation.

full rationale

The paper's engineering results are not circular: Sections 3.4 and 5 report concrete throughput, latency, CPU, and memory measurements obtained by running the Dockerized Kafka/Spark pipeline, and those numbers stand independently of the machine learning evaluation. The circularity is concentrated in the congestion-prediction module. Section 3.3 states that the Random Forest uses features v Vel, v Acc, Space Headway, and Time Headway, while the labels are simply 'generated via KMeans.' Section 6 confirms that the congestion labels were produced by unsupervised KMeans clustering and then used as supervised training targets. The reported macro F1-score above 0.95 is therefore a measure of how well the Random Forest replicates the KMeans cluster assignments on the same feature space. Because there is no external ground truth, no sensor validation, and no independent label set, the central claim that CityPulse can generate meaningful congestion insights without physical sensors is not demonstrated by the ML evaluation. The throughput results support only the 'scalable pipeline' part of the contribution, not the 'congestion prediction' part. Score 8 reflects that the key predictive claim reduces by construction to a fitted clustering renamed as prediction; a lower score would understate how much of the headline conclusion depends on this self-referential evaluation.

Assumptions & free parameters 4 free parameters · 3 assumptions · 0 invented entities

The central results rely on a small number of modeling choices: the number of congestion classes, the random forest size, and the ingestion batch sizes. No new physical entities or forces are introduced. The main epistemic debt is the assumption that synthetic data and KMeans-derived labels approximate real traffic, an assumption the paper never tests.

free parameters (4)

Number of KMeans clusters (congestion classes) = 3
Chosen by hand; every congestion label and all downstream F1 scores depend on this choice. No cluster validity measure is reported.
Random Forest n_estimators = 100
Standard default hyperparameter, not tuned; minimal effect on the circularity issue.
Kafka producer batch size = 500
Batch size for ingestion; the reported throughput and latency depend on this configuration choice.
Chunked ingestion batch size = 500,000
The chunked strategy that produced the reported stable performance; the full-push comparison shows a 10% degradation, so this parameter materially shapes the headline performance claim.

assumptions (3)

domain assumption The 11 million synthetic records, cited to [MAH22], represent real-world urban traffic phenomena including congestion, GPS coordinates, and weather.
Introduced in the abstract and Section 5; never validated against real traffic data, yet every downstream conclusion about deployability depends on it.
ad hoc to paper The three KMeans cluster assignments correspond to meaningful congestion levels (Low, Medium, High).
Section 3.3 states labels are generated via KMeans; this is a modeling choice made for this paper, and the supervised evaluation inherits it as ground truth.
domain assumption Standard stream-processing components (Kafka, Spark, Docker) operate as documented and their defaults are acceptable for the benchmark.
The paper provides no independent verification of component behavior; performance claims assume the software stack works as expected.

how reviews work

0 comments

Cite this review

Pith. "Pith review of CityPulse: Real-Time Traffic Data Analytics and Congestion Prediction." pith.science (2026). https://pith.science/paper/ZOIFNOQL

@misc{pith2026250601971,
  author       = {Pith},
  title        = {Pith review of: CityPulse: Real-Time Traffic Data Analytics and Congestion Prediction},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/ZOIFNOQL}},
  note         = {Machine review of arXiv:2506.01971}
}

read the original abstract

CityPulse is a proof-of-concept big data pipeline designed to enable real-time urban mobility analytics using scalable, containerized components -- without reliance on physical sensor infrastructure. The system simulates the ingestion of 11 million traffic-related records representing urban phenomena such as vehicle congestion, GPS coordinates, and weather conditions. Data is ingested through a Dockerized Apache Kafka cluster, coordinated by ZooKeeper, and processed in real time using Apache Spark Structured Streaming. To ensure robustness under load, the architecture introduces a temporary data storage layer that buffers Spark output before committing it to a centralized data warehouse. This design improves write efficiency, fault tolerance, and enables batch processing of intermediate results. The refined data feeds into a lightweight machine learning module and is served through a Flask backend with a React-based frontend for visualization and interaction. Stress testing shows that the system maintains over 300,000 records per minute throughput with only a 10\% increase in latency under full load conditions. With its modular Docker-based deployment, CityPulse offers a cost-effective and reproducible analytics solution for traffic congestion monitoring in resource-constrained environments, particularly in developing regions like Cameroon.

Figures

Figures reproduced from arXiv: 2506.01971 by the authors.

**Figure 1.** CityPulse: System Architecture emulating urban traffic signals, such as vehicle telemetry, GPS coordinates, and weather patterns. This synthetic approach enables fast, low-cost experimentation and iteration. CityPulse employs Apache Kafka (for ingestion), ZooKeeper (for coordination), and Apache Spark (for streaming and transformation), all orchestrated via Docker. The system uses a temporary storage layer to decoup… view at source ↗

**Figure 2.** Left: Average velocity across lanes. Right: Distribution of congestion levels. [PITH_FULL_IMAGE:figures/full_fig_p005_2.png] view at source ↗

**Figure 3.** Left: Vehicle count per lane. Right: Average space headway by lane. [PITH_FULL_IMAGE:figures/full_fig_p005_3.png] view at source ↗

Figures from the paper (4 more)

**Figure 4.** Figure 4: Average Feature Importances from Random Forest Classifier [PITH_FULL_IMAGE:figures/full_fig_p007_4.png]

**Figure 5.** Figure 5: Classification Report Per Cluster (Precision, Recall, F1-Score) [PITH_FULL_IMAGE:figures/full_fig_p008_5.png]

**Figure 6.** Figure 6: Model Accuracy and F1-Score Over Sequential Batches [PITH_FULL_IMAGE:figures/full_fig_p008_6.png]

**Figure 7.** Figure 7: Combined Confusion Matrix Across All Batches [PITH_FULL_IMAGE:figures/full_fig_p009_7.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

8 extracted references · 5 canonical work pages

[1]

Real-time detection of traffic from twitter stream analysis

Eleonora D'Andrea, Pietro Ducange, Beatrice Lazzerini, and Francesco Marcelloni. Real-time detection of traffic from twitter stream analysis. IEEE Transactions on Intelligent Transportation Systems , 16(4):2269--2283, 2015. https://doi.org/10.1109/TITS.2015.2409031 doi:10.1109/TITS.2015.2409031

work page arXiv 2015
[2]

Real-time traffic speed estimation using mobile phone location data and deep learning

Yifan Huang, Shuai Li, and Xiaoming Liu. Real-time traffic speed estimation using mobile phone location data and deep learning. IEEE Access , 7:132037--132046, 2019. https://doi.org/10.1109/ACCESS.2019.2940806 doi:10.1109/ACCESS.2019.2940806

arXiv 2019
[3]

Real-time traffic monitoring system using IoT -aided robotics and deep learning techniques

Mohammed Qader Kheder and Aree Ali Mohammed. Real-time traffic monitoring system using IoT -aided robotics and deep learning techniques. Kuwait Journal of Science , 51(1):100153, 2024

work page 2024
[4]

Deep learning model for real-time traffic flow prediction using big data analytics

Abdelrahman Mousa, Safa Ali, and Haider Hussein. Deep learning model for real-time traffic flow prediction using big data analytics. Journal of Big Data , 9(1):1--15, 2022. https://doi.org/10.1186/s40537-022-00576-1 doi:10.1186/s40537-022-00576-1

work page doi:10.1186/s40537-022-00576-1 2022
[5]

Big data applications in real-time traffic operation and safety monitoring and improvement on urban expressways

Qi Shi and Mohamed Abdel-Aty. Big data applications in real-time traffic operation and safety monitoring and improvement on urban expressways. Transportation Research Part C: Emerging Technologies , 58:380--394, 2015. https://doi.org/10.1016/j.trc.2015.02.022 doi:10.1016/j.trc.2015.02.022

work page doi:10.1016/j.trc.2015.02.022 2015
[6]

Parallel computing for large-scale traffic simulation: A review

Liang Sun, Lin Yao, Cheng Xu, and Jiawei Wang. Parallel computing for large-scale traffic simulation: A review. Simulation Modelling Practice and Theory , 85:34--49, 2018. https://doi.org/10.1016/j.simpat.2018.04.006 doi:10.1016/j.simpat.2018.04.006

work page doi:10.1016/j.simpat.2018.04.006 2018
[7]

Traffic performance GPT ( TP - GPT ): Real-time data informed intelligent chatbot for transportation surveillance and management

Bingzhang Wang, Zhiyu Cai, Muhammad Monjurul Karim, Chenxi Liu, and Yinhai Wang. Traffic performance GPT ( TP - GPT ): Real-time data informed intelligent chatbot for transportation surveillance and management. arXiv preprint arXiv:2405.03076 , 2024

arXiv 2024
[8]

Urban traffic congestion prediction using graph attention networks with spatial-temporal features

Jun Zhang, Yu Zheng, and Yuan Qi. Urban traffic congestion prediction using graph attention networks with spatial-temporal features. IEEE Transactions on Intelligent Transportation Systems , 21(11):4821--4830, 2020. https://doi.org/10.1109/TITS.2019.2951896 doi:10.1109/TITS.2019.2951896

arXiv 2020

Pith tools

Reviewed August 15, 2026 · model on record in the stance chip above.

[1] [1]

Real-time detection of traffic from twitter stream analysis

Eleonora D'Andrea, Pietro Ducange, Beatrice Lazzerini, and Francesco Marcelloni. Real-time detection of traffic from twitter stream analysis. IEEE Transactions on Intelligent Transportation Systems , 16(4):2269--2283, 2015. https://doi.org/10.1109/TITS.2015.2409031 doi:10.1109/TITS.2015.2409031

work page arXiv 2015

[2] [2]

Real-time traffic speed estimation using mobile phone location data and deep learning

Yifan Huang, Shuai Li, and Xiaoming Liu. Real-time traffic speed estimation using mobile phone location data and deep learning. IEEE Access , 7:132037--132046, 2019. https://doi.org/10.1109/ACCESS.2019.2940806 doi:10.1109/ACCESS.2019.2940806

arXiv 2019

[3] [3]

Real-time traffic monitoring system using IoT -aided robotics and deep learning techniques

Mohammed Qader Kheder and Aree Ali Mohammed. Real-time traffic monitoring system using IoT -aided robotics and deep learning techniques. Kuwait Journal of Science , 51(1):100153, 2024

work page 2024

[4] [4]

Deep learning model for real-time traffic flow prediction using big data analytics

Abdelrahman Mousa, Safa Ali, and Haider Hussein. Deep learning model for real-time traffic flow prediction using big data analytics. Journal of Big Data , 9(1):1--15, 2022. https://doi.org/10.1186/s40537-022-00576-1 doi:10.1186/s40537-022-00576-1

work page doi:10.1186/s40537-022-00576-1 2022

[5] [5]

Big data applications in real-time traffic operation and safety monitoring and improvement on urban expressways

Qi Shi and Mohamed Abdel-Aty. Big data applications in real-time traffic operation and safety monitoring and improvement on urban expressways. Transportation Research Part C: Emerging Technologies , 58:380--394, 2015. https://doi.org/10.1016/j.trc.2015.02.022 doi:10.1016/j.trc.2015.02.022

work page doi:10.1016/j.trc.2015.02.022 2015

[6] [6]

Parallel computing for large-scale traffic simulation: A review

Liang Sun, Lin Yao, Cheng Xu, and Jiawei Wang. Parallel computing for large-scale traffic simulation: A review. Simulation Modelling Practice and Theory , 85:34--49, 2018. https://doi.org/10.1016/j.simpat.2018.04.006 doi:10.1016/j.simpat.2018.04.006

work page doi:10.1016/j.simpat.2018.04.006 2018

[7] [7]

Traffic performance GPT ( TP - GPT ): Real-time data informed intelligent chatbot for transportation surveillance and management

Bingzhang Wang, Zhiyu Cai, Muhammad Monjurul Karim, Chenxi Liu, and Yinhai Wang. Traffic performance GPT ( TP - GPT ): Real-time data informed intelligent chatbot for transportation surveillance and management. arXiv preprint arXiv:2405.03076 , 2024

arXiv 2024

[8] [8]

Urban traffic congestion prediction using graph attention networks with spatial-temporal features

Jun Zhang, Yu Zheng, and Yuan Qi. Urban traffic congestion prediction using graph attention networks with spatial-temporal features. IEEE Transactions on Intelligent Transportation Systems , 21(11):4821--4830, 2020. https://doi.org/10.1109/TITS.2019.2951896 doi:10.1109/TITS.2019.2951896

arXiv 2020