How we shrank our trip planner till it didn’t need data.

How we did it (step 1)

Static transit data (i.e. schedules, stop lists, route maps) provide the first obstacle to offline access. Why? The files are HUGE! Transit agencies use a data format called GTFS, whose files can be 100MB+. That’s a lot of data — and just for schedules, stop lists, route maps. Moreover, it’s a lot of data to parse through every time you need to calculate a trip plan.

But those 100MB files have lots of redundancies. With the right math, you can suss out patterns in transit schedules, and represent them in more efficient ways. Why store a bus schedule as “12:00AM, 12:10AM, 12:20AM” if you could store it as “0:00, +10, +10”, which takes fewer characters, and thus less space?

What if you could find even more tricks, more efficient ways to represent data? How much space could you save?

It turns out… a lot.

To squeeze out those efficiencies, Anton and Guillaume built an in-house compression library called bGTFS, where the “b” stands for binary. It can shrink your city’s transit data files between 30X to 200X.

It’s significantly more efficient than .zip compression, and lets you download/store/load your city’s transit data in seconds.

It’s why Transit feels so refreshingly fast.

After we built bGTFS, we extended our repertoire of compression tricks to maps: bOSM is our way of compressing Open Street Map data. It lets us take all the relevant stuff we want (streets, intersections, footpaths, bike paths) and dumps the info we don’t (like the “horse accessibility” of certain streets… lol).

With bOSM, we represent the world in a compressed 1024 tile x 1024 tile grid of which we need ~9 tiles per city. But where an OSM map of the globe would need ~44GB of data, a bOSM map needs just ~3.4GB — of which your city is a teeny fraction. In Montreal, a bOSM map requires just 10MB. Very nice!

Together with bGTFS + bOSM, we can now store all your city’s transit, biking, and walking data in super tiny files, right on your phone.

Step 2: going offline (and getting off the cloud…)

Storing transit data on your phone is one thing. But doing calculations on that data is a whole other plate of spaghettios.

Until today — and until we met Rod 😍 — there was no way to plan a transit trip without a data connection. Connected to data, you could plan trips that integrated real-time disruptions and vehicle positions. Disconnected, you couldn’t even plan a trip based around the schedule!

You’d either have to find your way with a map, ask for directions, leave the subway for better reception, or pray for it to regain reception mid-ride.

If you were on your everyday commute, losing your “trip planning superpowers” wasn’t a big deal. But if you were in a new city or on an unfamiliar route, the data-dependency of our trip planner could be stressful. How could we make the trip planner more consistently useful?

To make it fully offline-compatible, we started with bike and walking trips. With our tiny bOSM files, it wasn’t that hard. Offline trip planning launched for those trips, last summer.

Next, we had to figure out how to use offline walking directions to discover which transit transfers were possible, and which ones weren’t. Which buses and trains (and at what times) connect with one another? The combinations seemed infinite — and infinity isn’t easy for phones to parse.

Rather than having the offline trip planner chugging away for minutes, looking up transfers between every pair of transit lines, we needed something more efficient. Something to pare down the infinite possibilities. Something lighter on computation. Something that could spit out plans in milliseconds.

So Rod did what any genius developer would do with the world’s sexiest transit data compression algorithm:

• He took our compressed bGTFS (transit) and bOSM (map) data.
• He pre-calculated the transit + walking transfers between any two stops (within a 1km radius) and discarded ones above a 20-minute walk
• He stored all those “possible transfers” to memory, in a tiny file.

Now, our app no longer had to calculate walking directions for each leg of your trip: it only needed to find walking directions from your start- and end-points to the nearest transit stop, and rely on pre-calculated transfers for the rest!

By saving “transit + walking” transfer times to memory, we can quickly compare them against your transit schedules. Which means that starting today, you can get reliable transit directions offline, including line-to-line transfers the schedule says are possible.

E.g. “Will the subway get me on my 1:00AM bus? No… but you can make the 1:20AM.”

Good transit isn’t just about getting you from a-to-b. It’s about helping you do it efficiently, and giving you the confidence to get from a-to-b — even under less-than-ideal circumstances. It’s about making transit more broadly useful, ensuring people who don’t have good data plans can still get the best information available.

And while nobody prefers to travel without real-time transit data, by making more Transit features available offline, we ensure more people can get where they need to go. Even when their subway doesn’t have WiFi. They hit their data cap. Or an ICBM whizzing red-hot across the atmosphere blows their cell satellite to smithereens.

Whatever happens, our trip planner will now work 100% of the time™ — ensuring a consistent experience, for everyone, and every ride.