The problem Apollo solves

Transit for masses currently sucks. Since humans plan the routes, changing them is slow, expensive, and impossible to modify on a day-to-day basis. Since Apollo is a program, it can easily be used to generate the most optimal routes on demand. Usually, both students and administrators had unnecessary inefficiencies for days such as when only a particular part of the school wasn't using the bus (e.g., on a day in which only middle school children have exams). Now, the institution doesn't need to waste fuel on partially empty vehicles, the drivers don't need to waste time figuring out who they have to wait to pick up or drop off on a particular day, and the passengers needn't take meaninglessly longer trips.

Implemented Features

• Buses only go to the nearest stop on the main road, which saves the driver the hassle of figuring out how to drive as close as possible to the pick-up/drop-off point without significantly wasting the other passengers' time.
• Outliers will be highlighted (i.e., people who live ridiculously far away) to help aid in human intervention.
• Passengers and their family members can track where the passenger is while the passenger is in the bus (i.e., GPS and ETA). Since buses are tracked, it will be known how long it’ll take for the bus to reach the school in the afternoon (in case the bus has to first travel to the school that day before it even starts its actual journey).

The Future of Apollo

• Since it's common for institutes to rent vehicles, they'll have the ability to specify the transport sizes they have available.
• If human intervention was used to move a person's programmatically chosen position, it would be saved so that when routes are regenerated, the moved points are'nt lost.
• Time should be factored in as well. Every bus should start from a decent time (i.e., not one from two hours before all the others).

Challenges we ran into

• Frontend: Drawing on the map (lines are complicated to draw efficiently)
• Backend: Difference between (e.g., CORS issues, difference in the way HTTP clients handle certain HTTP status codes)