Osmosis
Improved BMTC system - Shows realtime bus routes - Prevent petty thefts from conductors incorrectly ticketing a different stop - Improve analytics, and hence route planning - Riders can go cashless
The problem Osmosis solves

Objectives Here are the numerous issues the BMTC faces which Osmosis will fix.

  • Consumers do not know the real bus routes and timings because the provided schedules do not show bus movements in real time. The passenger's app shows realtime bus routes along, their respective passenger counts, and allow riders to go casheless.
  • Conductors make petty thefts by incorrectly billing the customer for a stop different from the one they asked for. Our near-foolproof system discourages passengers from exiting the bus before the conductor can scan their QR code, and prevent conductors from theiving by shifting the ticketing entirely to the application.
  • Negligent conductors cause for analytics to suffer, thereby making it difficult to effectively plan bus routes. So even users who lack smartphones will benefit from this new system because their routes will be optimized, and they'll pay flat fares.

For Passengers For BMTC passengers who need better bus systems, Osmosis is an app that prevents conductors from making petty thefts, provides real time bus routes, and provides cashless transactions. Unlike the existing BMTC app, our product saves time and money.

For Administrators For BMTC administrators who need to effectively plan bus routes, Osmosis is an admin panel that provides analytics such as heatmaps for identifying planning efficiency during rush hour, and charts for viewing trends. Unlike the current BMTC system, our product provides deep actionable insights from data that isn’t incorrectly collected from negligent bus conductors.

Challenges we ran into

Admin panel Using the Maps API was tricky. We switched to Mapbox in the end, and had a success in a much shorter amount of time. Conductor's and Passenger's App Dealing with HTTP request issues such as CORS, and the incorrect handling of PATCH requests, etc. from the window.fetch API. We dealt with it by modifying all API endpoints to use HTTP GET instead. Backend Choosing the optimal host (e.g., AWS, Heroku, local, ngrok) was a tough choice. We picked ngrok at the end because it is not difficult to set up like an IaaS is, is not limited to using orthodox setups of highly popular technologies like a PaaS, and doesn't insecurely and inefficiently expose the local web server.

Begin a conversation

Sign in or create an account on Devfolio to post a comment.