We counted Atlanta's missing data before writing a router

The question we get most often is some version of what's the secret algorithm? People assume accessibility navigation is a routing problem — that somewhere in our future is a clever graph search that solves wheelchairs the way existing apps solved cars.

It isn't. And before we wrote a line of routing code, we counted.

Routing is data-bound, not algorithm-bound

Open-source routing engines already ship wheelchair-aware costing. Valhalla has a wheelchair costing model. GraphHopper has one too. These are good engines, built by people who thought carefully about slope, surface, and sidewalk width — and they are starving.

Not for compute. For attributes.

An engine can only route around a missing curb cut if the map knows the curb cut is missing. It can only detour to a working elevator if the map knows which elevators exist, let alone which ones are broken today. The algorithm is a commodity. The attributes are the moat — and the attributes are what's missing.

The count

So we counted. We took the open map data for our launch region — metro Atlanta — and audited it the way a router would see it:

What a router needs	What the map has today
Sidewalk ways	~65,000
Ways with a surface tag	~17%
Ways tagged for wheelchair use	~2,600
Elevators, tagged, metro-wide	61

Sixty-one elevators, for a metro of six million people. Four out of five sidewalks have no surface data at all — a router can't know whether "this block" is smooth poured concrete or broken brick and loose gravel, because the map has no idea either.

This isn't a complaint about the volunteers who maintain open map data. It's a measurement of the gap between what accessibility routing requires and what anyone has collected. Nobody has collected it, because collecting it is the whole job — and the job hadn't been done.

Why reporting comes first

That count is why our roadmap runs backwards from what you'd expect. Phase one isn't navigation. It's the reporting flywheel that produces the data navigation will consume:

• People report what they experience — step-free entrances, ramp slopes, surface quality, whether the restroom actually fits a wheelchair, on a registry of about sixty accessibility features per place.
• Photos help, humans decide — image analysis can pre-fill a report, but community review is what confirms it.
• Reviews accumulate into scores — with confidence that grows with the number of independent voices behind them.
• Routing arrives when the data can carry it — the engines are already waiting; they'll get fed here first.

We released the first version of this platform in July, and our 0.7 release in late August rebuilt it around accessibility — venue pages, feature voting, community alerts, offline support. It is deliberately not turn-by-turn yet. The honest version of our progress looks like a map filling in, one reviewed place at a time.

Gated, not time-boxed

Our public launch target is 2027, and the gate for turn-by-turn routing is specific: enough verified attribute coverage in the launch region that a route drawn through it deserves your trust. We'd rather ship the router late than ship it confidently wrong — a confident wrong route is the exact failure mode our community already lives with on every existing map.

If you want to watch that coverage curve climb — or better, be one of the people who bends it — the waitlist is how we'll know which cities to open first.

Numbers above come from our own audit of the open map extract for the Atlanta launch region, August 2026. Open data moves fast; the gap is the point, not the exact decimals.