Córdoba Connect: Smart Multimodal Mobility

Plan trips across Córdoba by combining AUCORSA buses, local rail, cycling and walking. Compare door-to-door options and choose the fastest route for every journey.

Comment

Inspiration

Getting across Córdoba should not require checking several apps, interpreting different timetables and having to memorise the bus journeys or resigning to walking. This is especially inconvenient for recurring journeys such as commuting to work or university. The fastest option can change depending on the departure time, waiting time and distance to the nearest stop, not merely the time spent inside a vehicle. Sadly Google Maps or other apps sometimes misses Aucorsa bus connections due to misconfigurations or wrong timetables, which makes it so frustrating trying to find your way around the city. I built Córdoba Connect to bring those choices together in one clear, door-to-door experience designed specifically for Córdoba.

What it does

Córdoba Connect is a bilingual Android mobility companion that compares AUCORSA buses, Renfe Proximidad services, walking and cycling. The user selects an origin and destination using address search or their current location, chooses whether to leave now or at a specific time, and receives practical journey alternatives. Each result includes:

  • Total trip duration and arrival time.
  • Walking, waiting and in-vehicle time.
  • Transfers, stops, operators and service headsigns.
  • A map with separately styled walking, bus, rail and cycling segments.
  • Fare notices when a journey may require separate tickets or transfers.
  • Walking or cycling recommendations when active mobility is competitive with public transport. Frequently used journeys can be saved as workday or weekend commutes. They remain available through encrypted local storage, while optional Firebase synchronization stores them under an anonymous per-installation identity. The interface is available in both English and Spanish.

How I built it

The Android application is written in Kotlin using Jetpack Compose and Material 3. Google Maps and Places provide address selection, location search and route visualization. The mobile app does not communicate with the routing engine directly. Instead, it uses a FastAPI service that validates journey requests and exposes a stable API contract. FastAPI then queries OpenTripPlanner, which calculates routes using an OpenStreetMap extract of Córdoba together with prepared AUCORSA and Renfe GTFS datasets. This separation keeps the Android client independent of OpenTripPlanner’s GraphQL response format and makes routing rules, validation and provider-specific behavior testable outside the app. Saved journeys use Room and SQLCipher, with encryption material protected by Android Keystore. Firebase Anonymous Authentication, Firestore security rules and Firebase App Check provide optional cloud synchronization without making Firebase the app’s only source of data. The complete routing stack is containerized and can be reproduced locally with Docker. The repository includes scripts for preparing OpenStreetMap and GTFS data, building the OpenTripPlanner graph, starting the backend and validating both Android and Python code in CI.

How I used Codex and GPT-5.6

I used Codex with GPT-5.6 as an engineering collaborator across the Android app, backend, routing infrastructure and deployment workflow, not simply as code autocomplete. I supplied Codex with build failures, application logs, screenshots and real route-planning examples. It helped me inspect the existing prototype, reduce it to a coherent hackathon product and iterate across multiple layers of the system. GPT-5.6 was particularly valuable for reasoning about problems that crossed component boundaries. Examples included:

  • Designing a stable FastAPI contract between Android and OpenTripPlanner.
  • Interpreting OpenTripPlanner itineraries and keeping transfers, tickets and fare validations as separate concepts.
  • Correcting departure and arrival ordering so the fastest result reflects the complete journey.
  • Diagnosing differences between emulator, physical-device and release networking.
  • Configuring HTTPS release endpoints without embedding credentials.
  • Adding encrypted local persistence and resilient Firestore synchronization.
  • Troubleshooting Firebase Authentication and App Check restrictions.
  • Localizing the interface into English and Spanish.
  • Repairing Gradle and GitHub Actions failures and adding repeatable validation. I also used Codex to challenge implementation decisions rather than accepting the first solution. This led to a local-first data model, an explicit API boundary and honest handling of transport data limitations. Córdoba Connect does not call an LLM at runtime. Journey calculation remains deterministic and reproducible through OpenTripPlanner. GPT-5.6’s role was to accelerate and strengthen the engineering process behind the product.

Challenges I ran into

The hardest part was not drawing routes on a map, but making heterogeneous transport information understandable and trustworthy. The available AUCORSA GTFS snapshot had expired. Instead of silently presenting it as current or claiming real-time arrivals, I created a separately identified weekly projection for the prototype. The app clearly operates with scheduled data only. Replacing this projection with a refreshed official feed is an important next step, but requires close collaboration with AUCORSA. Another challenge was interpreting multimodal itineraries correctly. Transfers do not always correspond directly to tickets, and some consecutive AUCORSA legs may require another validation even when the routing engine does not report a conventional transfer. Release networking also required additional work. Local HTTP is convenient during development, but an installable release needs an HTTPS backend and carefully separated build configuration. Testing on an actual Android device exposed issues that were not visible in the emulator, including endpoint selection and resolving “My location” into a useful address before saving it.

Accomplishments that I’m proud of

I am proud that Córdoba Connect became a coherent, working product rather than an isolated routing demonstration. It now combines:

  • A complete Android experience with map-based results.
  • Real multimodal calculations through OpenTripPlanner.
  • A stable and tested backend API.
  • Encrypted offline saved journeys.
  • Optional protected Firestore synchronization.
  • English and Spanish interfaces.
  • Docker-based, self-hostable infrastructure.
  • Automated Android and backend validation. I am especially proud of treating data quality as part of the user experience. The application does not describe scheduled information as real time, and the repository documents the provenance and limitations of the transport data.

What I learned

I learned that a mobility app is as much a data and infrastructure project as it is a user-interface project. A polished screen is not enough if route timing, service calendars or transfer semantics are misleading. I also learned how valuable an AI coding agent becomes when it can work from concrete evidence: failing tests, logs, screenshots and reproducible examples. The most useful GPT-5.6 interactions were not requests to generate an entire feature, but iterative investigations where the model could connect behavior across Android, Python, Docker, Firebase and cloud networking.

What’s next

The next milestone is deploying the backend to a stable public HTTPS endpoint and replacing the projected AUCORSA calendar with a continuously refreshed official feed. I would also like to add:

  • Real-time disruption and arrival information when reusable official data is available.
  • Optional account sign-in for restoring journeys across installations and devices.
  • Accessibility and mobility-aware routing preferences.
  • Saved-commute notifications and departure reminders.
  • More regional transport providers and bicycle infrastructure information.
  • Public distribution through Google Play and a migration to Flutter or similar to support iOS. The long-term goal is for Córdoba Connect to become a transparent, locally focused mobility layer that helps residents choose the most practical and sustainable option for every journey.

Built With

Share this project:

Updates