How we built a Canada-wide accessibility and travel-time engine

When a public health researcher in Nova Scotia wants to map food deserts, they need to answer questions such as which households can reach a grocery store within a 15-minute walk. When a transit planner in Calgary evaluates a new bus route, they need to understand how it changes access to employment centres. When a housing advocate in Toronto argues that a neighbourhood is underserved, they need data showing how long it takes residents to reach schools, clinics, and parks.

These are equity questions. When we map food deserts, we're identifying communities at risk. When we analyze transit access to employment, we're measuring economic opportunity. When we track how long it takes to reach schools and clinics, we're quantifying barriers that disproportionately affect low-income neighborhoods.

These questions all depend on the same underlying information: realistic travel times. Not straight-line distances, but actual routes: ones that follow real roads, respect one-way streets, and reflect whether someone is walking, cycling, or driving.

At Curbcut, we built this to serve multiple stakeholders and research needs from a single foundation. Rather than calculating travel times from homes to grocery stores, then recalculating for clinics, then again for parks, we built reusable infrastructure: travel times between every dissemination block (the smallest geographic unit Statistics Canada publishes, roughly equivalent to a city block). Once we know the travel time between any two blocks, accessibility to any destination becomes a simple lookup. Assign the grocery store to its block, and the travel times are already there. The food desert researcher and the transit planner draw from the same foundation without triggering new calculations or duplicating effort.

This approach implies operating at national scale. And while this design is straightforward conceptually, its scale is not. With roughly half a million dissemination blocks, the number of origin–destination combinations grow quadratically.

Why this infrastructure matters for equity analysis

Before diving into the technical challenge, it's worth understanding why solving this problem matters. Traditional accessibility studies are often limited to single cities or specific use cases because calculating travel times at scale is computationally prohibitive. This means:

• Rural and smaller communities are often excluded from analysis

• Cross-regional comparisons are impossible

• Researchers and advocates lack the data to make evidence-based arguments

• Policy decisions are made without understanding their accessibility impacts

By building national-scale infrastructure, we enable the Nova Scotia researcher, Calgary planner, and Toronto advocate to ask their questions without needing their own technical infrastructure. This is data democratization in action.

Why this is hard: The curse of squared numbers

A travel time matrix pairs every origin with every destination. For 500,000 dissemination blocks, that's 500,000 multiplied by itself: 250 billion pairs.

To put that in perspective: if you stored each travel time as a single number, the resulting file would exceed a terabyte. No ordinary computer can hold that in memory, let alone compute it in reasonable time. Most routing software assumes you're calculating a handful of trips, maybe a few thousand. We needed something entirely different.

The key insight: Throw out what you don't need

The breakthrough was recognizing that most of those 250 billion pairs are meaningless. The Toronto advocate doesn't need to know how long it takes to walk from a Scarborough neighbourhood to a school in Vancouver. Nobody walks 200 kilometres to get groceries. A 4-hour drive isn't relevant for daily accessibility.

So instead of computing everything, we filter first. For each origin, we identify only the destinations within a realistic travel radius:

• Walking: 10 kilometres (roughly an hour at a brisk pace)

• Cycling: 30 kilometres

• Driving: 120 kilometres

We use a spatial indexing technique that quickly finds all dissemination blocks within these distances. A block in downtown Montreal might have a few thousand neighbours within 30 kilometres; one in northern Quebec might have a dozen. Either way, we've reduced the problem from hundreds of billions of pairs to around 150 million, a 99.94% reduction.

We're computing exact travel times for every pair that could plausibly matter for accessibility analysis.

Routing at scale: Enter OSRM

To compute realistic travel times, we rely on the Open Source Routing Machine (OSRM), which is the same open-source routing engine used in many navigation tools. It calculates routes along real road networks using OpenStreetMap data, accounting for one-way streets, turn restrictions, and differences between walking, cycling, and driving.

We self-host OSRM on our own servers using Docker containers. This gives us complete control over capacity, configuration, and optimization, critical when processing millions of requests. Unlike calling an external API with rate limits, we can tune our infrastructure to the specific needs of large-scale accessibility analysis.

OSRM is designed to answer questions like: how long does it take to get from here to there? For a small number of trips, this works extremely well.

The challenge appears at scale. OSRM is built like a conversation: you ask one question, it replies with one answer. When you need answers for millions of trips, the time spent just asking and receiving those questions overwhelms the actual route calculation. The routing itself is fast; the back-and-forth communication becomes the limiting factor.

The HTTP problem (and how we solved it)

Every time you ask OSRM for a travel time, your computer opens a connection, sends coordinates, waits for a response, and closes the connection. These back-and-forth exchanges take time, often more time than the actual route calculation.

If we sent requests one at a time, we'd spend most of our time waiting for network roundtrips, not computing routes. OSRM would sit idle while our code processed each response.

The solution is batching and parallelism. Instead of asking for one route at a time, OSRM's "table" endpoint accepts multiple coordinates and returns a matrix of travel times between them. And instead of waiting for each response before sending the next request, we fire off many requests simultaneously.

Through extensive testing, we found the sweet spots:

• Concurrent connections should scale with your server's capacity. Too few, and the routing engine sits idle between requests. Too many, roughly beyond three times your available CPU threads, and you're just creating a queue. Requests pile up waiting to be processed, and some start timing out.

• Batch size involves a trade-off. Smaller batches mean more requests, which means more connection overhead. But larger batches make each individual calculation take longer, the complexity grows with the square of the number of coordinates, and oversized requests risk failing entirely. We found a middle ground: large enough to minimize overhead, small enough for reliable sub-second responses.

With the right configuration, the entire country completes in hours rather than weeks.

Storing the results: lists, not matrices

Traditional travel time data comes as a giant grid: rows for origins, columns for destinations, cells for travel times. That format assumes you need every cell, which we don't.

Instead, we store results as a collection of lists. Each origin gets its own compact table containing only its reachable destinations and the corresponding travel times. A dissemination block in suburban Ottawa might have 800 entries; one in rural Manitoba might have 40. We store exactly what exists, nothing more.

This sparse format means our national dataset fits comfortably in memory on a standard workstation. Queries are fast because we're not searching through empty cells.

What this infrastructure powers

The City of Laval uses these travel times in Curbcut Laval to evaluate proposed locations for new community facilities. When planning where to site a new library or community center, city planners can instantly see which neighborhoods currently have the longest travel times to existing facilities, ensuring new investments reach areas of greatest need.

This same infrastructure now makes similar analysis possible across Canada:

• Public health researchers can map food deserts across entire provinces, identifying which rural communities fall outside a 15-minute drive of any grocery store.

• Transit planners can compare cycling access to employment centres across neighbourhoods, pinpointing where infrastructure investments would make the biggest difference.

• Housing advocates can show precisely which neighbourhoods face the longest walks to schools, clinics, and parks, and how those patterns break down by income.

The Data Bridge connecting travel times to everything else

The travel time matrix is powerful on its own, but its real value emerges through Curbcut's Data Bridge, our core technical innovation that democratizes access to sophisticated spatial analysis by integrating travel times with thousands of other data variables.

This means users can instantly explore questions like:

• How does transit accessibility correlate with household income?

• Which neighborhoods with poor healthcare access also have high proportions of elderly residents?

• Where are new housing developments being built in relation to employment centers?

The infrastructure we've described here is the foundation, but the Data Bridge makes it actionable for non-technical users through Curbcut's platforms.

From infrastructure to impact

Computing travel times at national scale isn't about raw computing power, but about being strategic with what you compute and how you compute it. By filtering to relevant pairs, optimizing batching and parallelism, and storing results efficiently, we turned an impossible problem into a manageable one.

But the real achievement isn't technical, it's that this infrastructure now powers equitable, data-driven decision-making across Canada. The public health researcher doesn't need to hire a data engineer. The transit planner doesn't need to learn Python. The housing advocate doesn't need a research budget.

This is what data democratization looks like: sophisticated analysis, made accessible. And because the entire country processes in hours rather than weeks, we can keep it current as communities evolve.

Ready to explore accessibility patterns in your community? Curbcut offers access to these travel times alongside 2,000+ other data variables. Municipal partners can deploy Curbcut platforms for their communities with custom data integration. Contact us to discuss how accessibility analysis can inform your next policy decision.