An isochrone map is a polygon that answers a deceptively simple question: where can I get to from here in X minutes? Draw a 15-minute drive-time isochrone around a coffee shop and you have its real-world catchment. Draw a 30-minute walk-time isochrone around a metro station and you have its pedestrian reach. Every "near me" feature, every store catchment study, every commute-time real estate filter is built on this idea.
This guide explains what an isochrone really is, how isochrones are computed on the road network, where they show up in production systems, and which pitfalls cost teams time and money.
What an Isochrone Really Is
The word comes from the Greek isos (equal) and chronos (time): a curve along which the travel time is the same. In modern mapping, an isochrone is a polygon (or a set of nested polygons) representing every location reachable from an origin within a chosen time budget, given a chosen travel mode.
Two things make an isochrone different from a simple buffer. First, it is computed on the road network, not on a flat plane. Rivers, motorways, mountains, and one-way streets all distort the shape. Second, it is mode-aware: a 20-minute drive isochrone, a 20-minute cycle isochrone, and a 20-minute walk isochrone from the same point are three completely different polygons.
The output is almost always GeoJSON, with a Polygon or MultiPolygon geometry and properties carrying the travel-time threshold and the mode. That is what your front-end map renders and what your spatial database queries against.
How Isochrones Are Computed
The naive approach is to run a shortest-path search from the origin and stop when the cumulative travel time hits the threshold. In practice, that is too slow at scale, so production systems use precomputed road-network graphs and accelerated search algorithms.
The road graph is built once from a source like OpenStreetMap or a commercial road dataset: every intersection becomes a node, every road segment becomes an edge weighted by travel time for each mode. From an origin, a graph search (Dijkstra, A*, or a bidirectional variant) walks outwards, expanding the cheapest unvisited node first, until the time budget is exhausted. The set of reached nodes plus the partially-reached edges defines the boundary.
Modern engines use contraction hierarchies or related techniques to make this fast. The graph is preprocessed into a hierarchy where shortcut edges skip over less important nodes, so a query that would otherwise touch millions of edges can be answered in milliseconds. The reachable nodes are then wrapped into a polygon, usually with a concave hull or alpha-shape so the outline hugs the actual road extent rather than ballooning out into empty space.
The result is a GeoJSON polygon you can stream straight to a Leaflet, Mapbox GL, or MapLibre map, or load into PostGIS for spatial joins.
Where Isochrones Show Up
Isochrones are quietly powering a lot of location-aware product features.
- Store and venue catchments: retailers draw drive-time isochrones around each location to estimate the population they reasonably serve, then overlay census or spending data to size the market
- EV range planning: battery-aware isochrones show how far an EV can drive on its remaining charge, factoring in elevation, speed, and consumption
- Real estate commute filters: "show me every flat within a 30-minute commute of this office" is an isochrone intersected with a property listings table
- Healthcare access analysis: planners compare isochrones around hospitals and clinics with population grids to find underserved areas
- Logistics service areas: couriers, field-service teams, and on-demand delivery platforms use isochrones to define which orders they will accept from a given depot
- Urban planning and transit: 15-minute-city studies, station catchment plans, and accessibility audits all run on multimodal isochrones
In each case, the isochrone is the spatial filter. It turns a vague question ("how close is close enough?") into a polygon you can intersect, render, and reason about.
Pitfalls in Production
Isochrones look easy in a demo and get harder in production.
Mode mismatch. A drive isochrone uses motorway speeds and ignores one-way restrictions for pedestrians. A walk isochrone uses footpaths and pedestrian shortcuts that cars cannot use. Mixing the two is the most common source of "the polygon looks wrong" bug reports. Always pass the explicit mode and surface it in the UI.
Time of day and traffic. A 15-minute drive at 03:00 covers a far larger area than the same 15-minute drive at 17:30. If your use case is commute-aware (real estate filters, store hours, dispatch), pass a departure_time and use a traffic-aware engine. Static isochrones lie about rush hour.
Multimodal stitching. Real journeys combine modes: walk to the metro, ride two stops, walk to the destination. Naive single-mode isochrones miss this entirely. True multimodal isochrones require a transit timetable and a graph that joins pedestrian and transit edges, which is significantly more complex than drive-only.
Coverage simplification. Some engines aggressively smooth the polygon to make it look pretty, which silently overstates coverage by including areas no road actually reaches. For decisions that matter (opening a store, accepting a delivery zone), inspect the raw boundary rather than trusting the rendered shape.
Polygon size at scale. Long-duration isochrones (60, 90 minutes) can have tens of thousands of vertices. Simplify before sending them to the browser, or render server-side, or your map will stutter.
Isochrones in MapAtlas
The MapAtlas Isochrone API returns drive, walk, cycle, and traffic-aware drive-time polygons as GeoJSON, with support for multiple time thresholds in a single request and departure-time inputs for traffic-aware results. Polygons are computed on a continuously updated road graph and returned in a shape your map library can render without further processing.
For workflows that need both reachable-area polygons and pairwise travel times, the Isochrone API pairs with the Distance Matrix API so a single workflow can answer "where can I reach in 20 minutes?" and "rank these candidates by drive time" in one pipeline.
An isochrone is, in the end, just a polygon. But it is the polygon that turns travel time into a shape your application can filter, render, and reason about, and it is the difference between a true commute-aware feature and a circle drawn around a pin.
Frequently Asked Questions
What is an isochrone map?
An isochrone map is a polygon, or a set of nested polygons, showing every place reachable from a starting point within a given travel time. A 15-minute drive-time isochrone around a store, for example, traces the shape on the map that contains every road segment a customer can reach in 15 minutes or less. The shape is almost never a circle because real road networks have rivers, motorways, dead ends, and one-way streets.
How is an isochrone different from a radius?
A radius is a straight-line buffer drawn with a compass: every point inside is the same crow-flies distance from the centre. An isochrone is a travel-time buffer computed on the actual road network: every point inside is reachable within the same number of minutes. A 10 km radius and a 10-minute drive-time isochrone almost never match because terrain, motorways, and traffic distort the shape.
What does an isochrone API return?
An isochrone API returns one or more polygons as GeoJSON, each tagged with the travel-time threshold it represents (5, 10, 15 minutes, for example). The polygons are computed on the road graph for a chosen travel mode (drive, walk, cycle, transit) and can be returned for a specific departure time when traffic is taken into account. You drop the GeoJSON straight onto a map or use it as a spatial filter in PostGIS.
Why do isochrones look so jagged?
Isochrones are derived from a graph of road segments, not from a continuous surface. The polygon boundary is interpolated from the furthest reachable nodes within the time budget, so the edges follow the road geometry. Smoother shapes can be produced with concave hulls or alpha shapes, but a slightly jagged outline is honest: it shows where the network actually ends, not where a smoothing function imagined it would.
