The Problem With TAZ Polygons in Transit Analysis
Traffic Analysis Zones have been the standard spatial unit for transportation planning in the United States since the urban transportation modeling studies of the 1950s and 60s. TAZs are defined by MPOs and state DOTs as part of the urban transportation planning process, and they appear in every four-step travel demand model from here to Anchorage. They're not going away, and we're not arguing they should.
But TAZs carry an inherited problem: their boundaries were drawn primarily for vehicle trip generation and attraction modeling, and they tend to follow administrative geography — census tracts, census block groups, municipal boundaries, neighborhood association lines. In dense urban cores, TAZs can be quite small (a few blocks). In suburban and exurban areas, a single TAZ might cover several square miles. The result is a spatial unit whose resolution varies dramatically across the study area and whose boundaries encode political and administrative history, not actual travel behavior.
For transit analysis specifically, this creates three concrete problems:
- Resolution mismatch: A TAZ covering 1.2 square miles in a suburban fringe area might contain three bus stops, a park-and-ride lot, and two distinct residential neighborhoods with very different propensities for transit use. Averaging demand across the entire TAZ loses the within-zone variation that matters for stop placement and route alignment decisions.
- Boundary artifacts: When a high-demand corridor crosses a TAZ boundary, analysis that aggregates to the TAZ level can split the corridor demand across two zones and obscure the linear pattern entirely. Worse, if the boundary coincides with a jurisdictional boundary (city limit, county line), the split may make the corridor look like two distinct low-demand areas rather than one high-demand through-movement.
- Inconsistent adjacency: TAZ polygons are irregular in shape, which means adjacency relationships are inconsistent. Spatial joins and neighborhood analysis — finding all zones adjacent to a given zone — produce different effective neighbor counts for different zones, complicating any analysis that depends on spatial proximity.
What H3 Offers Instead
Uber's H3 is a hierarchical hexagonal spatial indexing system developed primarily for internal routing and demand analysis, open-sourced in 2018. The key properties for transit demand analysis:
Uniform cell area at a given resolution. At resolution 8 (the resolution we use for most transit demand work), every H3 cell covers approximately 0.74 km² — consistently, everywhere. A cell in downtown Austin covers the same area as a cell in the suburbs. This is a fundamentally different property from TAZs, and it matters enormously for cross-area comparisons. When you say "this corridor has elevated demand," you mean the same thing whether the corridor runs through downtown or through a suburban transfer center.
Hexagonal geometry eliminates directional bias. Square grid cells have two neighbor distances — cardinal (touching edge to edge) and diagonal (touching corner to corner). This introduces directional bias in any analysis that uses spatial neighbor relationships. Hexagonal cells have only one neighbor distance: every adjacent cell shares an equal-length edge with every other adjacent cell. For demand surface modeling — where we're drawing isodistance rings around transit stops and corridors — this property removes a systematic analytical artifact.
Hierarchical indexing enables multi-resolution analysis. The H3 hierarchy is compact: each resolution-7 cell contains exactly 7 resolution-8 cells. This makes it straightforward to aggregate up (combining stop-level demand into corridor-level demand) or disaggregate down (allocating route-level ridership to stop catchment areas) using consistent spatial units throughout. The same analysis workflow handles both regional pattern recognition and stop-level micro-analysis without changing spatial frameworks.
A Concrete Comparison: Identifying an Underserved Corridor
Here's a scenario that illustrates where the two approaches diverge. Consider a transit authority analyzing a candidate corridor for bus rapid transit investment — a 4-mile stretch running through a mixed-use area that spans three TAZs. The corridor crosses a TAZ boundary midway through, and that boundary happens to coincide with a municipal boundary from the 1990s that has been meaningless on the ground since the area was fully built out. Two of the three TAZs are large (suburban-era geometry), one is smaller (urban core).
In a TAZ-based analysis, the corridor appears as two distinct pieces. The larger suburban TAZ shows moderate trip generation rates, but the zone is so large that the demand is diluted spatially — the per-area demand density looks unremarkable. The smaller urban TAZ shows higher density but covers only a portion of the corridor. The three-zone picture doesn't cleanly map to the actual movement pattern.
In H3 resolution 8 analysis of the same corridor, the cells along the 4-mile alignment have consistent area (0.74 km² each). You can directly compare boarding demand per cell across the full corridor length. The mixed-use area at the midpoint — which is where both residential and employment density peaks — shows up as a cluster of high-demand cells that cuts across the TAZ boundary cleanly. The spatial pattern of demand is visible; the administrative boundary is irrelevant.
We ran this type of analysis on actual GTFS ridership and LEHD employment data for a mid-size Sun Belt metro and found three corridors where TAZ-based screening had missed concentrations of demand that were clearly visible in H3 resolution 8 aggregations. The corridors had been deprioritized in the previous LRTP cycle partly because the TAZ data didn't surface them as high-demand.
Limitations Worth Being Honest About
We're not saying H3 is perfect or that TAZs have no value. TAZs remain appropriate for four-step travel demand models that are calibrated and validated against TAZ-level trip tables — those models have their own methodological lineage that isn't broken by spatial aggregation at the TAZ level. For regional traffic forecasting, the TAZ framework is the right tool.
H3 also doesn't solve data quality problems. A hex grid applied to sparse APC data or incomplete GTFS coverage produces a spatially clean but analytically misleading picture. The quality of the demand surface is bounded by the quality of the underlying feed data, regardless of what spatial unit you use for aggregation. Agencies with intermittently operating APCs, missing GTFS trip updates, or bike-share feeds that go stale for days at a time will see those data gaps reflected in the H3 demand surface.
And H3 demand surfaces don't replace field observation and community engagement. A hex cell showing high demand density is an indicator that something needs attention — it's the beginning of a planning conversation, not the end of one. Route alignment decisions that affect communities require community input; demand surface analysis provides quantitative foundation for that conversation, not a substitute for it.
Implementation: Resolution Selection and Edge Cases
The resolution choice matters and depends on what you're analyzing. Our general guidance:
- Resolution 8 (0.74 km² avg): Corridor-level demand analysis, network redesign screening, first/last mile gap identification. This is the workhorse resolution for most transit planning applications.
- Resolution 9 (0.105 km² avg): Stop-level catchment analysis, dwell time vs. demand correlation, pedestrian access shed modeling. Use this when you need to see variation within a single bus stop's walkshed.
- Resolution 7 (5.16 km² avg): Regional pattern recognition, MPO-scale equity analysis, multi-agency demand comparison. Resolution 7 is roughly comparable to a TAZ in a dense urban area — useful for regional summaries but not for route-level decisions.
One edge case to plan for: H3 cells that straddle jurisdictional boundaries. When two agencies contribute data to a multi-jurisdiction demand surface, cells at the boundary will contain data from both sources with different normalization factors. The H3 library handles the geometry correctly — the cell is the cell — but your analysis pipeline needs to track data provenance per cell and apply appropriate weighting when data sources have different reliability or coverage rates.
Where This Fits in the Planning Process
H3 demand surfaces are most valuable at the screening and scoping phase of a planning project — when you're trying to answer "where does demand actually concentrate in this region, and where is the network not currently serving it?" That's the phase where spatial resolution and analytical precision matter most, and where TAZ-based analysis tends to produce the most misleading results.
Once you've screened corridors and identified priorities using the demand surface, the downstream planning process — alternatives analysis, environmental review, community engagement, detailed service design — proceeds using the standard toolkit. The H3 demand surface doesn't replace that toolkit; it gives planners a better foundation for deciding where to focus it.