How It Works

Imagine you’re traveling to a new city...
How do you find the most interesting attractions and plan a day of exploring?

Project Overview

Our project was a Django web application, utilizing an Apache server and PostgreSQL for database management. Our end-goal was to create a fast, personalized, and interactive itinerary builder for walking tours of cities. Furthermore, we used several APIs, including (but not limited to) Yelp, Wikipedia, Google Maps/Search, Twilio, and Bitly for our data.

To speed up the user experience, we used a database to store information from pre-selected cities, thereby eliminating the need for several API calls while the app is running. In each of these cities we ranked places of interest (POIs) as decided by Yelp based on a popularity formula provided by the paper we loosely based our project on. Our algorithm selects nearby POIs based on a calculated score that factors in distance, user preference, and popularity score (using Yelp ratings). Then, it creates a path that minimizes the distance between points while maximizing the score of the POIs on the route. This algorithm returns up to 8 POIs in traversal order that we send to the Google Maps API to get a map of the route.


Literary Research

“Aurigo: An Interactive Tour Planner for Personalized Itineraries”

We based our project on a paper presented at the Intelligent User Interfaces conference in 2015, “Aurigo: An Interactive Tour Planner for Personalized Itineraries.” Like the original paper, we tackled two main problems, the first being the efficient itinerary problem (how to pick the best possible points of interest for a visitor to pass through on a walking tour from one point to another), and the second being the assisted exploration problem (how to design an effective user interface for a user to customize their own itinerary). Our approach was similar to the paper's, making use of the same general algorithms for selecting points of interests, and basing our own interface design off of Aurigo. However, we did make small adjustments and deviations in design and algorithm implementation.

In particular, we changed the following aspects of their paper to better match what we wanted for our project:

Front-End

  • Utilized sliders instead of buttons for the user input page.
  • Allowed for expandable pop radius.
  • Allowed for reordering of route through side panel.
  • Changed interface for POI markers and info windows.
  • Added "send-directions-to-phone" capabilities.

Back-End

  • Weighted and normalized preferences used in algorithm.
  • Changed how distance was calculated. Namely, rather than just using Euclidean distance, we used the distance of a POI to an endpoint if a POI did not orthogonally intersect with a segment.


The Algorithm


Steps

  1. Draw a line between start and end point creating path of one segment
  2. For each segment in route:
    • Loop through each POI in the city
    • Find POI with best overall score
  3. Add POI with best score to the route, creating an additional segment
  4. Repeat 1 - 3 until path has chosen number of POIs as selected by user

User Studies

We also conducted a user study to test our application's usability and made changes accordingly to help make our application intuitive and easy to learn. The changes we made include the following:

  • Enhanced sidebar interactions
  • Populated database with more POIs
  • Improved discoverability of features