the Creative Commons Attribution 4.0 License.
the Creative Commons Attribution 4.0 License.
Transport modelling for dynamic urban climate studies: MATSDA-roads v2.0
Abstract. Representing dynamic patterns of people’s movement is crucial for modelling high-resolution urban systems with feedback to emissions (e.g., anthropogenic heat, pollutants) and exposure of individuals to environmental stressors. We have developed the transport model MATSDA (Movement And Transport Simulations using Dijkstra’s Algorithm) consists of MATSDA-roads and MATSDA-metro that iteratively computes optimised routes through a simplified nodal representation of urban transport networks. The approach can be used for different transport modes with routes being represented as a sequence of journeys between linked nodes. MATSDA-roads v2.0’s input network has a hierarchy of road types (motorway to local roads, UK) connected by junctions and intersections. MATSDA-roads v2.0 is assessed in London (UK) with data collected in real-time from the Google Maps Directions API over several weeks to capture day of week, time of day, route direction (outbound v. inbound) and route alternatives (total of >87,000 reference routes). A high level of road network detail, notably carriageway types (e.g., dual carriageways, slip roads), is critical to obtain travel times accurately to within 5–10 minutes during daytime, particularly for longer journeys. Model parameter choices are shown to impact model performance, with effective length of local roads and junction delay penalties increasing the modelled travel time. MATSDA-roads v2.0 captures the diurnal variability of urban traffic through its input data, including morning and evening rush hours but travel times are systematically underestimated late at night (between 22 h and 4 h). The model exhibits high skill at identifying major travel corridors (Fractions Skill Score ~0.7 at 500 m grid resolution), indicating its route choices are spatially realistic. This work provides a valuable tool for transport research, urban climate modelling and environmental exposure assessment that require dynamic human movement patterns.
- Preprint
(3294 KB) - Metadata XML
-
Supplement
(2129 KB) - BibTeX
- EndNote
Status: final response (author comments only)
-
RC1: 'Comment on egusphere-2025-6060', Anonymous Referee #1, 29 Mar 2026
-
AC1: 'Reply on RC1', Tiancheng Ma, 13 Apr 2026
We would like to thank Reviewer 1 for reviewing our manuscript and the positive comments. We appreciate you pointing out the potential for future work.
Please find our attached pdf file for point-by-point responses to each comment.
-
RC2: 'Reply on AC1', Anonymous Referee #1, 14 Apr 2026
The authors have appropriately addressed my comments, and there are no further remarks.
Citation: https://doi.org/10.5194/egusphere-2025-6060-RC2
-
RC2: 'Reply on AC1', Anonymous Referee #1, 14 Apr 2026
-
AC1: 'Reply on RC1', Tiancheng Ma, 13 Apr 2026
-
RC3: 'Comment on egusphere-2025-6060', Anonymous Referee #2, 23 Sep 2026
OverviewThis manuscript introduces MATSDA-roads v2.0, a Dijkstra's-algorithm-based transport model that computes optimised road-travel routes through a simplified, hierarchical nodal representation of a city's road network. The model is demonstrated for car driving in Greater London, evaluated against a large set of reference routes retrieved from the Google Maps (GM) Directions API on a gridded network representation. Local roads within each grid cell are aggregated into a single node, with F_L and JTP selected through sensitivity analysis (Sect. 4.1). Origin–destination sampling is designed around realistic commuter journeys (residence–workplace pairs stratified by car-commuting share and straight-line distance, Sect. 3.2.1). Route-realism factors not captured by the model, such as charging and low-emission zones, and other limitations are discussed in Sect. 5.1.The model description and evaluation are clearly presented, and the underlying dataset is substantial. Before publication, though, the manuscript should clarify more explicitly what MATSDA specifically contributes relative to existing routing approaches, over what scope its London-calibrated parameters are intended to apply, and what the comparison against Google Maps can and cannot show about the model's performance. These points, together with a few smaller clarifications, are discussed below; none require new analyses or climate-model coupling.Key CommentsComment 1: Positioning and contribution relative to existing routing approachesMATSDA-roads uses a standard shortest-path algorithm over an aggregated, hierarchical representation of the road network. The manuscript should explain how MATSDA differs in purpose from routing engines such as OSRM and GraphHopper and traffic simulators such as SUMO. The manuscript motivates MATSDA mainly by contrasting it with commercial "black-box" routers on grounds of transparency and query cost (Sect. 1), but does not discuss how it relates to these open-source alternatives.It would help readers to know what MATSDA is intended to provide for urban-climate applications that these related tools do not already offer — for example, a particular network-aggregation and calibration workflow, specific climate-relevant outputs, or another property tied to the intended use case. This is a request to clarify the intended distinction and scope of contribution, not to demonstrate equivalence or superiority through a benchmark against these tools.Comment 2: Transferability of the London-calibrated parametersF_L and the associated calibration (JTP, F_L = 0.16) are derived from London data (Sect. 4.1). The authors note that "differences between cities are likely making case-by-case assessments necessary" (Sect. 5.1, item 1), but the manuscript does not elaborate on what this means in practice. Please clarify which city characteristics (e.g., block size, local-road density, network topology) would be expected to most affect F_L, and what adaptation — re-calibration, a repeated sensitivity analysis, or something else — would be needed before applying MATSDA to a different city. This would help define the intended scope of applicability without requiring validation in another city within this manuscript.Separately, the distance-varying F_L parameterisation (Eq. 3) did not outperform the constant F_L = 0.16 (Sect. 4.1.1); the explanation for this is spread across two sentences and could be tightened into a single concluding statement.Comment 3: Google Maps as an evaluation referenceGM is used as the primary evaluation reference throughout Sect. 4, while Sect. 1 notes that commercial routers are opaque about their underlying routing logic. GM is a useful, widely available comparison point, but — by the manuscript's own framing — it is not a fully transparent ground truth. Please clarify what the comparison against GM can and cannot show about MATSDA's performance, and consider noting the absence of independent validation against other data sources (e.g., TfL loop-detector counts, TomTom/Waze data) as a scope limitation of the current evaluation rather than only as future work.Comment 4: Overnight bias (22:00–04:00)MATSDA systematically underestimates travel times overnight across all configurations (Fig. 11a, d, g; MBE < 0), reaching up to ~25 min faster than GM for longer routes. Sect. 4.2 already attributes part of this to the flatter diurnal speed profile in the GM data (Fig. S11), which is a reasonable starting point, but this explanation only appears in the latter part of the section. Consolidating the discussion in one place, and adding a clearer account of the remaining implications (e.g., whether GPS data sparsity at night or night-time traffic-composition changes also contribute, and what this means for 24 h applications), would help.Comment 5: Framing of the "dynamic urban climate studies" scopeThe title and abstract frame the work within "dynamic urban climate studies," while the manuscript itself is a transport-model description and evaluation study; coupling via DAVE is deferred to future work (Sect. 5.1, item 6). No climate-model coupling or additional analysis is needed here — rather, please adjust the title/abstract/introduction so that the framing and intended use match what is actually demonstrated in this paper, i.e., that this paper validates the transport component as a step toward the stated climate application.Secondary CommentsThe points below are suggestions to improve clarity and completeness; they are not, on their own, reasons to withhold publication.Comment 1: Source speed-data description and licensing. The Digimap Pilot Collection (2024) GPS speed data lack basic summary metadata — observation counts, spatial coverage across boroughs, and temporal density per time bin. Where full disclosure is restricted by licensing, a short statement plus any shareable high-level summary (e.g., counts or coverage per borough or per time bin) would help readers judge how well the averaged speeds represent actual traffic conditions, particularly at night (see Comment 4 above).Comment 2: Rationale for the Hit Rate thresholds. Sect. 3.2.4 uses a ±5 min tolerance (HR5) for short routes (≤14 km) and a ±10 min tolerance (HR10) for long routes (>14 km; Eq. 8). A brief justification for these specific values would help readers judge how stringent the metric is.Comment 3: Notation clarity. The λ and Fraktur F notations in Appendix A should be made more consistent and clear.Comment 4: Charging and low-emission zones and spatial route realism. MATSDA routes more journeys through central London than Google Maps, which the authors attribute in part to the omission of charging and low-emission zones (Sect. 4.3, Fig. 13a–c). This may affect route realism; a brief quantification would help.Comment 5: Parameter sensitivity: spatial homogeneity. F_L and JTP are derived from a domain-wide sensitivity analysis (Sect. 4.1). Are these parameters assumed spatially homogeneous, or do results (e.g. Fig. 6, Fig. S6) show differences between inner-London and suburban areas? A brief comment on this would be useful.Comment 6: Section 4.2 signposting. The cases in Table 3 would benefit from clearer signposting or subheadings.Comment 7: Integration of supplementary material. Key results from Supplementary Sections S1–S4 could be summarized in the main text.RecommendationMajor RevisionThe manuscript documents the model clearly and evaluates it against a substantial reference dataset, with code and data openly archived. Publication, however, depends on three points being clarified: (i) what MATSDA specifically contributes relative to existing routing approaches (Comment 1); (ii) the scope over which the London-calibrated parameters apply and what adaptation would be needed elsewhere (Comment 2); and (iii) what the comparison against Google Maps can and cannot show, together with a clearer account of the overnight-bias implications (Comments 3–4). The framing of the climate-study scope (Comment 5) should also be brought in line with what is demonstrated. None of these points require new analyses, additional data collection, or climate-model coupling — they concern how the existing material is framed, discussed, and cross-referenced.Citation: https://doi.org/
10.5194/egusphere-2025-6060-RC3
Model code and software
MATSDA-roads (Movement And Transport Simulations using Dijkstra's Algorithm - roads) (v2.0) T. Ma et al. https://doi.org/10.5281/zenodo.17736682
Viewed
| HTML | XML | Total | Supplement | BibTeX | EndNote | |
|---|---|---|---|---|---|---|
| 1,457 | 618 | 108 | 2,183 | 295 | 76 | 142 |
- HTML: 1,457
- PDF: 618
- XML: 108
- Total: 2,183
- Supplement: 295
- BibTeX: 76
- EndNote: 142
Viewed (geographical distribution)
| Country | # | Views | % |
|---|
| Total: | 0 |
| HTML: | 0 |
| PDF: | 0 |
| XML: | 0 |
- 1
General comments
The paper presents a model for capturing car flow patterns by iteratively computing optimal routes within a simplified nodal configuration of the urban traffic network. Based on the authors' impressive work, the model is developed and implemented for the London urban network. It shows the spatial distribution and diurnal variability of urban road traffic flow, but is limited to a selection of car-commuter classes.
The paper and the supplementary materials provide sufficient explanations of the model's development and validation. Therefore, the model could be replicated for other urban environments. Certainly, it is questionable if the validation steps followed for London would be sufficient for other urban cases. Nevertheless, the authors present appropriate indications and metrics to guide the validation process in other circumstances and specificities.
Specific comments
1. The authors appropriately emphasise the contributions of the proposed model compared to existing routing applications. Nevertheless, it would be worthwhile to have clearer explanations of how the presented model will address the stated goal of supporting urban climate modelling and environmental exposure assessments.
2. In the model evaluation, the route selection is limited to car commuters. The temporal and spatial evaluations are calibrated using historical traffic data from Google Maps. No correlations between person movements and traffic flow are discussed (e.g., modal share, car occupancy). Additionally, no impact of other types of road vehicles (e.g., freight vehicles, etc.) is considered.
3. The model is calibrated and validated based on historical traffic data from Google Maps. It is not demonstrated that it functions as a simulation model under changes to the considered urban structure or multimodal urban transport system (i.e., changes in modal choices for diurnal journeys).
Technical corrections
4. The paper is well structured, and the flow of the model description and implementation is coherent. Nevertheless, it would be useful to provide a synthetic overview of the methodology (before the model description), eventually including a flowchart of the study's main steps.
5. In the conclusion section, it would be helpful to explicitly redefine all the configurations referred to by #1, #2, … #7 (or at least add a reference to Table 3 for each of them).