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.
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.
* Sorry, bad joke.
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.
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.
The whole reason for wanting to perform OD table estimation is to minimize errors in whatever OD table we already have. That “prior” 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’t 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’t 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 “reasonable” 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.
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.
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: 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.) OD 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.
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.
- 3.2.2.1 Origin-Destination Table Estimation from Traffic Counts
- 4.4 Forecast Accuracy (parts)
- 5.7 Computation Technology Issues and Opportunities (parts)
- 6.11 Model Refinement with Origin Destination Table Estimation
- 6.12 Refinement with Origin-Destination Table Estimation, Small and Wide Areas
- 7.2 Windowing to Forecast Traffic for Small Areas
- 11.1.8 Using Windowing with Synthetic OD Table Estimation to Develop Turning Movement Forecasts at Multiple Locations
- 11.2 Case Study #2— Network Window
While you are at it, pause for a moment at Figure 4-14. This graph was originally published as a rough sketch in 1990 and the bottom curve has not budged since, as far as I can tell. This curve tells us the BEST we can do in fitting our OD tables, not the worst. Having too many links fall below this curve is deceptive.
So I wouldn’t mind hearing opinions as to how such as set of strong guidelines could be written, disseminated and enforced.
Alan Horowitz, Whitefish Bay, Wisconsin, August 3, 2015