1 / 13

Implementing MMUCC Data Standards for Traffic Records Analysis\

This report details the implementation process, challenges, and benefits of adopting new MMUCC data standards for traffic records analysis. It covers data mining implications, summary statistics, and training considerations for improved data quality. The document emphasizes the importance of accurate data collection, editing, and validation procedures to enhance crash analysis outcomes. The experience of Iowa's DOT in transitioning to MMUCC standards is highlighted, showcasing the impact on crash analysis and statistical evaluations.

katherineg
Download Presentation

Implementing MMUCC Data Standards for Traffic Records Analysis\

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. MMUCC Implementation:Report from the Field Processing the New MMUCC Data: Implicationsfor Data Mining and Summary Statistics(or Dealing with the new MMUCC)Traffic Records ForumSession 17July 2004 Michael D. Pawlovich, Ph.D., P.E. Traffic Safety and Crash Analysis EngineerOffice of Traffic and SafetyIowa Dept. of Transportation Michael.Pawlovich@dot.state.ia.us

  2. Recent History – 2001+ Main Form • MMUCC-based form (98+% compliant) • Last overhaul  1979 • One form (1979 w/ truck/bus) – front/back • Form look/feel maintained • Same/less data fields Supplement Code Sheet

  3. Development • Began in March 2000 • Multi-disciplinary working group • Engineers • Enforcement • Behavioralists • Feds: FHWA, FMCSA • Others • Iterative process • 33 electronic versions of crash form • 17 electronic versions of code sheet • Implementation Jan. 2001 • Paper form immediate • TraCS lagged a couple months  distribution

  4. Post 2001 • TraCS enhancements continue • Most non-MMUCC-related • “Vanilla” MMUCC • APS development – December 2002 • Data entry/initial checks of 2001 – June 2003 • Edit/validation process – June 2003 thru July 2004 • Today • 2001-2003 data available/disbursed • 2004 real-time – edits ongoing • Summary • Replaced 25 years of prior development in 3 ½ years – in-house

  5. Edit/Validation Batch Process • Euphemistically – “end of year” edits  No Longer!!! • Internal Iowa DOT crash edit/validation post-processing • Edits go to data quality/consistency • Invaluable for analyses • Essential for informed implementation • Some edits may become TraCS validations • Data quality at scene • Requires training!!! • Edits/validations for 2004+ done weekly or better

  6. DB2  PC Process (SAS Modular Code) DB2 … (13) Accident Vehicle Insurance Owner Injured Location etc. (complete) (developing connection paths) Access … (27) Shapefile Loc/Time Driver Vehicle Injured Non-motorist etc. (complete) (accessing and downloading) View … (27) Shapefile Loc/Time Driver Vehicle Injured Non-motorist etc. (complete) (PC manipulations/additions) PC … (28) Shapefile Loc/Time Driver Vehicle Injured Non-motorist etc. (edits/validation/clean-up) Edits • 4 types: location, missing, invalid, cross-validation • 5 report types: TraCS, officer paper, driver, animal (entered/blank) – problem tracking • 5 severity levels: fatal, major, minor, possible/unknown, PDO – prioritization

  7. Cross-Valids (a partial listing)

  8. Training Issues • Current training  deficiencies identified • Training document revision underway • Plans: • Revised document • Training sessions • WWW site • Newsletter • Variety of content: • How to use w/ collection scenarios • Examples of data analysis (why it’s important) • Reports on deficient/incorrect collection

  9. Post Edits/Training • Disburse the data  users/analysts • Gather notes of the process – what worked/what did not • Consider analysis tool/resource updates • Take a long break!!!

  10. Summary for collectors and analysts • Develop a clear, concise form • Data collection training essential – documentation & live • Include data collection/input/entry personnel • Develop a process to disburse data to analysts • Redesign edit/validation process • Analyst training essential consistency of interpretation required better understanding of form ≈ better entry/less editing remove non-reportable & unessential fields separate personal identifiers derive certain fields – roadway and crash develop GIS coverages recreate and improve historical processes  look for potential improvements in data collection new data element dictionary – catered to form help sheet for new/adjusted data elements explanation of new data fields (e.g., SoE, MHE, FHE)

  11. Iowa’s MMUCC Experience • Spurred revamping of Iowa’s form • Simplified data collection • Complicated data editing/validation and analysis • Not bad…just more challenging • More training required throughout process • Analysis tools adaptation required • Summary: • Individual crashes more understandable • Aggregate analysis more complicated

  12. Analysis/Statistics • Just completed edit/validation process • Some use of partially edited data • Initial 4’ paved shoulder evaluation • 4  3-lane conversion • Expressway intersections • High-speed, signalized expressway intersections • Iowa DOT District personnel analyses • Outside data requests (city/county/citizen) • CTRE’s ITSDS  GTSB • Initial SICL

  13. Contact Information/Website • Michael.Pawlovich@dot.state.ia.us • Dr. Joyce Emery: Joyce.Emery@dot.state.ia.us • Websites: • Crash analysis resources: http://www.dot.state.ia.us/crashanalysis/ • Office of Driver Services: http://www.dot.state.ia.us/mvd/ods/ • CTRE’s ITSDS: http://www.ctre.iastate.edu/itsds/

More Related