- Project Name: Route Ranker
- Group Members: Samantha Anderson (sna@), Eric Denovitzer (edenovit@), Nick Gilligan (nhgillig@), Jonathan Lack (jlack@), Mark Whelan (mgwhelan@)
- Project Manager: Samantha Anderson (sna@)
For our project we will be creating a path tracking application for the iPhone. We will be addressing the issue of finding the quickest route between two endpoints and sharing these optimal routes with other trusted users. Different routes may be more efficient during different times of day and so we will aggregate and report the optimal routes based on specific time windows. This application will be most useful for commuters or people with many route options to a destination.
Major features of the application:
Our project is similar to existing route tracking applications, but adds additional functionality. By attaching time data to route our app can calculate route times and determining the optimal routes.
We plan to make this application for the iPhone using a remote server to do some of the more complicated calculations and store some of the route data. We will need to store the older route data in a database.
A user goes to a new city and wants to remember the path he takes through the city. Once he arrives on the train in the city, he opens up our application and changes the setting so that the application only records GPS coordinates infrequently because he is going to be exploring the city and tracking his route for a while and doesn't want to drain the battery. On the same home page the user clicks start and begins to track his route. As he explores, the user marks his favorite places by clicking mark place. This will place a pin on his current location on his current route map which he can review at any time.
Later that day the user is hungry and remembers passing a series of restaurants that looked really good about thirty minutes ago, but he had forgotten to mark. Luckily, the application also stores the time every time it records coordinates. He goes to the route map page and finds where he was thirty minutes ago and heads back there for a meal.
At the end of the day the user uses the route map to find the train station where he started and goes home. His day was particularly great and he thinks that his friend who is visiting the city next week should check out the places he explored and marked along his route. The user sends his route to his friend so that his friend can explore some of the same places.
Scenario 2: The commuterA user has a couple different routes that he takes to and from work. Sometimes he has to come in for work earlier for a meeting and cannot seem to keep track of which routes are best for what times of day. The user decides to fix this dilemma once and for all by using our application to store this data. Over a period of a couple weeks the user has been tracking all his different routes to and from work. A few times during this period he had to come in early and leave early.
After the user is pleased with the amount of data he has collected, he goes to the compare routes screen. Here he can make groups of data to compare. He wants to learn which route is fastest around 8:00am. In order to do this he first creates a new group. When he creates a new group it directs him to a new screen with all of his recent routes. From this, he selects all of the different times he took a route1 around 8:00 and puts them into the group. Once this group is finished, he creates a new group and places all of the times he took route2 around 8:00. After he has created all the groups he wants to compare, he clicks compare. This will produce some useful information like average start time, average end time, average trip duration, average trip speed, longest trip duration, and shortest trip duration. He notices that route2 was on average faster than route1 and so he adds route2 into his favorites and names it "8 am commute." He does the same type of comparisons for other times of day and stores the faster routes in his favorites.
Next time when the user can't remember which route he should take, he simply opens up his favorites screen and finds the favorite route corresponding to the time of day.
Because we are designing our application for the iPhone, it will have to be written in Objective C. Because each user could potentially have dozens of paths, and each path would contain dozens of GPS coordinates, we will have to store this information in a remote database. The basic organization of the data base is below:
Userinfo:Users will log on to the app via facebook. Using facebook's api, we will be able to access a unique userIDNumber and listOfFriends for each app user. All of the information for the other sections in the database will come directly from the phone.
The user is presented with a few options upon opening the app. The first few options fall under the broad category of path-tracking. The user can start tracking his path for an indefinite period of time, until he decides to stop. This would be a sort of free-range mode, for wandering about in a city or exploring somewhere new. Another mode would be a more targeted approach − the user can choose to sync his path-tracking with paths he takes every day. Tracking would automatically start when the user leaves his start location and automatically stop when he arrives at his end location, with a record kept of how long it took to go from start to finish, and perhaps a comparison of the time it took him to go from start to finish that time versus other times.
The information presented to the user would largely be in the form of maps, projected onto the Map application on the iPhone. A lot of the processing is done in the background − the dropping of pins to measure GPS coordinates is the biggest one. The GPS coordinates should be sent to our database after the path is completed; it should be sufficient to store them in memory until that point. After the user's tracking session ends, we need to connect the points on the map into a coherent path and use either colors or arrows to indicate when they traveled where. There is not a whole lot of other processing work, except to check start and stop locations and compare them with previous path history and paths taken by friends. We could also implement a "similar paths" feature, in which a user can view paths friends have shared that are near the selected path. A similar feature that would be interesting would be a "path history" feature − for the paths that users take every day (those most likely to be synced with the calendar), they could view all the previous times they took that route, sorted by time of day, date, or fastest time. Both features would just require a simple sort of a relatively small data set, though information would have to be fetched from the database.
For implementation, we are going to use Objective-C so that we can take advantage of the iPhone platform. The application will be mobile, and at the current time we do not believe that a web interface would be of much added value; the operating environment will be entirely within the app. In logistical terms, we will need a database (we are thinking of using SQLite) to store users' paths (start location, stop location, time and date of travel, and GPS coordinates at each point along the way), as well as lists of common places, favorite paths, settings, and which paths are available to that user. For the latter functionality, we will use access control lists, and we will have a separate "public" database for paths that other people have shared to everybody. For friend lists, we are likely going to try to leverage the Facebook API, allowing people to sign in via Facebook and use that list of friends. That should diminish the amount we need in our databases as well as make it easier for people to find friends. We will use the Core Location API that Apple provides to get GPS coordinates. We will also leverage the iOS 5 Maps API to name paths according to landmarks or route. This would be particularly useful for driving or walking in a city, and could help distinguish different routes people take from one place to another.
End of Spring Break (3/25) – Learn Objective-C and iOS app design from Stanford online courses
We are hoping that our first TA meeting after break will help us figure out the timing and order of these milestones:
We are set on the idea of using the iOS GPS functionality to perform a path-tracking service. There are however, many features that we can add to this, and many ways to use the GPS functionality that we have not entirely decided on yet. The 'Route Ranker' is going to evolve and could potentially change significantly as we go about building it.
We also acknowledge that there are other path-tracking apps currently on the app market, so one of the more important challenges for is to differentiate ourselves from, and improve upon, these other apps.
Logistically, there is very little/no experience with iOS programming in the group, and only slightly more than that with SQLite. There is going to be a steep learning curve at the beginning, and a significant amount of work will have to be put into learning these technologies before we begin using them to build our app.