Discussion and Outlook

Any design has shortcomings. Although the TRANSIMS design seems robust in the sense that design decisions from many years ago have not gotten in the way of newer issues, there are always elements which are easier to model with a certain design and others which are harder to model. Here are some issues:

• The router will find a good or the best transit line for a trip. In many cases, however, several alternative lines could be taken, for example at typical transit malls in American Central Business Districts. In such cases, the router will pick one line which seems convenient from the schedule; but it may happen that, when the traveler arrives at the stop, another line might be better.

  Including these effects into the router is possible, but only by defining additional ``virtual'' transit lines for each segment of the transit network which is served by several lines. For example, if a transit mall is served along its entire length by bus lines 1, 3, and 9, then a new line with a not yet existing number could be defined along the length of the path where the three lines overlap. Unfortunately, this yields a possibly high number of such ``virtual'' lines, since all combinatorial combinations of lines and segments could become new virtual lines. Also, the micro-simulation would have to pick it up in some way, that is, the route plan would have to state which bus lines are equivalent. - What this still would not capture is if two different paths via different transit lines could bring the traveler to the next activity.

• Dijkstra-type routers cannot deal with non-additive costs, which are used by most public transit fare systems or some road pricing schemes. The TRANSIMS router cannot deal with this directly, but at least for simple cases the feedback mechanism can pick it up. For example, it can force the simulation to try out both the transit and the car option, and add the monetary costs only at the point when the relative performance between both is evaluated.