At some point in the process of performing the contract that led to NCHRP Report 716 its authors (or maybe its project panel) deviated from what many of us thought the contract was all about. Personally (I will not involve a bunch of anonymous confidants), I was expecting NCHRP Report 716 to be an update of NCHRP Report 365, which was itself an update of NCHRP Report 187. The major theme of the two earlier reports was parameter transferability. That is, there are some universal, approximately correct, travel model parameters that can be applied most anywhere with some degree of success. The major theme of the most recent report is parameter untransferability.
So rather than saying, “here are good equations containing good parameters you can use for your model”, they said “here are a bunch of mutually incompatible equations with a variety of incompatible parameters that someone or other has found useful for their travel model – you choose.” As the Whooper commercial emphasizes, people want options. Who can blame the authors of NCHRP Report 716 for providing options?
I will leave this rhetorical question hanging while I dwell on the consequences for QRS II users.
A typical QRS II users does not want a lot of flexibility. He or she wants to know with some degree of certainty what will work and what will not work. A typical QRS II user wants to be sure that their model meets best-practice standards and will pass muster at public hearings and at peer reviews. A typical QRS II users does not have a lot of time or budget to devote to model calibration, so he or she is often seeking strong advice from experienced modelers as to what to include and what values should be set. A typical QRS II user could read NCHRP Report 716 cover-to-cover and still wind up confused as to what is correct and what is not correct.
So NCHRP Report 716 presents a real conundrum for the software developer (me in this case). Do I pick and choose from the menu of options in NCHRP Report 716, eliminating those that seem odd or erroneous, or do I take everything and let the buyer (i.e., QRS II user) beware. Prior to NCHRP Report 716, I was very reluctant to put anything in QRS II of which I did not have a high degree of confidence. NCHRP Report 716 has forced me to change a bit. So you might ask, how does that shift in philosophy manifest itself in the software?
First, let’s discuss the automobile ownership step. NCHRP Report 716 provides 4 different parameter sets that do not show any discernible consistency. Since automobile ownership can be thought of as an optional preprocessing requirement, I decided to leave it out of QRS II. Verdict = OUT.
Next is trip production with cross-classification. Cross-classification has been a conventional method for decades, but QRS II only added it when NCHRP 716 was first published. However, NCHRP Report 716 could not decide upon the definitions of rows and columns, so it published a mishmash of tables with a variety of rows and columns. QRS II allows users to define their own rows and columns, but those definitions must be constant across all trip purposes. Default parameters are taken from rows as vehicle and columns as household size. Verdict = IN, mostly.
Automobile occupancy and trip attractions were essentially unchanged in structure from earlier reports, so QRS II users can simply insert their own parameters. I updated the automobile occupancy parameters, but left the trip attraction parameters as they were, since NCHRP Report 716 was inconclusive. Verdict = IN.
Last is mode split. NCHRP Report 716 is into nested logit in a big way, but there is no firm recommendation as to modes to include or nesting structures. Here, it seems, is a place for maximum flexibility. QRS II replaces its old multinomial logit step with a nested step that can be configured to almost any structure someone might want. However, configuring this step is not simple, even though there is a logical flow through QRS II’s various dialog boxes. QRS II defaults to a single mode (auto/highway) and a generic set of parameters. Thus, most QRS II users won’t need to concern themselves at all with nesting, but it is there when desired. Verdict = IN.
Alan Horowitz, March 25, 2015