Open dataset

Filed timetables on 545 city to city corridors

Version 1.0.0 · CC BY 4.0 · Snapshot of 16 September 2026

What operators had filed for 545 city to city corridors, read out of the open feeds between 12 September 2026 and 16 September 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 28 September 2026 and 43 for 30 September 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 6 October 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
What runs on them
  • 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.

  1. AalborgCopenhagen

    On 28 Sept 2026 · 3 legs · 2 changes · 4h 09m

    • 08:0309:13
      Aalborg St.Aarhus HTrain · DSB ICL · 2 intermediate stops
    • 09:2012:06
      Aarhus HKøbenhavn HTrain · DSB ICL · 5 intermediate stops
    • 12:1012:12
      København HDybbølsbro St.Train · DSB S-tog B · no intermediate stops
  2. AeginaAthens

    On 28 Sept 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
  3. AgropoliPalinuro

    On 28 Sept 2026 · 2 legs · 1 change · 2h 18m

    • 18:0519:05
      AgropoliSalerno (Piazza Concordia)Coach · FlixBus-eu FlixBus N501 · no intermediate stops
    • 19:0820:23
      SALERNOPISCIOTTA PALINUROTrain · TRENITALIA REG 5247 · 9 intermediate stops

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

Deliberate deviations

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.

Where the stops are

1,267 of 3,368 stops could be placed without guessing. The rest carry an empty latitude and longitude.

MethodStopsWhat the coordinate is
station-canonical347The centre of the settlement the stop serves.
geometry200The operator's own polyline for the leg. The stop itself.
station-exact187The centre of the settlement the stop serves.
place-containment177The centre of the settlement the stop serves.
station-normalised129The centre of the settlement the stop serves.
place-name123The centre of the settlement the stop serves.
corridor-endpoint104The 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 kilometres 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.

FileRowsSizeSHA-256
orlero-corridor-timetables-1.0.0.zip657 KiBae3104269bc88334946cde5f18ebc9ff5264d23d9ca74d5547b7dbb211fa3d57
orlero-corridor-timetables-gtfs-1.0.0.zip7,347134 KiBf190a54862419e2708b31fa7d8a64e3fa83c7b73a2f5dac5b791ed2671f92cb2
corridors.csv545105 KiBe595685ec9bcab61fe52ee704780d3cf8db79cc4d536cc16cd2589ebe4ab3c74
itineraries.csv1,035224 KiBa206cd69a3ebbfa4f2742be089a3f81166e04f29889b4fd61198e2037fefc206
legs.csv3,0251.1 MiBbef6eacc0fbdd1182036c89e9fc84ded6525ed0e264e67202f3a1a6ee09a414d
calling_points.csv11,2221.5 MiB1d8fec63c03db01213637dc3a3613793f6d58227505e34bc06c784924699c0b1
stops.csv3,368494 KiB5ff2c5ecc844a766093fbd509ce402847c086cae0cd5ae30c8fc56ecad293e93

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 licence. 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.

Licence

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.
Plan with Ori

Ori, the trip planner

Ask it something like this