The circle lies: how much a bus stop actually covers

How much of the city does a bus stop actually reach?

The standard answer is a circle: a 375-metre radius, five minutes at 4.5 km/h. It shows up in most public transport accessibility studies, and it is convenient because it takes one line of code.

It is also wrong by a factor of three and a half.

The problem

A circle knows nothing about the city. It crosses rivers, railways, boundary walls and dead ends as casually as it crosses an open square. It counts as reachable everything within 375 metres as the crow flies, while on foot you can only move where there is a street.

This is not an academic concern: that measure decides where stops get added, which ones look redundant, how much population is served. If the measure is inflated, so are the decisions.

Measuring the right thing, though, is not trivial. The first obstacle is that stops almost never sit on an intersection. Starting the computation from the nearest graph node — the obvious shortcut — throws away up to a quarter of the isochrone before you even start walking.

The solution

We built Fermata, which computes for each of the 1,308 TPER stops in the city of Bologna the area reachable in five minutes along the real street network:

• Shortest paths on the real graph — Dijkstra over the city’s street network, not a geometric buffer
• Snapping by projection — each stop is projected onto the nearest edge and inserted as a virtual node, connected to both endpoints by the real distance along the geometry, so the budget is spent walking rather than reaching the nearest junction
• Three pedestrian networks compared — the official RIFTER street graph, OpenStreetMap and the two merged, comparable stop by stop, plus a third-party isochrone service as a cross-check
• A composite value index — population served, share of vulnerable residents, income, accessibility and safety of the walk, distance to the nearest interchange

On income the choice is deliberately equity-first: a lower median-income area weighs more, because it has fewer mobility alternatives. That is not a technical default, it is a value judgement — and it should be stated, not buried in a weight.

The result

On real data for Bologna, the area genuinely reachable on foot from the stop network is 3.49 times smaller than the one the circle method claims as covered.

This is not a marginal gap to absorb with a safety factor: these are two maps describing two different cities. And the second one does not exist.

The comparison is visible stop by stop in the application demo: the polygon following the streets, the segments actually walked and the euclidean circle, overlaid on the same stop.

The part nobody writes up: when the numbers get worse

Twice during the project we changed method and our own results got worse. Both times it was the right call.

First case: the shape of the isochrone. The reachable area was initially closed with a concave hull. Switching to a buffer around the edges actually walked, the covered area nearly halved — and the circle’s overestimation, consequently, grew further. The earlier method was filling in the interiors of city blocks around every stop: private courtyards and gardens counted as walkable. The lower number is the correct one.

Second case: the holes in the coverage. Walksheds have intentional holes — courtyards and block interiors you cannot walk through. Computing “uncovered areas” as the complement of coverage counted those holes as unserved periphery. On the real dataset the vast majority of those voids were internal courtyards, inflating the population classified as unreached by more than half. A courtyard is not an area to serve with a new stop: it is a physical obstacle.

Had we published the first version, we would have described a city with a far worse coverage problem than the real one, in numbers that looked authoritative.

The principle that applies everywhere

A model that agrees with you is a model you have not finished checking.

Neither correction above surfaced from a failing test: the code ran, the numbers were plausible, the maps looked good. They surfaced from going and looking at what those polygons actually represented, one at a time, until the arithmetic stopped adding up for the wrong reason.

This holds for isochrones as for any data pipeline: the useful question is not “does the computation run?” but “am I measuring the thing I think I am measuring?”. The first almost always answers yes. It is the second one that changes decisions.

Making decisions on geospatial or operational data? Get in touch — let’s check together whether it measures what you think it does.