How the data is built

TravelTime Data API is a data product. Before you build against the API it's worth understanding what you're actually getting and where it comes from. The pages in this section answer the questions customers ask in their first hour of evaluation.

What's in this section

Points of interest — how we merge three independent POI sources into one consolidated layer, what "cross-validated" means, and how the source-count signal helps you trade precision against recall. Read this before you decide which min_sources filter to use.

Public transport — where our station and line data comes from (it isn't raw GTFS), how stops get clustered into stations, and what counts as a "trip" in our frequency rollups. Read this before you query the transport endpoints.

Green space and polygons — what counts as a park or open space, how the polygon classes work, and how we compute "reachable area" inside an isochrone. Read this before relying on land-cover area numbers.

Population & areas — population, census demographics, and transit coverage projected onto H3, plus the administrative-boundary hierarchy (the Areas API). Read this before building catchment analytics or filtering by admin area.

Environment — noise, air quality, flood risk, deprivation, broadband and crime on H3. Read this before using any of them: the sources are coarser than a cell, and coverage varies by nation, so null carries meaning.

Freshness and versions — how often the per-country dataset rebuilds, what changes between rebuilds, and how to tell when a snapshot has rolled over. Read this before you cache anything client-side or commit to an SLA.

A note on country scoping

Everything in this section is described against a single country at a time. POI sources, the transport graph, polygons, and freshness all operate per-country — we keep a separate dataset for each ISO country code we support, and queries never silently span them. The list of supported countries comes from GET /v1/countries in one call, and Countries & coverage shows the same list with the datasets behind each; a production app should send country=<cc> on every request and treat unsupported countries as a hard error.

A note on what "ingest" looks like

You may see references in some pages to a "build pipeline" or a "rebuild". That's the back-office process we run periodically that downloads raw source data, runs the matching and aggregation logic, and writes the per-country dataset the API reads. From a customer's perspective, the result is a sealed, read-only snapshot: it doesn't change in flight, and a single API response is internally consistent. The freshness page covers when those snapshots roll over.