When the San Francisco County Transportation Authority developed the citywide dynamic traffic assignment (DTA) model for San Francisco# (see submitted abstract, Modeling Every Hill, Bus, Traffic Signal, and Car ... or http://dta.googlecode.com), the DTA team had a second goal: to share the tools developed for the process with other cities and regions that might be interested in developing a DTA model. As a result, the team has created an open source project called DTA Anyway to facilitate the creation of DTA networks and scenarios. The code performs the following tasks:

* Imports the static model network and adds shape;

* Imports transit lines from their static model format;

* Imports traffic signal phasing and timing plans;

* Imports stop signs from a GIS layer;

* Attaches count data from a separate database; and

* Writes all files in a format ready to be run by the DTA model.

Automating these processes allows a new DTA scenario to be run each time the static model (SF-CHAMP) is run, which facilitates testing with future demand and different scenarios, rather than being constrained to a single scenario.

The development team designed the API before implementation with two primary objectives: making it (1) easy to use and (2) extensible. DTA Anyway consists of an object-oriented python library with objects that represent the dynamic network, nodes, links, movements, etc. The library does not include any San Francisco-specific code; rather, these local elements are encapsulated in the scripts that use the library. While the San Francisco static network is in the Citilabs Cube format and the output dynamic network is in the INRO Dynameq format, the library design attempts to decouple the read/write methods from the data structures as much as possible, for easier future extension to other static and dynamic network formats.

This presentation will include some of the lessons learned by the DTA Anyway team, including the value of source control, using google code to track tasks, the utility of short development cycles and small tasks, the emphasis on useful documentation, and using code review to ensure code clarity and documentation quality.