Protocols for Collecting and Using Traffic Data in Bridge Design
Bibliographic record
Abstract
This report documents and presents the results of a study to develop a set of protocols and methodologies for using available recent truck traffic data to develop and calibrate live load models for Load and Resistance Factor Design (LRFD) bridge design. The HL-93, a combination of the HS20 truck and lane loads, was developed using 1975 truck data from the Ontario Ministry of Transportation to project a 75-year live-load occurrence. Because truck traffic volume and weight have increased and truck configurations have become more complex, the 1975 Ontario data do not represent present U.S traffic loadings. The goal of this project, therefore, was to develop a set of protocols and methodologies for using available recent truck traffic data collected at different US sites and recommend a step-by-step procedure that can be followed to obtain live load models for LRFD bridge design. The protocols are geared to address the collection, processing and use of national weigh-in-motion (WIM) data to develop and calibrate vehicular loads for LRFD superstructure design, fatigue design, deck design and design for overload permits. These protocols are appropriate for national use or data specific to a state or local jurisdiction where the truck weight regulations and/or traffic conditions may be significantly different from national standards. The study also gives practical examples of implementing these protocols with recent national WIM data drawn from states/sites around the country with different traffic exposures, load spectra, and truck configurations.
Fetched live from OpenAlex and de-inverted. Abstracts are not stored in this database: the inverted indexes are 8.6 GB of the frame’s 9.3 GB of text, and the host has 13 GB free.
How this classification was reachedexpand
Full frame machine prediction
Teacher imitationNot calibrated prevalence, not ground truth. Human validation pending. The Gemma side is a direct model label for every work in the frame, read from the title-only record. The Codex side is a classifier learned from the 10,348 direct Codex labels and calibrated to design-weighted sample rates; fields without enough sample support carry no Codex call. Candidate is the union of the two sides; consensus is their intersection. These outputs are machine_predicted_unvalidated and are not human labels.
Distilled classifier scores by category (both heads)
| Category | Codex | Gemma |
|---|---|---|
| Metaresearch | 0.094 | 0.101 |
| Meta-epidemiology (narrow) | 0.002 | 0.002 |
| Meta-epidemiology (broad) | 0.001 | 0.001 |
| Bibliometrics | 0.010 | 0.007 |
| Science and technology studies | 0.004 | 0.002 |
| Scholarly communication | 0.006 | 0.005 |
| Open science | 0.004 | 0.006 |
| Research integrity | 0.002 | 0.003 |
| Insufficient payload (model declined to judge) | 0.013 | 0.014 |
Machine scores (provisional)
The two teacher heads of the student model, read on this work. A score orders the frame for review; it never asserts a category, and the validation status ships verbatim with every row.
Baseline scores from an immature model (maturity gate not passed, 7 training rounds). Scores rank; they never assert a category.
score_only:v0-immature-baseline · verbatim from the scoring run: score_only means the number may rank works, and no category label ships from itClassification
machine, unvalidatedMachine predicted; a candidate call from one source (direct Gemma or distilled Codex), not a consensus.
How this classification was reached, model by model and score by score, is at the end of the page under "How this classification was reached".