Teams should be 2-3 students (maybe 4 for teams including students from the urban simulation course as well as CSE students). Projects suitable for a mixed CSE/planning teams are marked **; projects suitable for a CSE-only team are marked *. (Some could be either way, and are so marked.)
For the past 5 years or so, we've been using agile programming development methods for UrbanSim, including extensive use of unit tests, test-first development, an automated build system, etc. A novel part of the process for us has been connecting a traffic light (a real one) with our build system: green means all unit tests have passed, red means one or more failed, and yellow means that there is a build in progress. The automated build system and traffic light have been a valuable part of our software engineering process. Two problems are that we are using cvs for version control, and the build system is a home-brew one called Fireman. These were the right decisions at the time: cvs was the standard open-source version control system, and a suitable open-source build system wasn't available. The situation has changed, however: subversion offers some important capabilities that cvs doesn't (in particular anonymous repository access, and the ability to create new accounts independent of the CS lab); and there is now at least one built system that does what we need, namely CruiseControl.
So this project would involve setting up CruiseControl, and integrating it with our subversion repository, the unit test framework, and with the traffic light controllers. If possible we'd also like to publish an open-source hardware design of the traffic light controller in case others want to replicate this. This project would be in the standard CSE realm - the team wouldn't include students from the Introduction to Urban Simulation course. Ideally the project would involve implementing and deploying the new system during the quarter, so that the final report could include some discussion of the software engineering process involved in making the transition, and of the usage patterns of the result both within in the UrbanSim research group at UW and the broader UrbanSim user community. At least one team member should have some hardware skills.
An important consideration in major transportation projects or land use changes is equity: are the costs and benefits distributed equitably? If not, who gains and who pays? A related set of indicators is for economic welfare measures. Joel Franklin, a recent PhD graduate in the Interdisciplinary Program in Urban Design and Planning and an UrbanSim project member, worked on such analyses as part of his PhD dissertation. We'd like to take some of his algorithms and integrate them with Opus/UrbanSim - ideally, producing equity indicators as part of our standard indicator suite, including indicator documentation. This project would involve a mixed team of CSE / planning students. Team members from CSE will need to be willing to learn some new concepts and language! Some familiarity with statistics would be helpful, although not required.
A couple of years ago, Zoran Popović and students implemented some games that used UrbanSim output to construct 3-d street scenes of Seattle areas. There would be a 3-d control so you could fly over the city, have a pedestrian-eye street level view, etc. One application of this would be for modelers to inspect the data and look for outlyers. Another would be for interesting demos, to help engage people in the planning process and outputs and get some intuition about the results. And of course it would make a great demo. Ideally we would integrate this with the indicator tools, so that 3-d visualizations could be produced along with other indicators.
The street scene software needs to make lots of assumptions about the appearance of the streets and buildings beyond what UrbanSim produces. We would like like to expose these assumptions and make them changeable, with knobs to adjust parameters of how the buildings are constructed, trees and benches on the street, crosswalks, on-street vs off-street parking, bike racks, etc. I hypothesize that how people will regard a particular scene can be enormously influenced by these. An interesting consequence is that the results will be quite vulnerable to psychological manipulation -- so that it will be important to use the same parameters for different scenario outputs being compared. Further, this could be a nice educational tool to show people how such manipulation is possible. This would be a good project for teams of CS and planning students -- planning students could help define the parameters and appearance, and investigate its use in planning contexts. The CSE students should have taken CSE 457.
This project is related to 3-d Visualizations of Street Scenes. Duncan Cavens, now at the University of British Columbia, wrote a recent paper on "Site-Specific Simulation and Visualization of Suburban Growth". This describes a simulation system that produces semi-realistic visualizations of the resulting development in a new development site over time. This project would involve either getting his code, or re-implementing it, and integrating it with UrbanSim. Again, the CSE students should have taken CSE 457.
Our current chart-based visualizations for indicators aren't as good as they could be. Investigate improving UrbanSim visualizations using either matplotlib or chaco. Provide a good graphical user interface that lets users customize these visualizations as needed. The first part of this project would involve finding out what users need to understand the indicator results, and what software is available, followed by (likely) some paper prototypes and then implementations. This would be a good project to do with a combination of CSE and planning students, or could be done just by CSE students.
We've had considerable success in the UrbanSim project with using a traffic light as an ambient indicator of the health of the build. However, it is currently much more cumbersome to see what the current status is of simulations being run. With a full travel model run, PSRC takes 5 days to run -- so it's very helpful to know early if a run has failed or is producing bad values. So this project would involve providing ambient indicators of the health of the simulation runs active on our servers. Our initial conception is that this would be a monitor in our lab (and on the web) -- or perhaps better, a plasma display -- that would show useful indicator results from the current runs. The system would automatically cycle through different possible displays. These should be easily user-configurable. The initial stages of this project would be understanding how modelers currently monitor simulations, what kinds of indicators and other displays are available. Then there would be a paper prototyping and testing phase, followed by implementation and deployment. This project team would probably just involve CSE students, who would talk with the TAs and other UrbanSim staff members to understand what modelers need.
UrbanSim makes extensive use of Geographic Information Systems for preparing the data and interpreting results. For some of this we use proprietary software, but as an open-source project we would also like to provide open-source alternatives insofar as feasible. Currently we use matplotlib (an open-source plotting library) to generate simple maps, but these aren't up to the quality of the proprietary systems. We would like to investigate other open-source GIS systems (QuantumGIS, SAGA, ...?), identify a good one, and integrate it with the Opus indicator framework, to produce good-quality cartographic output. This project could be done either by CSE students only (talking with UrbanSim staff to understand the needs), or with a combination of CSE and planning students.
A current student project has been to use the Orange open-source data mining software to analyze input data for UrbanSim to detect possible errors. This project would involve extending that work, as well as experimenting with the Orange widget toolkit to construct classifiers using a graphical builder. At least one and ideally all CSE members of the project team will have taken CSE 473. If conducted as a joint CSE/planning student project, the role of the planning students would be to work on understanding common errors in input data, coming up with training data sets, and helping with the UI design of the system (which would be ultimately intended for planners and modelers to use).
Biogeme (Bierlaire's Optimization Toolbox for GEV Model Estimation) is an object-oriented software package designed for estimating a certain class of econometric models. We've done some experimentation with connecting it with Opus, since we expect these models to be useful for UrbanSim. The project is to create an TraitsUI/Envisage GUI for Biogeme, working with planning students to figure out what kind of interface is needed. As with the Equity Indicators project, students should be interested and willing to learn some new concepts. Some statistics will be helpful.
UrbanSim 3, the previous version of the system, included a database consistency checker that was quite useful in checking input databases. This project is to design a modular software architecture for a database consistency checker for UrbanSim 4, and implement a set of rules. In addition, though, the architecture should make it easy for other users to contribute rules.
Investigate running UrbanSim on IPython, a version that supports parallel and distributed computing. Applications:
Create a log manager to (a) write our logger information to a "database", and (b) allow the user to view the information in useful ways (e.g. expland/collapse sections, filter type of info shown)
UrbanSim runs can take 5 days to run, and monitoring the state of the runs is important. We have an interface to the run manager currently, but it could use improvement.
The Environmental Protection Agency has an air quality model, MOBILE 6. Integrate this with UrbanSim so that we can produce indicators of air quality for different scenarios. (Is this feasible?)
This project is not very tightly coupled with UrbanSim itself, but could be useful in the longer run. We have been using Traits and the Traits UI for building small graphical editors. The Traits UI system includes a layout engine, but Enthought has said they are quite interested in an improved constraint-based layout tool. So this project would involve developing such a tool, based on the Cassowary constraint satisfaction library. (There is already a C++ implementation of Cassowary, with a Python wrapper, although it may need some work to get it functioning with the current version of Python.)
Here are a few other project ideas, not fully developed: