Purdue Map System

 

Existing commercial mapping software is great at giving street level driving directions for known addresses.  However, for large universities where the majority of the traffic is by pedestrians, this mapping software breaks down.  The need for giving directions for a university campus goes beyond just common streets; they need to include pedestrian walkways, common shortcuts, and paths.  The goal of this project is to provide an interactive map of Purdue University to help students and visitors find where they need to go and how to get there. 

 

Base Requirements

 

  1. Route Request:
    1. The system shall provide the ability for a user to request directions from Point A to Point B.
    2. The system shall display a route from Point A to Point B on a map of the Purdue campus.  The resolution of map could be buildings or rooms.  The map graphic could be a facilities map, a Google graphic, MapQuest graphic, or any map that best integrates with a teamÕs solution.
    3. When a route is requested, the system shall show the correct portion of the map overlayed with a method to indicate the directions from Point A to Point B (such as a highlighted line, bar, or teamÕs choice).
    4. As a minimum, the system shall allow the user to request a route by specifying building names as the starting and ending locations.
    5. If more that one route exists from Point A to Point B, the system shall return all routes with an indication of which route is preferred (if any).
  2. Route Entry:
    1. The system shall provide the ability to input a new path from Point A to Point B. 
    2. When requested to enter a route, the system shall provide the ability to include at least two segments for any route.  For example, the route starts at Point A with a segment that stops at Point B, then another segment that starts at Point B and goes to Point C as the final destination.
    3. As a minimum, the system shall allow the user to enter a route by specifying building names as segment end-points.
    4. The system shall allow more that one route to be defined between any given Point A and Point B.
    5. The system shall allow the user to define routes that are preferred or not preferred.
  3. The system can include any other features the team chooses.

 

 

Design Hints

 

  1. The system lends itself well to be architected as a front-end/back-end or client/server.
  2. Back-end/server suggestions:
    1. Use a well-documented database and/or server, preferably one that a team member has familiarity with.
    2. Use the back-end as the place to store the map and routing information.
    3. Try to handle up to 5 or more concurrent connections and routing requests so multiple front-ends/clients can be supported at the same time.
    4. Plan on implementing a default set of building and landmark locations of the Purdue campus to facilitate input of route information.  Ensure the locations that are specified properly correlate to the chosen map graphic.
    5. Assign a unique name to each location or landmark.
    6. Try to utilize efficient cross-referencing and data inquiry algorithms such that user response time is minimized.
  3. Front-end/client suggestions:
    1. Implement the client application as a user-friendly GUI that executes in MicrosoftÕs Internet Explorer, or some other internet browser.
    2. Allow 5 or more instances of the GUI application to be executed concurrently.
    3. Try to display routing information such that all buildings and landmarks of the route are included on the map graphic and the relative surrounding area is also shown (i.e. the displayed map of the chosen path is filled in to show surrounding buildings and landmarks).
    4. Users make mistakes.  It would be a good idea to handle the most common input mistakes, for example if a landmark or building doesnÕt exist in the database the application could return a message stating such.  Also, the ability to erase an erroneous or out-of-date route could be very useful.

 

 

Judging Criteria

 

  1. How effectively the system performs required functionality.
  2. How efficiently the system is designed and implemented.  This relates to factors such as how fast routing information is returned and displayed in the user application.
  3. GUI design in the areas of usability, creativity, and originality.
  4. Extra features supported.