tru-traffic.com

We have a project that is currently a multi-lane facility with regular NEMA phasing at the corridor signals. The project will convert the corridor from the existing bi-directionally linked signals to a Super/Synchronized Street with new signals at the U-turn bulb outs. My question has to do with developing a strategy to collect “Before” trips through the existing system, and then collect “After” trips through the new system. This could be said to be a comparison between apples and oranges. The Super/Synchronized geometry will introduce “one way” operations which are mutually exclusive between cardinal directions. In short, the eastbound lanes and signals will operate independently of the westbound lanes and signals. Each of the directions will be able to operate at different cycle lengths because of the independence between cardinal directions. For example, eastbound AM could be a 90 second cycle while westbound could be 120 seconds.

I believe Tru-Traffic will collect the trip logs in a usable manner if I take them separately developing a list of eastbound trips and in the same list westbound trips so noted in the file. This should also permit collection of trip logs in the same manner for the “After” trip logs. My dilemma arises from having to introduce the location of the new signals for control of the bulb-outs into the database. If the new signal locations can be added to the listing of signals database will the addition in anyway effect the “before” trips already collected? If there is no impact on the “before” trip logs then I should be able to run the evaluations for Eastbound independent of Westbound thus producing two sets of output measuring the benefit of the revised operations by cardinal direction.

Your insight is sought and greatly appreciated.

As you hoped, the number of signals and their locations do not affect the “before” or "after" trip logs.

Tru-Traffic's parlance distinguishes between a "trip log" and a "run". "Trip logs" are not affected by routes or nodes or their locations. "Runs" are created on the fly (and re-created as needed) by comparing a trip log to a route (with its nodes and their locations). Each time you add a new trip log, or edit one, or add another route, or add a node to a route, or delete one, or move one, Tru-Traffic reanalyzes everything and finds all the runs. Runs are not saved in the file, only the trip logs and the routes.

In the same *.Dgm file, you might create a route showing the "before" nodes at their current locations. And add routes, maybe an EB one and a WB one, with the "after" nodes at their eventual locations. And add yet another route showing just the common nodes (perhaps just the starting and end points). Using a single set of before and after trip logs, Tru-Traffic will find all the runs that apply to each of these routes. Depending on how much things change, the runs for the "before" trip logs along the "after" routes may not make much sense (e.g., the node-to-node travel times may introduce more confusion than what they're worth), and the same might apply to the runs for the "after" trip logs along the "before" routes. But I would think that all the runs, before and after, along that common route (with just the common nodes) would be just what you're looking for in terms of travel time analysis.

For most of the columns in a TT&D report, the signal timings (e.g., cycle length) has no direct affect, so for those columns, it doesn't really matter what timings you put in that common route.