|
||||
University of Oregon
|
Like many municipal transportation systems, Lane Transit District (LTD) publishes bus schedules on their web site. However, if I want to know how best to get from the CS building to Fifth Street Market for a beer with some friends at 6 on Friday, it is not easy to determine which buses I should take, or whether I would get there faster by walking. I want you to change that.
Your team will build a web-based bus route finder. A user will enter a starting point, a destination, and an approximate time, and your application will produce a page giving a recommended (approximately best) trip plan, possibly including up to four bus rides, and including the time and location of entering and leaving each bus.
The project is small, but I insist on high quality. You will use real LTD schedules. Although you need not include the whole LTD schedule in this system, you must convince us that your system would work satisfactorily with the full LTD system schedule. I will consider Project 1 a complete success if LTD requests the software to use as the basis of their own trip planning interface.
This assignment is intended to give you some practice in developing a complete, high-quality software package and in team development. The practice you gain now will be useful in your larger project later.
User input is through an html form. The design of this form is left to you (but you will be graded partly on its usability).
Output in response to the web query will be a "trip," which is a sequence of "segments." A "segment" is entering a particular bus (e.g., #24 Donald) at a particular time (e.g., 7:46am) at a particular location (e.g., Willamette and 29th), then leaving that bus at a later time (e.g., 8:00am) at a different location (e.g., Donald at Fox Hollow). See the notes below for additional information about trips. Trip plans should be displayed in a format that is suitable for printing.
Trip plans should be approximately optimal. The criteria that make one trip "better" or "worse" than another are total trip time (less is better), arrival or departure time, and number of transfers (transfers = segments - 1). You have some freedom in defining "optimal" in a way that makes your programming task easier, but you must be reasonable. Trip plans must also be feasible. For example, you must leave a reasonable amount of time for each transfer, to minimize the likelihood of missed buses.
You must consider and handle cases in which no reasonable trip plan can be found. Ill-formed queries (e.g., a location that doesn't exist) should be prevented wherever possible, but you may have to handle some input errors. You will also have to handle cases in which a query is well-formed, but has no satisfactory answer nonetheless. You may consider any trip of over 90 minutes to be unsatisfactory (or you may set a higher bound). You may also consider trips with more than three transfers (four segments) to be infeasible.
In addition to the user query, your system will use a representation of actual LTD bus schedules. It must be simple for non-programmers to replace and augment this schedule data. See notes below for additional notes on maintaining the schedule database.
Your system must scale reasonably to at least the full size of the LTD bus system, and preferably it should be usable also for more complex metropolitan transportation systems (e.g., the Portland Metro system which includes both buses and the Max light rail line). It must not put an unreasonable burden on a web server. This implies that you will have to remember at least a little bit from CIS 313 and CIS 315, and not use completely stupid data structures and algorithms. (For this purpose, "stupid" algorithms during a web query are those that are quadratic or worse. "Stupid" algorithms for off-line processing, such as preparing tables to make web queries faster, are those which are worse than quadratic in the number of bus stops or worse than cubic in the number of bus routes.)
You must deliver much more than just a piece of working code. In fact, it is likely that much less than half of your total effort will go to production of code. A concept document and a design document will be due during the course of the project (see the course schedule for dates); these must be turned in along with the project source code and the following:
All of the above must be provided in a single package, in a convenient form. Acceptable forms include
A bus route is a sequence of stops, some of which are time-points. A time-point has a definite scheduled time (if the bus arrives early, it waits until the scheduled time to depart). Between two time-points there may be several other stops. All we know about that time at which a bus arrives and departs at a stop that is not a time-point is that it must be after the previous time-point, and before the following time-point.
Usually, people transfer (change buses) only at time-points. You may assume that transfers are only possible at time points. However, people often board and depart buses at stops that are not time-points.
Schedules are more complex than you might think. For example, a bus does not always follow the same route in the morning as in the afternoon. Schedules also differ between weekdays, Saturday, and Sunday. (Holiday schedules are usually based on Saturday or Sunday schedules.) You must handle this properly. However, you may assume that a person can enter or leave a bus at any bus stop along the route (which isn't strictly true: See for example route 68c, which includes some stops at which people are allowed to leave the bus but not to board it.)
The route "database" may be just a set of plain text files. You will probably want to have one "source" format for data entry, another more efficient format to be used during the web queries, and a translator from the former to the latter. It is highly desirable to provide validation (i.e., to check the database for well-formedness).
Ideally, the schedule database used for online trip planning and the data used to print LTD schedule documents should be the same. We do not have time to study the actual information structures used in LTD computer systems, but you can anticipate an eventual unification of the two by keeping the external (input) representation of the database cleanly separated from the functionality of your software.
No one can type in all the details of the complete route system without making mistakes. Input data validation may help, but (as always) it is better to prevent errors than to handle them. You can reduce the chance of data input errors by designing a simple, compact language for describing schedules. For example, the external data format could indicate that Route 68c Chad Drive runs every 30 minutes from 6:40 to 8:40, rather than separately entering the 6:40, 7:10, 7:40, 8:10, and 8:40 runs. An alternative to providing a compact input format would be to somehow extract the schedule data automatically from LTD web pages, but I suspect that will not be feasible.
Is the time of a trip the preferred time of departure or the preferred time of arrival? Often we have arrival time constraints (e.g., I am meeting friends for a drink at 6, and I'd like to leave the office as late as possible.) Occasionally we may have departure constraints (it's 8, I want to leave, what's the quickest way home?). Ideally your system would support both, but you are required only to support one or the other.
In finding an approximately optimal trip, you may want to assign a "cost" to a transfer. For example, you might consider that a transfer has a "cost" of 20 minutes in addition to whatever time is actually spent waiting. It is probably simpler to just make minimizing the number of transfers the most important criterion, but note that this will sometimes result in trip plans that most peope would consider bad.
It is desirable, but not required, to allow queries and results that involve not just a single trip plan, but the best trips during a range of times (e.g., getting from Oregon Hall to Fifth Street Market between 4:30pm and 6:30pm). The best trips during a range of times could involve quite different routes.
Last change