"TravelTime" is followed by a field naming the From venue and then a field with the To venue, then the distance in metres, and then the optional worst case delay time in seconds, and finally another optional field with notes for the user (like "Take Elevator B").
This is used for calculating the shortest path between venues and the time it takes to walk it, which is then used for detecting shows you can't get to in time.
The Venues usually name places with shows, or you can make up venue names for intermediate locations to help with the path finding. Use something descriptive for the user such as "Fifth-and-Main" street intersections. They'll show up as venues with no performances. If you want to, you can add a VenueURL for intermediate places that points to, for example, a subway station web page.
The user's walking speed setting will be combined with the distance to get their walking time. The worst case delay time is added to the walking time to get the time it takes to travel between venues. If we can't find a path between the venues, the DefaultTravelTime setting is used for the travel time instead. The setting for time spent in line-ups getting tickets is added to the travel time to get the total time to go between venues. If a show starts before you can get to it from the previous show, it will be displayed (usually in red) as a conflict.
You don't have to specify every possible path when setting up your Festival; the shortest path composed from multiple TravelTime segments will be found. A rough grid of TravelTime segments covering the Festival's area will be sufficient. If you don't specify a TravelTime in the opposite direction, the reverse direction will be assumed to take as long to travel. If there's a one-way path for some reason, you have to specify that there's no reverse direction by putting in a TravelTime entry for the reverse direction with a negative distance (-1 is good).
The worst case delay time measures the time spent waiting at traffic lights, elevators and so on. Measure the time from when the light stops being green (as if you just missed it) to the next time it turns green. Elevator worst case time is measured by sending the elevator to the furthest floor and seeing how long it takes to go and return. Though crowded elevators take longer than that, so maybe measuring on a busy day would be better. For bus, subways, car and other vehicular travel limited by a schedule or speed limits (all cars go about the same speed), include the vehicular travel time and waiting time at the bus stop/station in the worst case delay time and only count the distance walked to the bus stop, station or parked car in the distance measurement.
Bicycle travel would be somewhat complicated (are they walking or biking indoors or both?), so we currently don't handle it, though you can approximate it with a very fast walking speed setting.
The Notes field is optional, and you do need to specify a worst case value prior to it if you use it (0 if you don't have a worst case number). It's included verbatim in the web output, so you can include HTML if you wish to do something like link to information about a bus route.