Blog · 16 October 2026 · TC Data Consultants

Replacing OpenTripPlanner with MOTIS for Great Britain

TransCAPI plans door-to-door journeys by bus, train, Tube, tram and ferry anywhere in England, Scotland and Wales. Until this week that ran on OpenTripPlanner 2.9. Now it runs on MOTIS 2.11. Before switching I put the same 400 journeys through both. This is what we found, and what we had to change to get there.

Why change

The whole of TransCAPI runs on one server with 12 cores and 47 GB of memory. The data is about 390,000 stops, every National Rail station and around 1.5 million bus trips. OTP coped, but only just:

• Memory. The GB graph needed a 24 GB heap to serve (26 GB resident) and about 37 GB to build. Building and serving couldn't overlap, so every Sunday from 03:00 to 04:30 journey planning was switched off while the graph was rebuilt.
• Data trimmed to fit. The bus timetable given to OTP had no route shapes and only two months of trips, because the full feed ran the build out of memory.
• Speed. A warm journey took 3–6 seconds, with spikes past 10. That's acceptable in an API response, but too slow for a public journey planner where people type and wait.

MOTIS imports the same data in about 7 minutes, with a 9.5 GB peak. It serves with about 2.4 GB resident, plus 4.6 GB of data files that it maps into memory. That's small enough to rebuild every morning, which means no weekly rebuild and no maintenance window. The import runs in a memory-capped systemd unit, and the new data only replaces the old once it answers a test query.

The test

Both engines got exactly the same requests, through the same code path in our API, for 400 journeys sampled at random:

• 152 local bus journeys of 2–12 km between bus stops
• 100 town-to-town journeys of 10–60 km between stations
• 48 long-distance journeys of 100–650 km between the 150 busiest stations
• 100 bus-and-rail journeys of 15–50 km, from a bus stop to a station or the reverse

Each start and end point was moved up to a few hundred metres from its stop in a random direction, the way a street address would be. Most journeys were on a Monday and 15% on a Saturday, with times weighted towards the peaks. One in five was "arrive by" rather than "leave at". For each engine I took its best journey: the earliest arrival, or for "arrive by" the latest departure that still arrives in time.

Speed

These are times for the whole request as our API makes it, including the walking and cycling alternatives. The engine on its own is quicker.

Journeys

A "better" journey arrives more than 2 minutes earlier, or for "arrive by" leaves more than 2 minutes later.

MOTIS was more than 10 minutes better in 141 journeys, and OTP was in 6. MOTIS found a journey 11 times when OTP found none; OTP never found one when MOTIS didn't. Neither found one for the remaining journey. In 3 of the 80 "arrive by" requests, OTP's best journey arrived after the time asked for, once by two hours. MOTIS never did that.

Some examples, from the 12 October timetable:

• London Liverpool Street to Peterborough, leaving 16:15. OTP: 16:40, arriving 17:54. MOTIS: Circle line to King's Cross at 16:18, arriving 17:26.
• Hersham to Fulwell (Surrey to south-west London), leaving 18:30. OTP: three buses from 19:17, arriving 20:01. MOTIS: a bus, a train and a bus from 18:37, arriving 19:34.
• Where OTP won: Fratton to Bramley (Hampshire), arriving by 17:15. OTP left at 15:24. MOTIS left 27 minutes earlier on a different route.

The catch: MOTIS walks more

Across the test, the median journey walked 1.2 km on MOTIS and 0.8 km on OTP. Some of MOTIS's wins come from walking to a better station or across central London rather than changing trains. Gatwick to Stafford was 34 minutes quicker with 1.7 km of walking instead of 0.7 km. That's usually the right call, but not for everyone, so the API's walking limits still apply.

In fairness to OTP, this is OTP as we ran it: a heap that was nearly full and a timetable trimmed to fit. On a machine with twice the memory, and with more tuning, it would likely close some of the gap. What made the decision was fitting comfortably on the hardware we have.

What we had to tune

MOTIS worked well out of the box, but four things mattered for Great Britain:

1. The walk to the first station. MOTIS's default limits the walk at each end to 15 minutes (maxPreTransitTime and maxPostTransitTime). A station 16 minutes away was simply missing, and people were sent round by bus or to the next morning. We use 30 minutes.
2. The search window. We started with a one-hour searchWindow. Across London that took 7–14 seconds. MOTIS widens the window itself until it has enough journeys, so 15 minutes found the same best journey in 2–4 seconds.
3. Walking and cycling alternatives. These come from a separate request. With a four-hour cap on direct trips, some cycle routes took 22 seconds to work out. One hour covers the trips people actually compare with the bus.
4. Cold starts. MOTIS reads its street data from memory-mapped files as each area is first searched. On a server under memory pressure those pages get evicted, and the first search in a city took about 5 seconds. After each rebuild we now read the files once (cat data/osr/* > /dev/null), and those searches take under a second.

Two smaller things. MOTIS returns times in UTC where OTP used local time, so our adapter converts them. And we export the rail timetable to GTFS ourselves, with trip IDs that match our live Darwin data, so live platforms and delays still attach to the right train.

Switching over

For a week, every journey request went to MOTIS, with OTP answering if MOTIS failed or was restarting. That never happened. OTP is switched off this weekend. That frees about 20 GB of memory and ends the Sunday maintenance window, and the timetable MOTIS plans with is now rebuilt every day instead of every week.

The API didn't change: /v1/journey.json returns the same shape as before, so customers didn't need to do anything. Thanks to the MOTIS team at TU Darmstadt for a fast, well-documented engine, and to the OpenTripPlanner project, which got us to GB-wide journey planning in the first place.

Try it. TransCAPI is one API for buses, trains and journey planning across Great Britain. A free key gives you 1,000 requests a day with no card; the journey docs cover the parameters.