Digitraffic: Finnish Transport Data Platform
- Digitraffic is an open transportation data platform offering real-time and historical traffic, weather, and railway delay information via public APIs.
- It supports research by providing granular, event-level data for railway timetable analysis and diverse road data feeds for route optimization.
- The service aggregates heterogeneous data products—from weather forecasts to train timetables—demonstrating its vital role in intelligent transport systems.
Searching arXiv for papers mentioning Digitraffic and related Finnish transport open data services. Digitraffic is an open transport-data interface operated by Fintraffic, a traffic management entity owned by the Finnish Ministry of Transport and Communications. In current arXiv literature, it appears through at least two concrete service domains: Finland’s open road data interface and the Digitraffic Railway Traffic Service. Across those domains, Digitraffic functions as a public operational data source rather than a secondary reference: it exposes real-time and historical traffic information through open APIs, supplies the primary observational scaffold for railway delay analysis, and provides the road-weather, traffic, and event streams needed for route recommendation and related intelligent transportation applications (Tammia et al., 11 Aug 2025, Borin et al., 23 Jan 2026).
1. Institutional position and general character
Digitraffic is described in the literature as an open interface for operational transport data. On the road side, it is presented as Finland’s open road data interface, exposing real-time, nationwide road-traffic sensing and event information through open APIs. On the railway side, the relevant service is Fintraffic’s Digitraffic Railway Traffic Service, which provides train movement and timetable records and can be used as the base table for downstream analytical integration (Tammia et al., 11 Aug 2025, Borin et al., 23 Jan 2026).
The service is notable for being both operational and openly accessible. For the railway API usage documented in current research, authentication is not required, the rate limit is 60 requests per minute per IP, most responses are cached for approximately one minute, and the license is CC BY 4.0. The road interface is exposed through JSON APIs and, for some streams, MQTT/WebSocket interfaces. This combination of open access, machine-readable transport data, and operational granularity is a defining characteristic of Digitraffic as represented in recent research (Borin et al., 23 Jan 2026, Tammia et al., 11 Aug 2025).
A central feature of Digitraffic is that it is not limited to a single data product. The road literature treats it as a heterogeneous source of weather stations, traffic measurement stations, camera feeds, forecasts, maintenance information, and incident announcements, whereas the railway literature treats it as a timetable-event system in which station-by-station operational records define routes, schedules, and delays. This suggests that Digitraffic is best understood as a family of transport data services with mode-specific operational semantics rather than as a single homogeneous dataset (Tammia et al., 11 Aug 2025, Borin et al., 23 Jan 2026).
2. Service domains, interfaces, and observable scale
The two best-documented Digitraffic domains in current arXiv work are road traffic and railway traffic. The road interface is characterized by high attribute breadth and heterogeneous feeds; the railway interface is characterized by event-level timetable structure and historical retrieval by departure date.
| Service domain | Data products documented in research | Interface and update notes |
|---|---|---|
| Road traffic | Road-weather, TMS data, traffic messages, variable signs, road maintenance, cameras, forecasts | JSON; MQTT/WebSocket for some streams |
| Railway traffic | Historical train-by-date records, timetable events, delay fields | /api/v1/trains/{departure_date} |
| Road imagery | JPEG road-weather camera images | Update every 10 minutes; JSON |
For road data, one paper reports more than 2,300 real-time attributes from 1,814 stations nationwide. In July 2024, it reports 529 active weather stations, with 4 temporarily removed, and 58 of these located at airport runways; after excluding runway stations, the working set was conceptually 471 active road-weather stations. The same paper reports 761 camera locations, one temporarily removed, leaving 760 active sites, each with 1–7 presets, and 520 traffic measurement stations, of which 15 were temporarily removed, leaving 505 active traffic measurement stations. Measurement-site metadata is stated to be updated twice daily (Tammia et al., 11 Aug 2025).
The road interface also has topic-specific update characteristics. Road-weather cameras are JPEG images updated every 10 minutes and available through JSON. Current road-weather, TMS data, traffic messages, and road maintenance are described as real-time and available through MQTT and JSON. Road-weather forecasts update every 5 minutes through JSON. Variable signs are real-time via JSON. The shortest possible JSON interval is stated as 1 minute, and traffic announcements received via MQTT are gzipped and must be decompressed (Tammia et al., 11 Aug 2025).
For railway data, the documented retrieval path is more specific. The paper on Finnish railway delays explicitly states that the operational data come from Fintraffic’s Digitraffic Railway Traffic Service and, for historical retrieval, from the endpoint /api/v1/trains/{departure_date}, which returns all trains operated on a given departure date. Although Digitraffic more broadly offers train timetables, real-time location data, speed, train composition details, and station infrastructure metadata, the published construction pipeline cited in the paper uses the historical trains-by-date endpoint and the fields returned there, especially the nested timeTableRows structure (Borin et al., 23 Jan 2026).
3. Railway Traffic Service as an event-level operational model
In the railway literature, Digitraffic is not merely an input source but the operational backbone of the dataset. The integrated train–weather resource described in the paper is built by taking Digitraffic’s train movement and timetable records as the primary table and then attaching meteorological observations to each train event. Digitraffic therefore defines the unit of analysis, the delay targets, the temporal structure of journeys, and much of the exploratory analysis and modeling task (Borin et al., 23 Jan 2026).
At the train level, the service provides metadata including trainNumber, departureDate, operatorUICCode, operatorShortCode, trainType, trainCategory, commuterLineID, runningCurrently, cancelled, version, timetableType, timetableAcceptanceDate, and timeTableRows. The operational core is timeTableRows, an array whose documented fields include stationName, stationShortCode, type (ARRIVAL / DEPARTURE), scheduledTime, actualTime, differenceInMinutes, cancelled, stationUICCode, countryCode, trainStopping, commercialStop, commercialTrack, causes, trainReady, liveEstimateTime, and estimateSource (Borin et al., 23 Jan 2026).
This structure induces an event-level rather than a train-level data model. A route is represented as an ordered sequence of timeTableRows for a trainNumber on a departureDate. Intermediate stops produce two records, arrival and departure, while the origin has only departure and the terminal station only arrival. The paper states that a journey with stopping points yields $2n-1$ rows when all are commercial stops. A plausible implication is that Digitraffic’s railway service is especially well suited to sequence-aware modeling, because the native data model already encodes movement chronology and delay propagation at stop level (Borin et al., 23 Jan 2026).
The documented study covers January 2018 to December 2024 on the Finnish state-owned railway network, reported as 5,915 km. The station network used in the analysis includes 549 stations in Finnish territory over 2018–2024, of which 340 are non-passenger stations and 209 are passenger stations. The broader Digitraffic data also included 11 stations in Sweden and Russia, but the cited analysis focused only on Finnish territory. At this event-level granularity, the final integrated train–weather dataset contained about 38,551,161 observations (Borin et al., 23 Jan 2026).
Digitraffic also directly supplies the core delay semantics. The paper reproduces Fintraffic’s definition
It then interprets the field as on time if differenceInMinutes = 0, delayed if differenceInMinutes > 0, and ahead of schedule if differenceInMinutes < 0. The authors do not reconstruct raw delay independently; they import the precomputed Digitraffic measure and engineer additional target variants from it, including differenceInMinutes_offset, differenceInMinutes_eachStation_offset, trainDelayed, and cancelled (Borin et al., 23 Jan 2026).
4. Road data model and application-oriented preprocessing
On the road side, Digitraffic is presented as a broad sensor and event ecosystem rather than a single coherent table. The route recommendation study uses three main categories: road-weather data, traffic measurement data, and road event or alert data, especially road work and accidents. The practical problem is not access alone but semantic interpretation, variable selection, and alignment to a routing graph (Tammia et al., 11 Aug 2025).
Road-weather attributes are identified by sensor IDs 1 to 226, but metadata can only be fetched for 148 sensors through /api/weather/v1/sensors. Because of duplicates and near-duplicates, the authors thematically grouped and collapsed variables, reducing the set to 86 attributes after combining duplicate variables. They organized the useful weather attributes into road surface conditions, visibility, and other environmental factors, while discarding a fourth group of attributes that do not influence driving conditions (Tammia et al., 11 Aug 2025).
Several concrete preprocessing issues are emphasized. Duplicate sensors occur for concepts such as road-surface temperature, where multiple near-identical measurements may exist. Some categorical values are returned numerically with poor descriptions. Station capabilities vary widely: in the reported study region, the richest weather station produced 120 attributes, while the smallest produced only 23; traffic stations ranged from 30 to 8 attributes. When a station produced no data at all, the authors manually assigned a secondary station. They also removed airport runway weather stations, temporarily removed stations, test stations, and one station producing no data despite metadata claims (Tammia et al., 11 Aug 2025).
Traffic measurement data are described as better documented than weather data. The traffic metadata include 103 attributes, numbered from 5016 to 100000. For route costing, the paper retains direction-specific continuous volume-to-capacity ratio and average speed in the past 5 minutes as a percentage of free-flow speed, while discarding lane-specific attributes, raw speed values, and several aggregate or interval variants. A concrete data-quality problem is also reported: one station had clearly outdated free-flow-speed metadata, which the authors corrected manually in their program (Tammia et al., 11 Aug 2025).
Digitraffic’s road event feeds include road-work and traffic-announcement data. Road-work records contain work times, start and end times, work type, restrictions, disturbance severity, and descriptive fields, but the paper notes that much of this content is written for humans rather than machines. Because work types are free-text and inconsistent, the authors used only severity of disturbance. For accidents, they defined a segment-level accident cost of 1 if a preliminary accident report was published in the last 30 minutes, or if an accident report or general announcement existed and there had been no “all clear” (Tammia et al., 11 Aug 2025).
A key practical limitation is that Digitraffic does not itself provide the full routable road graph in the form needed for the cited application. The authors therefore imported geometry from Väylävirasto ShapeFiles, segmented roads at intersections with QGIS and PyQGIS, built a graph with NetworkX, and then attached one road-weather station and one traffic station to each road segment, usually by geographical proximity with manual corrections when the nearest station was on the wrong road. This suggests that Digitraffic road data are operationally rich but often require substantial external geospatial scaffolding before they can support downstream optimization (Tammia et al., 11 Aug 2025).
5. Research uses and empirical findings
Digitraffic has already supported two distinct classes of research use: railway reliability analysis with synchronized weather covariates, and road route recommendation with personalized cost functions.
For railways, the integrated dataset built on top of Digitraffic enabled network-scale characterization of Finnish delays. The cited analysis reports that winter months exhibit delay rates often exceeding 25%, June reaches 21.8%, weekdays are more delay-prone than weekends, Friday reaches 31.6% in February, and Saturday has the lowest delay percentages, around 12.2%–25.5% depending on season. It also reports geographic clustering of high-delay corridors in central and northern Finland. These findings depend directly on Digitraffic’s stop-level timetable-event structure, because the methodology evaluates each individual train schedule stop rather than only final-destination punctuality (Borin et al., 23 Jan 2026).
The same paper demonstrates machine-learning use. In a baseline experiment on long-distance trains passing through Oulu asema from 2018–2024, the authors used 101,146 observations and an XGBoost regressor to predict the Digitraffic-derived target differenceInMinutes_eachStation_offset. The reported results are 2.73 min MAE for differenceInMinutes_eachStation_offset, 4.21 min MAE for differenceInMinutes, and 4.81 min MAE for differenceInMinutes_offset. The authors interpret the better performance of the station-specific target as evidence that Digitraffic’s sequential timetable structure makes it possible to separate locally generated delay from propagated delay (Borin et al., 23 Jan 2026).
For roads, the route recommendation study uses Digitraffic as the live condition layer in a personalized routing engine. The authors validate the system on real-world data and report that they can efficiently identify and recommend personalized routes for three different driver profiles. Their study area in southwestern Northern Ostrobothnia contained 27 weather stations and 37 traffic measurement station locations after filtering. The evaluation considered three real-world situations: a calm Tuesday noon in August, a late-summer thunderstorm, and a slippery chilly October morning with light snowfall. The resulting routes differed by driver profile and by current Digitraffic-derived traffic, weather, and road-work conditions (Tammia et al., 11 Aug 2025).
The two use cases illustrate complementary strengths. Railway research exploits Digitraffic’s exact event chronology, route order, and precomputed delay fields. Road research exploits the breadth of road-weather, traffic, and event feeds, but only after extensive normalization into edge-level cost factors and user-specific preference vectors. This suggests that Digitraffic supports both direct operational inference from native fields and higher-level application design through semantic aggregation (Borin et al., 23 Jan 2026, Tammia et al., 11 Aug 2025).
6. Limitations, reproducibility, and broader significance
The literature is explicit that open access does not make Digitraffic immediately analysis-ready. On the road side, the main obstacles are incomplete and uneven metadata, duplicate and ambiguous sensors, heterogeneous station capability, sparse spatial coverage, human-readable event descriptions, inconsistent free-flow-speed metadata, and the apparent absence of public historical road-weather or road-condition data for the authors’ area of interest. The practical response in the route paper is heavily engineered and partly manual: duplicate averaging, fallback attributes, manual station assignment, manual metadata correction, and custom normalization to cost factors (Tammia et al., 11 Aug 2025).
On the railway side, several reproducibility-relevant details remain unspecified in the cited paper. The temporal alignment between weather and train events uses nearest-neighbor temporal matching within a predefined tolerance window, but the exact width of that window is not stated. The exact train-side timestamp used for weather alignment is not explicitly identified. The full list of dropped raw Digitraffic columns is not enumerated. The paper also contains internal inconsistencies, including whether raw hour is removed or retained in the final feature set and a malformed robust-scaling equation. These caveats do not alter the central role of Digitraffic in the pipeline, but they matter for strict reproduction (Borin et al., 23 Jan 2026).
Another recurring point is that not every documented Digitraffic capability is always used in final research pipelines. The railway paper notes that Digitraffic more broadly offers real-time location data, speed, train composition details, and station infrastructure metadata, but the published dataset construction relies specifically on the historical trains-by-date endpoint and timetable rows. Similarly, the road paper discusses cameras, forecasts, variable signs, exempt transports, and maintenance tracking, but its implemented system uses only a subset of these feeds. A common misconception is therefore that access to Digitraffic automatically yields a turnkey digital twin or routing engine. The published evidence indicates the opposite: the major burden lies in integration, semantic interpretation, and task-specific preprocessing (Borin et al., 23 Jan 2026, Tammia et al., 11 Aug 2025).
In adjacent arXiv literature, several works use the notion of a “Digitraffic-style” platform to describe broader systems that combine live sensing, digital twins, camera analytics, distributed sensing, and corridor-scale prediction. These works concern adaptive control, digital-twin traffic operations, and multimodal monitoring rather than the Finnish service itself, but they contextualize why Digitraffic matters: a platform that exposes real operational states through open interfaces can serve as the data substrate for simulation-backed control, monitoring, and route optimization (Shahriar et al., 2024, Zipfl et al., 3 Jul 2025, Yousefzadeh et al., 2024, Dasgupta et al., 2021, Dasgupta et al., 2023, Rezaei et al., 2021, Xie et al., 2024).
Taken together, current research portrays Digitraffic as a public operational data infrastructure whose significance lies less in any single API endpoint than in the way its mode-specific feeds encode the real transport system. In rail, it provides sequence-structured timetable events and delay semantics. On roads, it provides broad but heterogeneous weather, traffic, and event observations. In both cases, its research value derives from the same property: it exposes sufficiently detailed, open operational data to support analysis, modeling, and application-building at national or corridor scale (Borin et al., 23 Jan 2026, Tammia et al., 11 Aug 2025).