Inspiration
In a lot of places in the US, even ones with public transit available, there are often holes and gaps where it's not feasible to simply walk to the nearest stop or station. Georgetown is a prime example of this, with most of it being well over a mile away from the nearest Metro stop and even some distance away from the nearest Metrobus or Circulator stop. These kinds of gaps can easily be closed when commuters use bicycles in addition to transit, allowing for much quicker commutes while still getting all the same reductions in carbon emissions that leveraging public transit enables.
Despite this, however, there are currently no options on the market for commuters to plan routes that include both cycling and public transit. Anybody who wants to plan a route involving both of these modes of transit has to look at just public transit routes, then calculate themselves how much less time it'll take on bike. Furthermore, due to how much faster bicycles are than walking, this may not even produce the most optimal route.
There are certainly many people, particularly in the broader DC region, for whom a commute that involves bicycling and transit could serve to replace their car and reduce their individual impact on the environment. The fact that there isn't even the most basic of tools to plan a route, however, can serve to dissuade them from doing so. This is a challenge that we can certainly identify with, both in Gainesville, Florida as well as in the DMV, which prompted us to build a solution.
What it does
Mobike is a route planning application that helps bike commuters find multimodal cycling + transit routes, a feature that no other mapping application offers in the US. The user puts in their origin and destination, and receives a route that leverages their bicycle, as well as any local transit that may shorten their journey.
How we built it
The frontend is a React Native application, using Google Places Autocomplete for origin and destination selection, as well as a React Native Mapview and Mapbox's Polyline library. We use Expo to deploy it.
The backend server is implemented in Python, and exposes a REST API using the FastAPI library. Behind the scenes it uses the Google Maps Routes API to get high quality cycling and transit routes, and then uses a custom algorithm to create routes that leverage both cycling and transit.
Challenges we ran into
On the frontend it was very difficult to get a mapview displaying. A further issue was being able to accurately display lines. Rendering has to be incredibly precise to actually line up with the roads that we're telling the user to take.
On the backend, one of the biggest technical issues was actually getting basic routing going using an API. We tried multiple APIs before settling on Google's, and the Google Routes API is incredibly detailed, but as a result also can be very difficult to parse, containing many nested layers and semi-redundant entries. Another major struggle was actually implementing multimodal routing logically. There are a number of ways to implement this, so it was important to balance getting the best possible routings with how much time we realistically had available during this hackathon to implement more complex algorithms. Finally, there were a lot of struggles with managing timing in the program. Between the Routes API strictly enforcing times being in the future, as well as juggling timezone issues when converting between datetime and Protobuf Timestamps, it took a bit to hash out all of the errors that stemmed from timing and time communication issues.
Accomplishments that we're proud of
- Learning how to work with Google Maps and Places APIs successfully
- Getting a lot better at working with REST APIs, including error handling
What we learned
We learned a tremendous amount about how navigation applications work on the backend and how their rendering and routing is done. It was also one teammate's first time seriously working with REST APIs beyond just fetching data, and we learned a lot about error handling in HTTP, including our new favorite HTTP error, Error 418 ("I'm a teapot").
What's next for Mobike
There's a lot in store for Mobike! We initially built this because it was a real issue we were facing, with little alternatives for the everyday user except manually creating cycling + transit routes themselves.
An incomplete list of items to work on in the short term is:
- Implementing a more complex route planning algorithm still based in existing route APIs
- Building out the frontend to be more user-friendly
- Implementing notices to inform users of bicycle restrictions on suggested transit routes
- Offering more granular control to the user, as well as allowing them to select between multiple routes
In the longer term, we would like to:
- Replace the route planning with a more custom solution that allows us to optimize routes further
- Add in turn-by-turn navigation
- In general get it to feature parity with typical map/navigation applications like Google or Apple Maps
Built With
- expo.io
- fastapi
- google-places
- google-routes
- python
- react-native
Log in or sign up for Devpost to join the conversation.