# Refreshing the Travel-Time Map Behind Lyft's Marketplace: Rebuilding Neighborhood Reachability...

DevFeed: [Refreshing the Travel-Time Map Behind Lyft's Marketplace: Rebuilding Neighborhood Reachability...](<https://devfeed.tech/articles/refreshing-the-travel-time-map-behind-lyft-s-marketplace-rebuilding-neighborhood-reachability-1241.md>)

Original publisher: [Read original article](<https://eng.lyft.com/refreshing-the-travel-time-map-behind-lyfts-marketplace-rebuilding-neighborhood-reachability-5be3efbc82ea?source=rss----25cd379abb8---4>)

Author: Manjunath Shettar

Published: 2026-09-10T16:12:28Z

Content type: article

Language: en

Sources: [Lyft Engineering - Medium](<https://devfeed.tech/sources/lyft-engineering-medium.md>)

Topics: [dataset](<https://devfeed.tech/topics/dataset.md>), [airflow](<https://devfeed.tech/topics/airflow.md>)

Tags: [airflow](<https://devfeed.tech/tags/airflow.md>), [data-processing](<https://devfeed.tech/tags/data-processing.md>), [feature-engineering](<https://devfeed.tech/tags/feature-engineering.md>), [latency](<https://devfeed.tech/tags/latency.md>), [lyft](<https://devfeed.tech/tags/lyft.md>), [offline](<https://devfeed.tech/tags/offline.md>), [tea](<https://devfeed.tech/tags/tea.md>)

## AI overview

Lyft describes rebuilding its Neighborhood Reachability Signals: offline, regional travel-time matrices between geohash-6 cells and their associated neighborhood-center lists. The refresh replaces older static data and is intended to support marketplace pricing, driver guidance, and demand heatmaps, with future work aimed at time-aware travel times.

## Source excerpt

Refreshing the Travel-Time Map Behind Lyft's Marketplace: Rebuilding Neighborhood Reachability Signals Every time Lyft calculates pricing to balance a market, nudges a driver toward an under-served pocket of a city, or paints a heatmap of where demand is building, there is a quiet lookup table doing work in the background. It answers a deceptively simple question: how long does it take to get from here to there?, for millions of pairs of places, across hundreds of regions. That lookup table is the Neighborhood Reachability Signal, and for years large parts of it were frozen in a snapshot of the world from 2018-2019. This is the story of how we rebuilt it, why a refresh substantial enough to be worth adopting was what finally moved Pricing to switch, the cleanly positive results that came out of that switch, and where we're taking it next, from one static file per region to time-aware travel times that change with the rhythm of the day. What is a Neighborhood Reachability Signal? A geohash is a compact way of carving the world into a grid of cells. At geohash-6 resolution, each cell is roughly the size of a few city blocks. Slice a region into geohash-6 cells and you get a clean, discrete coordinate system for "neighborhoods" that downstream systems can reason about. The Forecasting & Real-Time Optimization (FORTOP) team produces the Neighborhood Reachability Signals dataset, which consists of two companion files for each region: Neighborhood Reachability Matrix: the estimated travel time, in minutes, between the centers of pairs of geohash-6 cells. Think of it as a sparse origin-to-destination travel-time matrix for a region. Neighborhood Centers: the list of all geohashes that appear in the ETA files for that region, i.e. the "vocabulary" of cells that the marketplace is allowed to talk about. Both files are generated offline on a schedule by an Airflow DAG. They are static in the sense that they are precomputed and shipped, rather than queried live (which is exact