At times, like any other city, Victoria is not always safe to travel by foot at night. With some portions of the population feeling concerned about safety in the area they live, the idea for creating an application to help users travel more safely would be a great way to give back. This would not only benefit our community, but can be easily applied to other cities as well.

What it does

GetThereSafe maps the best route to your destination by determining where the most amount of light sources are.

How we built it

Utilizing a Google Maps API, we built a PostgreSQL database that stores light source data from the Open Data Catalogue from the City of Victoria. When the Flask web app receives the start and destination locations, it calls upon our database to determine which route has the highest amount of light sources. It then returns the best routes for the user to use.

Challenges we ran into

Database Implementation: Our main challenge was creating a database (to store light source data) that could easily communicate with our app, which was being deployed via Heroku. The first attempt was to host our database with Orchestrate, but after determining that it would have taken far too much time to implement, it was decided that the team should change services.

On the advice of Artur from MLH, he suggested to spin up an Amazon Web Service that would host our database. Creating an EC2 instance running PostgreSQL inside, the database finally began to take form. However, we began to notice that there were going to be permission issues with our web app communicating with our EC2 instance.

An attempt to make a pg_dump into an RDS instance was made, but after three different database implementation attempts and much research, it was decided that we would implement our database via Heroku's PostgreSQL add-on (which utilizes AWS in the background, but in a limited manner in comparison to our previous attempts).

We were hoping to utilize cloud services to make our data set easily scalable, with the goal of being able to add more information to make our user's route as safe as possible. Unfortunately, due to our utilization of Heroku to deploy our web app, this complicated our implementation attempts to allow our services to communicate with one another. In the end, this was a significant lesson in not just correct database implementation, but also how multiple services communicate with one another.

Accomplishments that we're proud of

  1. Implementing an EC2 server instance running a PostgreSQL DB instance
  2. Managing to survive 15 hours of database brutality, and having created four different databases in that time.
  3. Calculating the best amount of light source coordinates on each route
  4. Site design!
  5. Mobile responsiveness
  6. Our logo is pretty cool - it's awesome!!!!
  7. Utilizing our first Google API!

What we learned

  1. Heroku is not very good at communicating with multiple services - this was a hard earned lesson...
  2. The scalability of AWS is GODLY - during the research phase, AWS proved to be a very viable option as we could add more data sets (e.g. crime) for our web app to work with.
  3. Traversing routes from Google Maps and determining closest light source to each coordinate

What's next for GetThereSafe

  1. Getting our AWS EC2/RDS PostgreSQL instance communicating with our app instead of Heroku's add-on.
  2. Add support for more cities! We will need to search for cities with this data openly available for them to be implemented within our application.
  3. Able to toggle between each route that the user would want to take.
  4. Start/Destination auto-completion fields.
  5. Pull location search data from Google as replacement for addresses
  6. Add more data sets to enhance route pathing (e.g. crime)
  7. Add support for cycling (use topography map, cycling route maps, and lighting to determine route)
Share this project: