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

From the OSM wiki. But do we care about horses? Neigh….

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.

For less than a minute, riders on Toronto’s Bloor-Danforth subway line go above ground, across a viaduct. Now, they can spend those fleeting seconds of 4G texting — instead of trip planning. 😘

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.

Every transit transfer??? Too much data. 💥📱🔫🧠

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.

(transit) and (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

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!

20+ minute walk?!? thank u, no 🙅‍

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.