Inspiration
Cornell is incredibly hilly. As using a car to get around campus is beyond impractical, I had taken to biking around campus. However, the hills of Cornell are notoriously brutal. I figured that, if we were able to plot a path with the least change in positive elevation, I could make my commute easier by finding the true path of shallowest ascent to my destination
What it does
Currently, the app takes multiple poly-line routes from Google Maps, categorizes them based upon steepness and change of elevation, and allows the user to select their preferred path optimization by their preferences.
How I built it
Using JavaScript, we implemented the Google Maps API to generate a number of routes between points. Then, from these routes, we accessed the steps of the journey, and through these steps we were able to, between each line segment of the step, calculate the change in height via the Elevation API. Then, by providing this data to the user, the user may then receive the most desirable route from their preferences.
Challenges I ran into
Some challenges we ran into were using the API as were are all new to the JavaScript language and thusly there was a even steeper than usual learning curve. At one point, our code mysteriously ceased working, despite multiple API refreshes, re-implementations, and testing, requiring a full rewrite of the code and upgrade to our API access in order to restore functionality. Another challenge we ran into was decoding the poly-line values to pass to our path ranking system. We were able to partially solve this problem for small data sets, however we were still unsure about the structure of the encoding for larger data sets.
Accomplishments that I'm proud of
Although only partially implemented, we were able to successfully create a decoder for Google's poly-line encoding in Python, however, because of an idiosyncrasy with Google's poly-line encoding, namely a change in compression with poly-lines greater than 2 points of complexity, we were not able to make this functional. Despite that, this is probably one of, if not the most difficult problem we had with our implementation at this stage, and although we only were able to achieve partial completion, I still think this is impressive.
What I learned
Our group had to work out the idiosyncrasies of the Google Cloud framework and specifically the Google Maps Directions API, the cause of most of our complications. None of us were exceedingly well-versed in JavaScript, so we also had to learn how to parse code in JS.
What's next for Rise/Run
Due to lack of time, we were forced to essentially side load our path ranking program onto Google's pathfinder framework. Given more time, we could have implemented our own A* algorithm in order to consider more roads which Google ignores, such as parks, while ignoring exceedingly steep footpaths likely to either be dangerous or contain difficult to pass stairs. In addition to basic rider safety, with our own algorithm we could account for more parameters, such as crime rates, sidewalk closures and other construction work, or high pedestrian traffic, to truly provide the best, safest bike route. Although we could go much farther with this idea, I think this would be the first step forward from the current state.
Log in or sign up for Devpost to join the conversation.