The travel_data table

Outputs from the external travel models, these logsums are inputs to the Accessibility Model.

The travel data can be interpreted as the composite utility of going from one place to another given the available travel modes for that household type. (Negative values reflect the fact that the time required gives the trip negative utility.)

Intrazonal travel may have less utility than interzonal travel if mass transit routes or highway options allow for easier travel to an adjacent zone than within a zone. logsum3 often shows lower utility than logsum2 because the logsums represent composite utilities for different household types. So, for example, it may be that 2 car households tend to have a more favorable person- to-car ratio than 3+ car households. Or it may be that 2 car households are more frequently able to combine trips, decreasing the disutility of any individual trip.

Note: In order to conserve memory usage, when the logsums are read from the database each logsum is multiplied by 100 and then converted to a short. When used in the models, it is divided by 100 to change back to a floating point number. Thus the precision of each logsum is two decimal points plus round off errors from converting between floating point and integer representations.

These data should be updated with the results of any travel model run.

Column Name	Data Type	Description
from_zone_id	integer	xref=''#Zones'' ``From'' traffic analysis zone
to_zone_id	integer	``From'' traffic analysis zone
logsum0	float	(Not checked by Schema Checker) Logsum value for 0 vehicle households, transit logsum
logsum1	float	(Not checked by Schema Checker) Logsum value for 1 vehicle households, transit logsum
. . .	float	(Not checked by Schema Checker) . . .
logsumN	float	(Not checked by Schema Checker) Logsum value for N+ vehicle households, transit logsum

The travel data table is a little different from other tables, which generally have a fixed number of columns, in that it can have 1..N ``logsum'' columns.

Note: Currently, the variables that UrbanSim supports assume the fixed structure, logsum0 (for transit), logsum1, logsum2, and logsum3 (for 3+ vehicle households). If you add another logsum column, for example logsum4, for 4+ vehicle households and take logsum3 to mean 3 vehicle households, the variables in the UrbanSim models will not make use of this, and will continue to use logsum3 as if it still stood for 3+ vehicle households. To use more logsums the user will therefore have to modify the UrbanSim accessibility variables.

• There must be a row for each combination of from_zone_id and to_zone_id for all zones in the zones table. For instance, if zones contains 3 zones (1, 2, and 5) there must be at least the following 9 entries in travel_data: (1,1), (1,2), (1,5), (2,1), (2,2), (2,5), (5,1), (5,2), (5,5). When the TravelDataMatrix is instantiated it allocates an array based on the maximum of from_zone_id and to_zone_id squared times the number of logsums. Later when this array is accessed, it is accessed by the zone id's read from the zones table. Thus if the numbers of zones represented in these two tables are inconsistent, this will cause an array access violation.
• There may be additional entries in travel_data for zones for from_zone_id or to_zone_id values that are not zones in the zones table. These are not used by the model computation.
• All logsum* values must be less than or equal to zero.
• There must be at least one logsum* column
• The logsum* column names must start at logsum0 and increase consecutively through the integers. The names must match the Perl regular expression /logsum\d+/
  • HouseholdLocationChoiceModel requires logsum0-logsum2 to be defined. If logsum3 is not defined then logsum2 is used for all computations that would otherwise have used logsum3.

If you have positive logsum values, subtract the maximum logsum value from all logsums in your table. This will correctly shift the logsums so that non are greater than zero.