Filed timetables on 545 city to city corridors
What operators had filed for 545 city to city corridors, read out of the open feeds between September 12, 2026 and September 16, 2026 and written down with the date it was read. Rail, coach, ferry and air, as a Frictionless Data Package and as a GTFS feed.
One service date per corridor
Each corridor was asked about once, for one service date, and every row carries that date and the instant of the fetch. It holds no frequency, no weekend pattern and nothing about next month.
1,254 corridors were put to the source. 545 came back with services, 694 had a stop at each end and nothing running between them, and 15 had no stop in the feeds within 60km of one end. Coverage follows who files an open feed.
502 of the corridors were probed for September 28, 2026 and 43 for September 30, 2026, which is the second date the probe tried where the first came back empty. Some itineraries run for several days, so departures in the file reach as late as October 6, 2026.
What a filed timetable is
Filed means the operator published it in advance: the service they intend to run, lodged in a feed weeks before the day. It is what the departure board says before the day starts.
- Not real timeEvery leg carries real_time = false: the requests were made two weeks before the service date, so there is no delay, no cancellation and no platform change in the file.
- No faresThe source publishes schedules and no prices, so no price is in these files. Where an operator publishes a link to where they sell the journey, that link is kept.
What is in it
Counted from the same snapshot the files are built from, so this table and the CSVs cannot drift apart.
- 545Corridors with services
- 1,035Itineraries
- 3,025Legs
- 11,222Calling points
- 3,368Named stops
- 1,267Of those, with a position
- 184Operators
- 33Countries
- 371Legs with a platform or track
- 620Legs filed as wheelchair accessible
- 2,132Legs carried in the GTFS feed
- 1,074Stops carried in the GTFS feed
- Train1,430
- Coach767
- Ferry725
- Flight103
Legs by mode. Bars are relative to the largest.
Ferry is a quarter of the legs, because these are corridors between cities rather than a network: an island is reached by ship or not at all.
Real itineraries
Three journeys from the file, one rail, one with a ferry and one with a coach, taken in the order the file holds them. Open legs.csv, search for the corridor, and these are the rows.
AalborgCopenhagen
On Sep 28, 2026 · 3 legs · 2 changes · 4h 09m
- 08:0309:13Aalborg St.Aarhus HTrain · DSB ICL · 2 intermediate stops
- 09:2012:06Aarhus HKøbenhavn HTrain · DSB ICL · 5 intermediate stops
- 12:1012:12København HDybbølsbro St.Train · DSB S-tog B · no intermediate stops
- 08:0309:13
AeginaAthens
On Sep 28, 2026 · 2 legs · 1 change · 1h 04m
- 08:3009:10ΑίγιναΠειραιάςFerry · ATTICA Hellenic Seaways 17083 · no intermediate stops
- 09:1409:34ΠειραιάςΑθήναTrain · Hellenic Train 1314 · 4 intermediate stops
- 08:3009:10
AgropoliPalinuro
On Sep 28, 2026 · 2 legs · 1 change · 2h 18m
- 18:0519:05AgropoliSalerno (Piazza Concordia)Coach · FlixBus-eu FlixBus N501 · no intermediate stops
- 19:0820:23SALERNOPISCIOTTA PALINUROTrain · TRENITALIA REG 5247 · 9 intermediate stops
- 18:0519:05
Times are as filed, in UTC, which is how the source publishes them and how the GTFS feed carries them. The local clock at either end is a different number.
The GTFS feed
The same snapshot as a GTFS Schedule feed, because that is what a transport researcher already has a tool for. One trip per leg, so trip_id is the leg_id in legs.csv and the two join directly.
111 agencies, 1,074 stops, 1,121 routes, 2,132 trips and 7,347 stop times across 9 service days. It validates against MobilityData's canonical GTFS validator with zero errors.
Every time in the feed is UTC
The reference requires one timezone per feed, and this snapshot spans Europe, Asia and the Americas, so every agency and every time in stop_times.txt is UTC, the instant the operator filed. Each stop carries its own stop_timezone to put the local clock back.
Deliberate deviations
- One service date per corridor, not a repeating schedule. calendar.txt has one row per service day with start_date equal to end_date and a single weekday flag set.
- Air is not in the feed: the reference defines ten route types and none of them is an aircraft. The 103 air legs are in legs.csv with mode = air and gtfs_route_type empty.
- 893 of the 3,025 legs are not in the feed, almost all because a stop at one end has no position and GTFS requires a coordinate. gtfs_trip_id in legs.csv is empty on exactly those rows.
- Some trips call at fewer stops than the operator filed, for the same reason. calling_points.csv always carries the full sequence, including the stops the feed had to drop.
- Extended route types are folded into the ten the reference defines: 101 becomes rail, 200 becomes bus, 1004 becomes ferry. The original value is kept in legs.source_route_type, so the fold can be undone.
https://gtfs.org/documentation/schedule/reference/ · MobilityData canonical GTFS validator 8.0.1
Where the stops are
1,267 of 3,368 stops could be placed without guessing. The rest carry an empty latitude and longitude.
| Method | Stops | What the coordinate is |
|---|---|---|
| station-canonical | 347 | The centre of the settlement the stop serves. |
| geometry | 200 | The operator's own polyline for the leg. The stop itself. |
| station-exact | 187 | The centre of the settlement the stop serves. |
| place-containment | 177 | The centre of the settlement the stop serves. |
| station-normalised | 129 | The centre of the settlement the stop serves. |
| place-name | 123 | The centre of the settlement the stop serves. |
| corridor-endpoint | 104 | The centre of the settlement the stop serves. |
Only the polyline gives the stop itself. Every other method gives the settlement, which in a large city can be a few kilometers out, so those rows are marked derived and the GTFS feed repeats it in stop_desc.
Two guards. A candidate has to be geographically plausible for a corridor the stop appears on: without that test "Taunton" matched the only Taunton in the gazetteer, which is in Massachusetts, and the feed claimed 23,623 km/h between Bridgwater and Taunton. Every leg is then checked against a speed ceiling well above anything that runs, and what breaks it is left out.
How each row is evidenced
Every row in every file carries source, source_url, fetched_at and evidence.
- filed
- The operator published it: stop names, service numbers, platforms, departure and arrival instants, calling points, accessibility flags. Every row in four of the five tables.
- derived
- This package computed it: in stops.csv, the rows whose position was worked out from a gazetteer rather than given by the operator.
- derived columns
- A filed row can still carry a computed column. Durations, distances, counts and the folded GTFS route type are arithmetic over filed values, and the Table Schema names each one as derived.
2,405 of 3,025 legs are filed as not wheelchair accessible, which says how feeds are filled in rather than what the rolling stock is.
Download
A Frictionless Data Package with a Table Schema for each resource, and the GTFS feed beside it. CSV in RFC 4180, UTF-8 without a byte order mark, LF endings, and a SHA-256 for every file. Nothing here needs an account or a key.
| File | Rows | Size | SHA-256 |
|---|---|---|---|
| orlero-corridor-timetables-1.0.0.zip | 657 KiB | ae3104269bc88334946cde5f18ebc9ff5264d23d9ca74d5547b7dbb211fa3d57 | |
| orlero-corridor-timetables-gtfs-1.0.0.zip | 7,347 | 134 KiB | f190a54862419e2708b31fa7d8a64e3fa83c7b73a2f5dac5b791ed2671f92cb2 |
| corridors.csv | 545 | 105 KiB | e595685ec9bcab61fe52ee704780d3cf8db79cc4d536cc16cd2589ebe4ab3c74 |
| itineraries.csv | 1,035 | 224 KiB | a206cd69a3ebbfa4f2742be089a3f81166e04f29889b4fd61198e2037fefc206 |
| legs.csv | 3,025 | 1.1 MiB | bef6eacc0fbdd1182036c89e9fc84ded6525ed0e264e67202f3a1a6ee09a414d |
| calling_points.csv | 11,222 | 1.5 MiB | 1d8fec63c03db01213637dc3a3613793f6d58227505e34bc06c784924699c0b1 |
| stops.csv | 3,368 | 494 KiB | 5ff2c5ecc844a766093fbd509ce402847c086cae0cd5ae30c8fc56ecad293e93 |
Everything is rebuilt from the committed snapshot by node data-packages/corridor-timetables/build.mjs, which fetches nothing and produces the same bytes every time. The package lives at data-packages/corridor-timetables.
How to cite it
Attribution is the whole of the license. If you use this, this is the line.
Citation
Orlero (2026). Filed timetables on 545 city to city corridors (Version 1.0.0) [Data set]. https://orlero.com/data/corridor-timetables
BibTeX
@dataset{orlero_corridor_timetables_1_0_0,
author = {{Orlero}},
title = {{Filed timetables on 545 city to city corridors}},
year = {2026},
version = {1.0.0},
publisher = {Orlero},
url = {https://orlero.com/data/corridor-timetables},
note = {CC BY 4.0}
}Identifier
No DOI yet. Cite the URL above.
License
CC BY 4.0. Facts are not owned, so what is licensed is the compilation, the identifiers, the resolved positions and the derived columns. The EU sui generis database right applies to that compilation on the same terms.
https://creativecommons.org/licenses/by/4.0/
What it cannot tell you
- One date per corridor, so nothing here supports a claim about frequency.
- At most two itineraries per corridor, so the fastest journey here need not be the fastest journey.
- Coverage is what the open data holds, largely Europe and North America.
- Operator names are as the feed spells them, so one company can appear under several names.
- Fares, real time and punctuality are in a different dataset.