600.226: Data Structures

Spring Semester 2006: January 30, 2006 - May 5, 2006

Assignment 11: Driving Charm City

Out on: April 21, 2006
Due by: April 28, 2006 by 5:59 pm for full credit (11:59 pm for 10% off, hard deadline)
Collaboration: Teams
Grading: Packaging 10%, Style 10%, Performance 20%, Design 20%, Functionality 40%

Overview

The eleventh assignment for 600.226: Data Structures once again deals with maps of Baltimore or "Charm City" as it is affectionately called by some. It's time to actually "attack" the competition and extend your "big project" with the real functionality that clients of MapQuest, Yahoo! Maps, and of course Google Maps expect. It's time for driving directions and all that good stuff. :-)

This is a team assignment, and all of you should know which team you're in (I hope). Each team hands in one assignment! Decide early on who is going to be responsible for submitting the assignment and when. Make sure to include all the relevant information (who is in the team?) in your README file! All members of a team will receive the same score for the product you submit together.

The Mapping Application

Your one and only task for this assignment is to turn your prototype from last week into a real mapping application with the following features:

Given an address in the Baltimore area, compute its position (in terms of latitude and longitude); the position should be as accurate as possible given your data set, which requires address interpolation of some kind; feel free to do some "excursions" with a GPS device of your choice to see how good you are. :-)
Given two addresses A and B in the Baltimore area, compute the least-cost path from A to B along drivable roads; your cost function is distance and distance only! (We are serious about this: even if you are implementing other cost functions as well, you must have one that only uses distance and drivability, nothing else.)

Please use Dijkstra's algorithm for finding the least-cost path through your network of streets. That's it! At least for the "core" requirements that we will expect when grading your project. Of course you should still try to "outdo" your competition in whatever area you feel will be most important to convince the venture capitalists to invest in your startup company at the end.

Please don't just hack more code without thinking, update your DATA and PLAN files from last week as well! As before, the DATA file should contain a description of your understanding of the TIGER/Line data and how to use it. The PLAN file should contain your "design notes" for the project. This doesn't have to be some fancy report, but it should describe your key use cases, abstractions, and data structures in enough detail for us to follow your ideas.

Possible Features

Here is a list of features (in addition to those we suggested last week) you might want to think about as you are trying to produce the coolest mapping application in years:

Sometimes you want to go from A to B, but you also want to stop at C on the way (or, more generally, at a number of additional locations). Allow users to specify additional "waypoints" that your route from A to B should pass through as well. There are a number of issues to think about. For example, if going to C is increasing the distance to B "too much" in some sense, you may want to warn the user. Also, if users specify several "waypoints," it might be "less driving" to visit them in an order different from the one they were given in.
Some users may prefer to drive certain kinds of streets. For example they may want to avoid either highways or regular surface streets as much as possible for some (superstitious?) reason. Allow users to specify these preferences and incorporate them into your cost function in some appropriate way.
The following makes sense in general, but it would be especially useful if combined with the previous features. You may want to allow users to "change their mind" on the fly and "explore" various alternate routes. For example, once directions have been given, allow users to look at the particular choice you made (i.e. the instructions on where to turn, where to exit, etc.) and "overrule" the optimal route you suggested. Imagine that your directions tell the user to "turn left" but there is construction going on and the user knows that it should be avoided by going right; this will definitely alter "later" steps in your directions, and it may even be better to "backtrack" and suggest changes in previous steps given the new constraints. This could be done in a particularly cool way if you have a graphical user interface... :-)
Dijkstra's algorithm is getting a little "carried away" sometimes and will complicate the directions quite a bit in order to save a few yards. Implement a cost function that makes this less likely, resulting in more drivable directions.

Need even more ideas? Jason's original assignment has several good suggestions, please check those out. Of course there are many more possible features, and you're free to implement whatever you can come up with. Go ahead and surprise those venture capitalists... :-)

Deliverables

Please turn in a gzip compressed tarball of your assignment; the filename should be cs226-assign-11-teamcode.tar.gz with teamcode replaced by the code assigned to your team for your repository and your mailing list. The tarball should contain no derived files whatsoever (i.e. no .class files, no .html files, etc.), but allow building all derived files. And your tarball should definitely not contain copies of the data files, but instructions of where we have to put them for your code to find them. Include a README file that briefly explains what your programs do and contains any other notes you want us to check out before grading.

Grading

For reference, here is a short explanation of the grading criteria. Packaging refers to the proper organization of the stuff you hand in, following the guidelines for Deliverables above. Style refers to Java programming style, including things like consistent indentation, appropriate identifiers, useful comments, suitable javadoc documentation, etc. Simple, clean, readable code is what you should be aiming for. Performance refers to how fast your program can produce the required results compared to other submissions. Design refers to proper modularization and the proper choice of algorithms and data structures. Functionality refers to your programs being able to do what they should according to the specification given above; if the specification is ambiguous and you had to make a certain choice, defend that choice in your README file.

If your programs cannot be built you will get no points whatsoever. If your programs cannot be built without warnings using javac -Xlint we will take off 10% (except if you document a very good reason). If your programs fail miserably even once, i.e. terminate with an exception of any kind, we will take off 10%.

Kudos

This project is based on a similar assignment by Prof. Dr. Jason Eisner: Thanks a bunch for the inspiration! :-) You are free to read Jason's assignment which contains lots of advice and background information that I am not providing. However, remember that you are doing this version, not Jason's version. If you use any of Jason's ideas, please give proper credit in your README file.