Drive-time trade areas: tools that use traffic patterns and census demand

Because it follows roads, the shape stretches down highways and stops at rivers, ramps, and dead ends. A radius treats a mile to the north and a mile across a freeway as the same distance. A drive-time polygon does not, which is why two sites with identical three-mile rings can reach very different numbers of people.

Traffic moves the boundary by the hour. The same ten-minute drive covers a lot less ground during a morning crush than at mid-morning, and a peak contour can shrink by close to a third in a congested corridor. A trade area built on free-flowing speeds will overstate reach for any business whose customers arrive at rush hour, so the departure time you model is part of the answer, not a footnote.

Tools that produce drive-time polygons fall into two broad groups, and they solve different halves of the problem. Routing and isochrone APIs are built to compute travel time across a network, often with live or historical traffic, and they return the polygon as geometry. That is the entire deliverable. The shape is accurate, and it arrives empty.

GIS and site-selection tools start from a polygon, whether they draw it themselves or take one from a routing engine, and then they attach what lives inside it. That is where census population, daytime workers, household income, category spend, and competitor locations enter the picture. Desktop GIS gives you the most control and assumes you bring the analyst. A site-selection platform packages the same geography and data into a scored, exportable output without the GIS seat.

On the routing side, Mapbox Isochrone can build contours from its driving-traffic profile and accepts a departure time so the polygon reflects expected congestion. INRIX Drive Time produces traffic-aware polygons from a large probe-data fleet, and TravelTime and HERE offer similar isochrone endpoints. These services are a good fit when you need the shape and plan to do your own analysis on top of it.

On the GIS and site-selection side, Esri can generate drive-time, walk-time, and polygon trade areas and then enrich them with demographic and business data, and Maptitude builds drive-time rings alongside hundreds of demographic variables. These tools answer the question the routing APIs leave open, which is who and what sits inside the polygon, in exchange for more setup and more expertise.

Traffic-aware routing engines bake congestion in through a departure-time parameter, often called depart_at, that tells the engine when the trip starts. With a time set, the engine uses typical speeds for that day and hour rather than open-road speeds, so a contour generated for an evening commute is tighter than one generated for a quiet Sunday. Without a departure time, you are usually modeling free flow, which flatters every site.

There are practical limits worth knowing before you wire anything up. A single isochrone request typically returns a handful of contours and caps the maximum travel time. Mapbox, for example, returns up to four contours per request and limits travel time to 60 minutes, so a five-band study or a 90-minute regional area means stitching multiple calls together.

The standard method intersects the drive-time polygon with census geography, usually block groups, and apportions each block group by the share that falls inside the boundary. That yields resident population, and you can layer on daytime population for lunch and commuter formats, household income, and modeled category spend. Then you add competition by counting and locating the relevant points of interest inside the same polygon, which is what separates a reachable market from a contested one.

Doing this by hand in a GIS is accurate and slow, and it has to be repeated for every candidate and every departure time. A site-selection platform runs the intersection, the apportionment, the demographics, and the competitor lookup as one pass, and keeps the data vintage attached so each figure carries a source and a date.

Some routing providers suggest scheduling a typical weekday commuting slot a couple of weeks ahead so the engine uses normal conditions, for instance a mid-morning peak or a late-afternoon one. That guidance translates into a few choices you can make for any study:

• Match the daypart to your format. A lunch quick-service brand cares about the noon rush, while grocery and fitness see customers on the evening commute.
• Pick an ordinary weekday and avoid holidays, school breaks, and event days that push traffic far from typical.
• When a decision is close, model both an off-peak and a peak departure and compare the demand inside each so you can see how sensitive the site is to congestion.

Geod sits a layer above the routing engine. It computes time-aware drive-time and walk-time isochrones, then rolls census demand, competition, and cannibalization against your own network into an explainable site brief, with every figure traced to a source and a snapshot date. The score breaks into components you can read and challenge in committee.

Geod is not a raw isochrone API or a traffic-data provider. If all you need is the polygon to feed your own pipeline, a routing service like Mapbox or INRIX is the better buy. If you need the polygon plus the demand and competition inside it plus a brief you can hand to a real estate committee, that is the gap Geod is built to close.