Reporting Discrepancy on Cumulative Summary Tab

[cthomas]

I have a question about the reports that Tru-Traffic is generating.

If I generate a report using all the travel time runs in the attached file (25 before, 28 after, and 13 neither) for the subsection from Litzsinger to CP#2 (MO 34), the report (340_MD_Report2.pdf) tells me that there is 6 Neither/12 Before/ 14 After for NB runs, 7 Neither/ 13 Before/ 7 After for SB runs and which results in a total of 13 Neither/ 20 Before/ 9 After for all runs. That math doesn’t add up for the before (12+13=25 not 20) and after (14+7=21 not 9) runs. When I uncheck all of the runs that Tru-Traffic does not recognize as part of the cumulative total and generate a report, I get what I would expect from the NB runs and SB runs data set (as seen in 340_MD_Report1) with the number of NB and SB runs added together totaling the number of runs in the Cumulative Summary. What is interesting is that Tru-Traffic is showing a different number of runs between the two reports for the direction summaries, yet when you look at the data in the direction summary tables between the two reports, the software is outputting the exact same data (NB summary table in Report 1 has the same data as the NB summary table in report 2). Why is the software showing more runs for the directional summary report than it should, yet not outputting any different results in the table?

While investigating this issue, I also noticed that if a travel time run is stopped within the intersection extents of an intersection, but before the node shown in the network view the data from the run does not get included in the summary tables. However, if a travel time run is stopped within the intersection extents, but is beyond the node shown in the network view, that the data from that run gets included in the summary report. I presume that the node is representative of the middle of the intersection and that the travel time run has to pass that point for it to be recognized as a run when generating a report. Is that the case?

[bullock]

It seems that some of your runs start downstream of the beginning of the arterial subsection, and others don't make it to the end of the subsection. You can identify these looking at the Details Tables of the TT&D report. There's a table for each run. Scroll through looking for runs that start downstream of the first intersection, and look also for runs that end before the last intersection.

The Summary tables show the number of runs link by link, with a possibly different number of runs for each link. Look at the final link in each direction to see the count of runs that make it end to end through the entire arterial subsection. That number matches the one on the Cumulative Summary, which summarizes only those runs that make it end to end through the subsection.

A trip log must pass the center of the red circle (or intersection extent) in order for Tru-Traffic to determine that it passes through the intersection. If it starts downstream of the center, or stops shy of the center, Tru-Traffic thinks it didn't go "through" that intersection.

[cthomas]

I realize that if I look at the last link on the direction summary tabs that it will tell me the count of the number of runs that make it through he entire arterial. The issue I have with the way that the report is currently showing the data on the Cumulative Summary tab is that it is very misleading. I have been using this software for 10 years and just noticed that the tables are not based on the number of runs that the report states are in each direction. If I run a report and look at the data in 340_MD_Report2.pdf for the Northbound direction, I am going to see that there were 14 after runs. Then I look at the table and see all the data summarized for the Northbound runs, which I have been thinking is based on 14 after runs, because that is what is shown to me above the table. I now know that this is not the case, because the table shows that each data set (before/after/etc) is based on ‘n’ number of runs. I have found this to be very misleading. I would expect the number displayed above each table to be the number of runs that the data in the table is based upon. There is nothing on the Cumulative Summary tab that would inform me, as a user, that the number of runs above the table is not what the data in the table is based on other than me making that observation. I cannot be the only person who has overlooked this. There are probably many users who are currently even unaware of this. I think that this can be a problem if a user generates a report and only looks at the number above the table to verify that they have collected enough runs for each direction, but doesn't realize they may not have if the 'n' value in the table does not match the number shown above the table. Why is it that the data above the table that tells you the number of runs does not equal to the value of ‘n’?

Yes, there are a number of runs that don’t traverse every intersection in the file. Those runs that don’t traverse all the intersections only show up in the directional summary if they pass through the first intersection. For example, there are a number of southbound trips that start after the first intersection and before the second intersection, but the software doesn’t include them in the Southbound Summary report. Each intersection segment shows the exact same number of trips for the southbound data, while there is only variation on the last segment for the northbound data for the last segment, because some of the runs ended before the last segment.

It seems to me that the information on the directional summary tab should include all data points on a segment to segment basis (regardless of if the trip log passed through the first intersection), which it is not. We have 7 after trip logs for southbound that pass through the last 7 study intersections, but not the first study intersection. As a result, these do not get included in the southbound summary data because they do not pass through the first segment. That is a lot of good data for the last 7 intersections that is not being utilized. Why is it that the software will not include a trip for in the direction summary tab if it doesn’t pass through the first intersection?

[bullock]

I see what you mean now, and I agree. Sorry, I'd misread your question and was looking only at the n=... numbers shown in column 1 within the table and comparing those not to the numbers in the table caption but rather to their corresponding numbers for upstream links in the Directional Summary tables.

I'll look further into that. Right now, it looks like a bug, and if confirmed, I'll fix it.

Regarding why the software includes a trip for in the directional summary only if it passes through the first intersection, the short answer is that the table, as it's designed, can be either consistent or complete. I decided that consistency was more important. Making it complete both complicated and confused the meaning of the "cumulative" columns, and I thought it too misleading when grouping the two different types of columns together in a single table.

The policy, as you know, is that the Summary page of the TT&D report summarizes only those trip log runs that participate in calculating the various "cumulative" columns (e.g., CTT). This rule applies even though some of the runs thereby excluded should, at first blush, at least be included in the various link-specific columns (e.g., TT).

When trip logs enter the artery downstream from the first intersection, to be complete, and include those in the rows for downstream links, would either confuse the meaning of the n=... number in column 1 or require two n=... values, one for the link-specific columns and another for the cumulative columns. That is, these runs would apply to the link-specific calculation (average TT), but not to the cumulative calculation (average CTT). With the rule stated above, it's all or nothing. If the trip log is excluded from the cumulative calculation, then it's also excluded from even the link-specific calculation. Can't participate in CTT, so disqualified from TT.

With the way the TT&D report shows the n value (n=2 or n=3) just once for all columns, I decided it would be confusing or explicitly misleading to use a different set of trip log runs for calculating the cumulative columns vs. the link-specific columns. This seemed worse to me than being implicitly misleading, which is to use the rather arbitrary "consistency rule" that the link-specific columns and the cumulative columns shall both summarize the same set of trip log runs. At least this way, the user has some control (by generating TT&D reports for selected subsections of the artery) over what runs get included in both.

The other ("completeness") way, the user could use subsections to choose only those trip log included in the cumulative columns, the link-specific columns would unconditionally summarize all trip log runs, independent of the selected subsection, and the header column for each row in the summary report would need to show two values for n, one value for the cumulative columns and another for the link-specific ones. At the time, at least, this seemed to present more confusion than just enforcing a consistency rule, however unnecessary.

I'm open to revisiting this policy, if you want to suggest a better design or argue that it'd be worth whatever trade-off in order to get complete (if inconsistent) summaries when possible.