Every year approximately 50,000 students attend Texas A&M. A substantial percentage of these students are newcomers to the campus and need a clear and intuitive way to find locations such as buildings, classes, and eating establishments. Even experienced students need directions to seldom-visited buildings. Ideally, these directions should be provided to students according to a chosen transportation method. For example, the path of a student driving across campus will differ from the path of a student walking across campus. Our Campus Navigator application provides a simple, user-friendly interface to find directions around campus for a variety of transportation types.
There already exist several commercial navigation applications - such as Google Maps, Yahoo Maps, and Mapquest - that provide users with directions from one place to another. However, these applications must search along existing roads; they are not able to provide routes that are as precise as an on-campus path would require. For example, a user of our application may choose to select "walking", "driving", and "bussing" as viable transportation options; the shortest path might then have the user walk to their car, drive to a certain parking lot, then take a bus to the destination. Our Campus Navigator application enables users to obtain routes that are much more detailed than an existing commercial application can provide.
Our implementation of a navigator application calls for much greater complexity than the simplest version of this type of application. At its core, a simple navigation application would not be difficult to create. The campus would be represented as a Graph structure, with locations (buildings, parking lots, etc.) on campus stored as vertices of the Graph and transitions between the locations (roads, sidewalks, etc.) stored as edges between the vertices. A simple Dijkstra's search would then be used to calculate the shortest path. However, the wide variety of queries and paths our application must handle requires us to develop a much more complex application.
Our extension of a simple navigator application allows research in two areas. First, we explore the complexity of handling shortest-path searches with multiple ways of traversing an edge. For example, an edge traversed by walking should have a different weight than the same edge traversed in a car. The correct weight must be chosen when calculating the shortest path. Also, stoplights and traffic may alter the weight of an edge. In addition to this, we explore the challenge of designing a user interface that is intuitive and robust enough for both inexperienced and experienced users.