ArriveAble

What Inspired Me and What's Next for ArriveAble

Since starting university 5 years ago, I’ve seen so many changes in infrastructure, parking lots and walking trails, and have changed my walking path almost every semester. In that time, I’ve also met so many people with different mobility needs trying to navigate the unfamiliar campus through inaccessible entrances, stairs, poor lighting, buildings under renovation, long outdoor paths and parking rules. ArriveAble was inspired by the idea that the journey on-campus deserves the same care as the journey to campus. I wanted to make arrival planning more inclusive by recommending a fast, reliable journey that met the user’s needs: a starting location to a carpark or a transit stop, then to the building entrance and classroom. Of course, this can be scaled to larger areas, such as city parking. Many cities have live city parking occupancy data, so ArriveAble can be scaled globally.

What I Learned

I learned that accessibility navigation is a data-quality problem; different campuses publish information in very different forms and many sources, such as: live ArcGIS parking feeds, interactive maps, MazeMap POIs, PDFs, and OpenStreetMap geometry. I also learned the importance of transparency, and ArriveAble labels whether information is live, source-linked, mapped, estimated, provisional, or unavailable.

How I Built It and Accomplishments I'm proud of

ArriveAble is a lightweight web app built with HTML, CSS, JavaScript, Leaflet and a small Node.js API layer.

It uses a reusable campus-adapter architecture:

Web app
  ↓
Recommendation and API layer
  ↓
Cached campus adapters and route-data normalisation
  ↓
Official campus sources, MazeMap, OpenStreetMap and live parking feeds

The current prototype supports:

• Curtin University Bentley, James Cook University Townsville and Charles Darwin University Casuarina.
• Typed building and classroom destinations.
• Car, motorcycle, bicycle and on-campus public-transport journeys.
• Wheelchair/mobility, ACROD, permit, courtesy-bay and electric-parking preferences.
• Curtin live parking availability, where a reliable public feed is available.
• Source-linked parking costs and availability information.
• OpenStreetMap outdoor footway, cycleway, service-road, transit-stop and parking geometry.
• Official university maps and PDFs for accessible, free, permit and electric-parking classifications.
• Busy-period backup parking recommendations for Curtin.
• An optional weekly late-class safety planner.
• A mobile-navigation concept with terrain-aware, forward-looking alerts.

GPT 5.6 and Codex accelerated the implementation through iterative code generation, debugging, source-adapter design, UI refinement, local validation, and route-failure investigation. They were used to help translate product requirements into working features, diagnose incorrect routing and stale-result issues, and make data limitations explicit rather than presenting uncertain accessibility information as verified.

Challenges I Faced

The biggest challenge was actually getting the optimal path on-campus. Like mentioned before, public campus information and maps can be incomplete, live availability may not be available, and accessible parking may be labelled differently across official maps and OpenStreetMap. I addressed this by prioritising official campus information for parking eligibility and using OpenStreetMap for connected outdoor path geometry. Another challenge was handling live and static data together. Curtin can provide live parking utilisation, while JCU and CDU currently rely on mapped parking locations and official documentation. The app therefore treats each source differently and makes the source visible to users. Finally, I iterated on the interface so users can see a recommended route, a clear explanation, travel time, walk or roll distance, cost, availability, source links, accessibility context, and also provided a backup route with its own step-by-step instructions.

Built With

• codex
• gpt5.6
• openai