Access to opportunity: measuring jobs reachable by transit

"How many people does this route serve?" is one of the most common questions a transit planner gets — and one of the easiest to answer badly. The usual shortcut is a buffer: count everyone living within a quarter mile of a stop. That number is easy to compute and easy to defend in a meeting, but it answers a different, weaker question than the one people actually care about. What matters to a rider is not whether a stop is nearby; it is whether the service at that stop can take them somewhere useful in a reasonable amount of time. Accessibility analysis measures exactly that.

Proximity is not access

A buffer measures proximity: presence of infrastructure near a place. Two stops a quarter mile apart look identical to a buffer even if one is served every 8 minutes all day and the other gets four buses on a school morning. The buffer also says nothing about where those buses go, how long the trip takes, or how many transfers it costs. It counts the front door of the transit network without checking whether anything is on the other side of it.

Travel-time accessibility asks the real question: starting from a given origin at a given time, how many destinations can I actually reach within a time budget, using transit plus the walking it takes to get to, between, and from stops? It folds frequency, span, network connectivity, transfer penalties, and walk access into a single number that reflects the trip a rider would really make.

The cumulative-opportunity metric

The standard, transparent way to express this is the cumulative-opportunity measure. You pick a travel-time threshold — typically 15, 30, and 45 minutes — and count the opportunities (jobs, people, grocery stores, clinics, whatever you are studying) reachable from each origin within that budget. The result is intuitive: "from this neighborhood you can reach 42,000 jobs in 30 minutes by transit." There is no opaque weighting or decay function to defend; you are simply counting what falls inside a travel-time contour.

That contour is the isochrone — a polygon (or, more precisely, a set of reachable destinations) enclosing everywhere you can get to within the threshold. Draw the 15-, 30-, and 45-minute isochrones from a point and you can see how access expands with time, and where the network's reach drops off a cliff because the only option is an infrequent or roundabout connection.

Why three thresholds

Reporting a single number hides the shape of access. A place might reach very little in 15 minutes but a great deal in 45, or vice versa. Three thresholds let planners distinguish short-trip access (errands, local jobs) from the longer commute range, and they make the equity story far more legible.

What goes into the calculation

An honest accessibility result is only as good as its inputs. Four matter most:

• The transit network. The schedule comes from GTFS — every route, trip, stop, and headway. Where you want delivered rather than planned service, GTFS-Realtime can supply the trips that actually ran, so the analysis reflects reality on the ground rather than the timetable.
• A street / walk network. Riders walk to the first stop, between stops on a transfer, and from the last stop to the destination. That walking is routed over a real pedestrian network, almost always from OpenStreetMap, with an assumed walk speed and maximum walk distance.
• A departure-time window. Access is profoundly time-of-day dependent. Leaving at 8:05 versus 8:20 can change your reachable destinations dramatically when a key connection runs every 30 minutes. Robust analyses sample many departure times across a window (say, every minute from 7:00–9:00 AM) and report the median or a percentile, rather than a single lucky or unlucky departure.
• An opportunity layer. The destinations being counted. Jobs typically come from the Census Bureau's LEHD LODES dataset; population and demographic counts come from the Census / ACS. The same machinery works for any geocoded destination set — hospitals, schools, supermarkets.

The routing engine

Computing door-to-door transit travel time from every origin to every destination, across many departure times, is a large problem. Purpose-built engines handle it. R5 (the Conveyal routing engine) is widely used in planning and research to build transit travel-time matrices and isochrones: it combines the GTFS schedule with the OpenStreetMap walk network and a range of departure times to produce reachable-destination counts and the contours that go with them. Because it profiles across a time window rather than routing a single trip, it captures the frequency effects that a one-shot trip planner misses.

Why it matters for planning

Cumulative-opportunity access rewards the things good transit actually does and that buffers ignore: running frequently, connecting to where jobs are, and minimizing transfer friction. A frequency improvement that a buffer cannot even see shows up immediately as more jobs reachable in 30 minutes. That makes accessibility a strong currency for two jobs in particular:

• Equity analysis. Compute access separately for groups and compare. A minority versus non-minority, or low-income versus higher-income, split of jobs reachable in 30 minutes turns an abstract fairness question into a measured gap — the kind of evidence a Title VI review and a board presentation both need.
• Grant narratives. Competitive federal and state applications increasingly ask projects to quantify benefits. "This project raises jobs reachable in 45 minutes by X% for Y residents, including Z low-income households" is a concrete, defensible benefit statement for a grant application.

Assumptions and caveats

Accessibility numbers are powerful, which makes their assumptions worth stating plainly:

• Departure-time sensitivity. A single departure time can mislead badly. Always profile across a window and report a central or conservative statistic.
• Walk speed and maximum walk distance. These parameters move results. A 1.0 m/s walk speed and a half-mile cap produce different access than 1.3 m/s and a quarter mile. Pick defensible values and keep them consistent across scenarios you compare.
• Schedule versus realized service. GTFS describes planned service; real buses are delayed, full, or cancelled. Where reliability matters, lean on GTFS-Realtime so the network reflects what was actually delivered.
• Opportunity vintage and geography. LODES and ACS are released with a lag and aggregated to block or block-group geographies. Note the data year and resolution so comparisons stay apples-to-apples.

How HeadwayForge helps

Standing up R5, an OpenStreetMap extract, current GTFS, and the right LODES/ACS vintages — then keeping them aligned for every agency you care about — is real engineering. HeadwayForge embeds an R5 routing engine and runs it against the same normalized national GTFS, OpenStreetMap, and Census data it already manages, so you can produce isochrones and counts of jobs and population reachable in 15 / 30 / 45 minutes from an origin without assembling a pipeline. Crucially, it computes the access result with a Title VI-grade minority versus non-minority split, so the equity comparison is built in rather than bolted on. See the product overview for how access analysis sits alongside service-supply and equity views, and the data-coverage view for which feeds and reference datasets are in scope.