Running time and travel time

Questions and discussions about operating Tru-Traffic

Moderator: bullock

Running time and travel time

Postby sandem » Tue May 10, 2011 2:18 am

I am having an issue with the output i.e. running time. My running time is more than the total travel time. I was checking to find out the reason why I am getting running time more than travel time, I figured that it is taking the user specified design distance instead of travel distance from the previous node. I have checked my synchro file where the distance from the previous node was fine. The same synchro file was saved as .CSV and then opened using Tru-Traffic and the output I am getting do not make any sense .

Can you help me fix this problem.
sandem
 
Posts: 1
Joined: Mon Jan 24, 2011 8:56 pm

Re: Running time and travel time

Postby bullock » Tue May 10, 2011 5:13 pm

You're correct that, by definition, the running time is the "expected time," or the user-specified distance divided by the user-specified design speed. As such, all runs show the same running time. The difference between the measured travel time and the running time is the delay, so if the user-declared distance and design speed are such that the expected time happens to exceed the travel time, then the delay is negative. We can think of that as running ahead of schedule.

Regarding the problem you've observed, here's some general guidance:

I've often seen problems in the accuracy of the travel distance after importing UTDF files. There are several reasons for this, but putting aside the details, a good strategy, I think, is to use your trip logs to set both the user-declared distance and the design speed.

Click the Get From Trip Logs button next to the distance box. The software will average the travel distances of the runs that you check. I like to sort them by distance, then if it's a straight link, choose the shortest distance in the list on argument that longer distances are probably reflecting GPS noise in the runs. If the link has curvature, then I usually check pretty much all the runs, excluding the outliers. I exclude the short outliers on argument that they're probably measuring the chord distance, not the arc. And I exclude the long outliers on argument that they probably have a fair amount of GPS noise affecting the distance measurement. Either way, it's often informative to study the distribution of distances over the runs, as it sometimes reveals runs that are either under-resolved or noisy -- candidates for either omission or clean up.

Click the ellipsis "..." buttons next to the speed boxes. Again the software will average the link speeds of the runs that you check, and again I start by sorting them by speed. In this case, though, I pretty much always choose just the fastest speed distance in the list, on argument that the others probably include delays that we don't want to design for.

Many users, including me, often prefer to get the free-flow speed, or design speed, by eye, looking at the peak instantaneous speeds along each link in a speed vs. distance plot (View: Plots from Trip Logs). Your eye can usually do a pretty good job picking an average peak speed from a cluster of run traces in the plot.

If that doesn't resolve the problem, please let me know.

Regards.
Greg
bullock
Site Admin
 
Posts: 218
Joined: Thu May 06, 2004 6:51 pm
Location: Pacific Grove, CA


Return to Program Operation

Who is online

Users browsing this forum: No registered users and 6 guests

cron