We are always working on new ideas to improve our modeling capabilities and make our jobs easier. One terrific improvement in the last year has been the advent of automatic externals balancing. This is, of course, not without a price of its own. That price is the need for additional and better input data.

In order to use automatic externals balancing properly, not only must we know the directional counts of traffic on each link attached to an external zone, but we must know how much of that count comprises Internal-eXternal (I-X) movements and how much of it is eXternal-eXternal (X- X) or through trips. As if that weren't enough, we have to know how many went to each of the other external zones when dealing with through trips. The mechanism for providing this data for a simulation run is the input trip table.

For example, say we have a large network of 140 internal zones, and we have 35 external zones, each connected to the internal network by at least one two-way street or two one-way streets. The simulation run will distribute the X-I and I-X trips, but it will have no idea how to deal with the X-X trips. To illustrate this, let's imagine this network as a window in a much larger urbanized area. Perhaps 70% of the volumes on the major routes are through trips. Now imagine this same network on an island. There may be no through trips. It is obvious that we must provide this information as best we can.

Let's say we have conducted a count program to gather the directional counts for each link connecting to an external zone. How do we break these counts into more detailed data? Perhaps we can get some data from the State on state and interstate routes which pass through our area. Perhaps we can do a roadside, or postcard, or license plate survey for some of the external links. Perhaps we will have to apply some "professional judgement."

Continuing with our example, we must supply a full-sized input trip table, although all the external trip cells are located in the lower right corner in from zones 141 to 175 and to zones 141 to 175. However, this small portion still contains 1225 cells. Given that we may not have all the information and that it all must balance, how do we fill in these cells?

First, we know the row and column totals. The row totals equal the through-trip portion of the counts from each external zone. The column totals are the portions to each external zone.

Next, we know that certain cells should have no interactions, that is, contain zeros. For instance, two external zones right next to each other connect to the internal network through two parallel streets. A trip between those two zones suggests that a person drove from one external into the internal network, made an almost U-turn, and drove back out the network on a parallel route. Unless there was a physical barrier between those parallel routes barring all connections, this not the likely route between those externals.

Also, we do not care about intrazonal trips in an external zone, so we will consider the cells on the diagonal to contain zeros.

To get a possible trip table, we could then insert ones (1) in the cells where interactions should exist and FRATAR the matrix to our known row and column totals. Inspection of this would, of course, reveal that some of the cell estimates are ridiculous.

So, we might then enter some real data (from the state or from surveys) for the cells where we have it. If we could then hold those cell values as well as the cells containing zeros and then FRATAR the remaining cells to still achieve the row and column totals, we would achieve an even better estimate of a possible trip table.

Through this iterative cycle of fixing some cell values, FRATARing, and inspecting, we can come up with a reasonable estimate of a through trip table where everything balances.

As part of our development efforts, we now have some early experimental modules which accomplish this task. This includes a trip table editor which is easier to use in order to enter the zeros, ones, and fixed values and a trip table adjust module which FRATARs the cells containing ones (1).

Before we integrate it fully into TMODEL2, we would like to have some users test these modules and give us some feedback on their utility and usability.