Red Regional

Projects | 2025 | Links:

Red Regional brings trip planning and transport information to regional public transport systems across Chile. It’s provided by the División de Transporte Público Regional (DTPR).

Red Regional is a single, configurable application and service that brings trip planning, local schedules, and modern payment options to towns and provinces across Chile outside Santiago. Run by the División de Transporte Público Regional (DTPR), the app adapts its behaviour through per-region configuration and operator adapters while keeping a common codebase and a shared prediction engine. The DTPR coordinates with local transport authorities to modernize payments and provide consistent trip information across regions.

How it works

Red Regional is intentionally modular and runs as a single application that is configured per region. The app consumes the local GTFS feeds and operator metadata, applies lightweight normalization, and (when available) merges any telemetry to provide stop-level arrival predictions and a familiar trip planner UI.

Because regional systems vary widely in data quality and payment infrastructure, the product relies on a per-region configuration layer that enables or disables features (e.g., top-ups, QR payments) and tunes predictor sensitivity. This approach lets a single codebase adapt behavior and integrations for each region without maintaining separate builds.

Challenges

Regional deployments bring a different set of constraints than a single-city product. Key challenges we solved included:

• Heterogeneous GTFS feeds and inconsistent identifiers — we built adapters and validation steps to normalize calendars, stop IDs and operator mappings so the planner and prediction layers could operate reliably across regions.
• Partial or intermittent telemetry — many regional networks do not provide continuous vehicle telemetry. We implemented a lightweight predictor that falls back to schedule-based estimates when live data is sparse, and uses conservative smoothing when telemetry is available to avoid misleading ETAs.
• Diverse payment systems — some regions supported modern QR or top-up channels while others relied on operator-managed balances. We designed pluggable payment adapters so each region could connect to local providers without bloating the core app.
• Operational complexity across regions — to keep releases maintainable we created tooling for per-region configuration, automated staged rollouts, and feature gates to reduce manual steps and the risk when enabling region-specific features.

Key learnings

• Reuse beats duplication: a single, well-tested prediction core with clear configuration hooks made it feasible to support many regional variants without maintaining multiple codebases.
• Data normalization is essential: investing in robust GTFS adapters and validation tooling prevented many downstream issues and made predictions more dependable.
• Feature gating and staged rollouts are critical when working with heterogeneous operators — they let us iterate safely and reduce the blast radius of payment or prediction changes.
• Designing for failure modes (missing telemetry, flaky networks) improves perceived quality more than chasing marginal algorithmic gains.

Tech stack

• Flutter for the mobile clients.
• Mapbox for maps and rendering.
• Backend services for GTFS transforms, prediction engines and region-specific APIs.
• Firebase for analytics and remote configuration; lightweight push infrastructure for notifications.

Conclusion

Red Regional was a lesson in engineering for diversity: different operators, networks and payments meant solutions had to be adaptable, testable and operationally simple. The project sharpened skills in data normalization, modular architecture, and pragmatic prediction engineering — delivering usable, accurate transport information to communities where reliable mobility data is often scarce.