{"id":144,"date":"2015-08-03T00:00:05","date_gmt":"2015-08-03T00:00:05","guid":{"rendered":"http:\/\/ajhassoc.com\/?p=144"},"modified":"2017-05-17T01:47:19","modified_gmt":"2017-05-17T01:47:19","slug":"we-really-need-strong-guidance-on-od-table-estimation-from-traffic-counts","status":"publish","type":"post","link":"https:\/\/ajhassoc.com\/index.php\/2015\/08\/03\/we-really-need-strong-guidance-on-od-table-estimation-from-traffic-counts\/","title":{"rendered":"We Really Need Strong Guidance on OD Table Estimation from Traffic Counts"},"content":{"rendered":"
\n

OD table estimation from traffic counts only makes sense if it is viewed as a method of statistical inference. Any other interpretation of OD table estimation causes splitting headaches.<\/p>\n

Now that we agree on this fact, we must also face the realization that there is a lot of junk masquerading as good technique. Short of requiring a license to practice OD table estimation (a POD, perhaps?*) we should at least arrive at a set of strong guidelines that when followed gives some hope of success and minimizes the chance of abuse.<\/p>\n

* Sorry, bad joke.<\/p>\n

Some of this already exists in various sections of NCHRP Report 765. I will list those sections for you later, but more is needed. A lot more.<\/p>\n

So maybe I have presumed too much by my assertion of the statistical underpinnings to OD table estimation. Think of a static OD table as a two-dimensional surface with points along that surface being interconnected in intricate ways. By our process of estimation we are trying to bend that surface without violating certain rules of interconnection. Moving one point often means moving others. Not so different a concept from linear regression where we rotate and shift a hyperplane to better fit observed data, I believe.<\/p>\n

The whole reason for wanting to perform OD table estimation is to minimize errors in whatever OD table we already have. That \u201cprior\u201d OD table could have come from theory, data, professional judgment or pure guesswork. Unfortunately, our traffic counts also have errors — lots of them. Some of these errors are due to miscounting, but mostly the errors come from various sampling misfortunes. (If you don\u2019t believe me, go to any traffic counting map, such as http:\/\/www.idot.illinois.gov\/Assets\/uploads\/files\/Transportation-System\/Maps-&-Charts\/adt_chicago.pdf, and look at daily counts on adjacent links along the same road.) Errors are even larger, relatively, for hourly (or shorter) counts needed for dynamic tables. So we don\u2019t want to overdo the tightness of our estimation; we only want to extract as much information out of the traffic counts as is reasonable. The definition of \u201creasonable\u201d varies greatly depending upon the source of the traffic counts. Hence, there is a need to give different counts different weights in the estimation process.<\/p>\n

The pot of gold is a better OD table than we would have had otherwise. Nonetheless, the same cautions apply to OD table estimation as to K-factors. The reasons for the adjustments may vanish over several years, so the long-term viability of the estimated OD table is questionable.<\/p>\n

All of this depends on having a really good traffic assignment method. Those intricate interconnections? They come from a traffic assignment. Poorly conceived aspects of an assignment can mess up the OD table estimation:\u00a0 bad delay relationships, bad network coding, incorrectly applied turn penalties, insufficient geographic detail, and a bunch more stuff not worth mentioning right now. (While I am not pointing my finger directly at you, let it be said that there are a whole lot of well-regarded agencies using traffic assignment methods that are woefully deficient.) \u00a0OD table estimation can make a really bad traffic assignment technique seem quite good by wall-papering over many of its flaws, so if you do not have complete confidence in your traffic assignment, stay well away from OD table estimation.<\/p>\n

So here is your reading list from NCHRP Report 765, keeping in mind that the subject is project-level travel forecasts, typically short- to medium-range, which are among the least troublesome with regard to stability and sometimes have nicely behaved networks to boot.<\/p>\n