What is an isochrone map?
A line connecting every point the same travel time from one spot — not a circle, and an idea older than the car. What the boundary actually shows, and where it stops short of finding you a home.
“Isochrone” sounds technical because it is built from Greek rather than English — isos, equal, and khronos, time. An isochrone map draws a boundary around every point reachable from one location within a set travel time, so the fifteen-minute line and the thirty-minute line are two different shapes wrapped around the same origin, not two circles of different sizes.
Equal time, not equal distance
That distinction has a name of its own: an isodistance map draws the same kind of boundary around equal distance rather than equal time. Mapbox and Radar both describe the split the same way — isodistance ignores how long the trip actually takes. Ten miles on an open freeway and ten miles through downtown lights land on the same isodistance line and very different isochrone lines, which is the entire reason the travel-time version is the useful one for a commute question.
The idea predates the car by decades
The genre is Victorian. In November 1881, Francis Galton published “On the Construction of Isochronic Passage-Charts” in the Proceedings of the Royal Geographical Society — a copy is catalogued at Princeton's map collection — showing, in bands of color radiating out from London, how many days it took to reach the rest of the world by the ships, trains and postal routes of the day. Isotherms and isobars already existed in weather mapping; Galton's contribution, as Geography Realm's history of the genre describes it, was applying the same equal-value-line idea to travel time instead of temperature or pressure. Other European mapmakers picked up the technique within a year or two, at city and continental scales alike — the only thing that has changed since is what counts as a travel mode.
How one actually gets built
The method is the same one behind every estimate on this site, described in more detail here: treat the road network as a graph of segments and intersections, compute the fastest path from the origin to every reachable point, and trace a boundary around the points that come in at or under the chosen number of minutes. TravelTime's isochrone API is a production example of exactly that — send an origin, a travel time and a mode, and it returns a polygon, with driving, cycling, walking and public transit (the last modelled from published timetables rather than estimated from road speeds) supported out to four hours. It can also take more than one origin and union or intersect the resulting shapes — more flexibility to combine destinations than a typical single-address commute filter offers.
What the boundary doesn't tell you
An isochrone map answers “roughly where, geographically, should I even be looking” — and for an unfamiliar metro, that is a genuinely useful first question; the full comparison of commute-search tools says so plainly. What it does not do is show you a single home. The polygon is the answer, and finding out what is actually for sale inside it is a separate step in a separate tool.
It also can't distinguish within itself. A point 6 minutes from the origin and a point 29 minutes from it both just sit inside the same 30-minute boundary — the line tells you in or out, not how comfortably, which is the same gate-not-a-score limitation portal commute filters have for a different reason. And every isochrone, however it's built, inherits the same honesty problem as any other travel-time estimate: it describes a typical trip on an ordinary day, not the specific Tuesday you would actually be driving.
Turning the blob into a shortlist
The useful move is to use an isochrone for what it's good at — a first pass at an unfamiliar area — and then switch tools for the part it can't do. On the map, the same travel-time-from-a-point idea runs against actual for-sale inventory and against more than one place at once, with every home scored rather than just gated in or out. Start from homes for sale by commute time if that's the question you actually have.