Case study
Origin–destination matrices from smart-card data for Bogotá's BRT and bus network
About 3.8 million validations on a weekday (13 Feb 2026) turned into origin–destination matrices, load profiles and service indicators: ~68 % chained to a destination before expansion, 97–99 % after it, in about 15 minutes a day at near-zero marginal cost.
| Organisation | TRANSMILENIO S.A., Dirección Técnica Zonal |
|---|---|
| Sector | Public transport (BRT and zonal bus network, Bogotá) |
| Period | 2024–2026 |
| Team | Methodology and original pipeline by researchers at Universidad de los Andes and TRANSMILENIO S.A. |
| Stack | R · SQL · GCP BigQuery · Parquet |
Summary
Bogotá's fare-collection system records where a passenger boards, not where they get off. This pipeline infers the destination of about 3.8 million validations on a weekday (13 Feb 2026) and expands the result into origin–destination matrices, load profiles and service indicators that the planning team uses for new routes, weekend redesigns and daily dispatch. It runs on GCP BigQuery in about 15 minutes end to end at near-zero marginal cost. The method and the original pipeline come from a Universidad de los Andes research group; with Alejandro Palacio I maintain and extend it.
Context and problem
TRANSMILENIO S.A. is the authority that manages Bogotá's BRT trunk lines and its zonal bus network (SITP). Every boarding produces a smart-card validation; there is no tap-out, so the raw data answers "where do people get on" but not "where do they go" — and planning questions (which routes to add, how to redesign weekend service, how many buses to dispatch on which corridor) are questions about trips, not boardings.
An O-D matrix estimated from the validations was the missing input. It had to be produced every day, for every stop and route in the network, from a data volume that is small for a warehouse and large for a laptop.
Constraints
- Data. Boardings only; destinations have to be inferred. Card-level data never appears in any output: results are aggregated by zone, stop and route.
- Team. Two people, alongside the authority's own planning team.
- Codebase. An inherited R pipeline with a working method. The job was to make it reliable and extend it, not to rewrite it.
- Cadence and cost. One run per day, on BigQuery, with a marginal cost close to zero.
Use
The outputs feed three decisions at the authority: planning of new routes, the redesign of weekend routes, and daily dispatch.
My role
I have maintained and extended the pipeline: bug fixes and precision improvements in the chaining and expansion stages; the quality-control layer; changes in data inputs; historical backfills of new versions; and the new outputs.