600.226: Data Structures

Fall Semester 2005: September 8, 2005 - December 12, 2005

Assignment 11: Driving Charm City

Out on: November 20, 2005
Due by: December 1, 2005 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 only, but please make sure to include 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.

Aside from the code you develop for this problem (and thus your project) please also include a plain Unix text file PLAN that contains your "design notes" for the project; this doesn't have to be some fancy prose document, but it should describe your key abstractions and key use cases 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, giving more drivable (albeit possibly somewhat longer) 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 extension should be .tar.gz). The tarball should uncompress into a directory cs226-assignment-11-teamcode with teamcode replaced by the code assigned to your team for your repository and your mailing list; uncompressing should not create any other files in the current directory. The tarball should contain no derived files whatsoever (i.e. no .class files), 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 a lot of advice and background information; 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.