Comments:

Flat Nested Threaded Embedded

Oldest First Newest First

Author	Thread:
Michael Griffith	Scope of Highway Inventory Safety Schema Posted: Tuesday, November 16, 2004 1:09 PM (EST) I recommend you consider the data dictionary for SafetyAnalyst.  For more information about SafetyAnalyst, please visit www.safetyanalyst.org Thanks- Mike Griffith
James Cheeks	Scope of Highway Inventory Safety Schema Posted: Tuesday, November 30, 2004 10:53 AM (EST) There has been a considerable amout of work that has been done in the area of the ITS Standards dealing with safety the Traffic Management Data Dictionary  (TMDD) and Message Sets for External Traffic Management Center Communications (MSETMCC) and the IEEE Incident Management (IM) Standards.  These Standards can be found on the ITE Website in the Technical area under Standards www.ite.org and the IEEE website www.ieee.org.
Al Butler	Location specification Posted: Tuesday, December 07, 2004 11:10 PM (EST) The single most critical piece of information about a crash is where it happened.  Location is the central organizing element of a crash database since crash frequency is the most utilized method of identifying sites requiring attention.  The XML project is correct to look towards the ISO linear referencing standard and its application in the current draft FGDC (nee Geospatial One-Stop) data exchange standards.  However, those standards are not yet stable and provide only a small part of the answer for locating crashes.  For example, the linear referencing standard is generally applicable only to state DOT data sets, as most local governments utilize either an address-based method of location or intersection/midblock distance approach.  A wide variety of location referencing methods must be accommodated and some mechanism of location translation provided for data from multiple jurisdictions to be integrated. We found several years ago in a review of crash reports filed in Florida that 30% had errors or misleading information about where the crash occurred.  This finding indicates that a central requirement for any useful data mining application, such as anticipated by an XML standard, is to be able to reconcile inconsistent location information.  Many times, though, only a person with local knowledge would be able to recognize such errors and inconsistencies.  A state agency blindly transcribing exactly what is on the crash report will not be a useful data source for transportation analyses.  The XML standard should include a means of describing the manner in which location and other crash data have been “scrubbed.“ A related problem is the common practice for law enforcement officers and others completing crash reports to use big measurement increments, like “1/4 mile from Jones Dr.“ or “1 mile past the city limits.“  GPS-derived coordinates can help to a degree, but they will often fail to properly identify the street on which a crash occurred in dense urban areas.  Besides, many crashes that should be associated with an intersection, such as rear-end crashes occurring at the end of a traffic queue, may actually be closer to a minor intersection unrelated to the proximate cause of the crash.  Simply accepting the GPS coordinates as the definitive description of location will place such crashes in the wrong place from a causal perspective.
Eric Ziering	Scope of Highway Inventory Safety Schema Posted: Thursday, December 09, 2004 9:02 AM (EST) Thank you, Mike.  I don't see the data dictionary you mention on the Safety Analyst site - could you send me a URL, or forward the appropriate documents directly to me at eziering@camsys.com?  Thanks again.
Eric Ziering	Scope of Highway Inventory Safety Schema Posted: Thursday, December 09, 2004 9:29 AM (EST) James - thanks for your input on this.  The IEEE 1512 work by the Incident Management Working Group is clearly relevant and will be considered in the course of this work.
Eric Ziering	Location specification Posted: Thursday, December 09, 2004 9:40 AM (EST) Al, these are excellent points that apply to both the Crash Report schema itself, and to any demonstration applications developed under the Highway Inventory Safety schema.  I particularly like your notion of encompassing in the crash record schema information encapsulating the manner in which location information was captured and/or scrubbed, so that attempts to link crash data to underlying highway inventory data are sufficiently informed.
Terry Hale	Scope of Highway Inventory Safety Schema Posted: Friday, December 17, 2004 11:42 AM (EST) I may be wrong on this, but I suspect that very few, if any, states have roadway safety information that is sufficiently detailed or accurate to correlate to specific incident locations.  To be admissable in a court case, I would expect that only on-scene recording of the actual physical conditions at the precise location would be acceptable. Unless a significant number of states can be shown to have detailed, accurate, and up-to-date highway safety inventory data, I will be opposed to spending effort on either of the applications listed.  I am in favor of making sure that we have a schema that allows recording of the safety information.  Initially, the schema can be used to record information at an incident location.  If states ever have the resources to maintain detailed comprehensive information in a statewide inventory, the schema should facilitate that. Terry Hale, NYSDOT
Eric Ziering	Scope of Highway Inventory Safety Schema Posted: Friday, January 07, 2005 10:51 AM (EST) Terry - Your point about the accuracy of roadway safety information is well taken.  At the same time, however, widespread deployment of XML technologies (over a long period of time, admittedly) ought to result in overall improvements in data quality as a result of greater use and accessibility.   Ideally (from an information modeling point of view), data on the safety-related characteristics of highway sections ought to live in inventory systems rather than in accident reports.  These data also ought to be immediately accessible (and updatable when incorrect) at the time an accident is reported or an accident report is filed.  The intent of the sample applications is to demonstrate how TransXML can facilitate such linkages and make them productive.   Perhaps we should consider a sample application that addresses this specific opportunity more directly. Finally, remember that the purpose of XML schema is not to dictate how information should be reported or recorded - nor even to dictate the specifics of how it is stored - but to provide a logical framework for describing and sharing this information. Many thanks for your input, and your continued participation in the TransXML effort.
Terry Hale	Scope of Highway Inventory Safety Schema Posted: Friday, January 07, 2005 1:39 PM (EST) Eric - I see the data quality problem as being related to the difficulty of obtaining the raw data, not an issue of the technology for storing it.  I don't know of a state agency that has, or will have, sufficient resources to regularly survey embankment slopes, clear area widths, site distnces, with sufficient areal and temporal frequency to make the data sufficient to include in an accident report. I see a primary benefit of this schema as being the ability of states to compare and aggregate accident data, particularly roadside accidents, so that trends can be identified that would not otherwise be apparent in the data of a single state.  If sample applications are to be prepared, I would like to see real data from two different states migrated into the XML schema and then compared and integrated.
Eric Ziering	Scope of Highway Inventory Safety Schema Posted: Friday, January 07, 2005 1:49 PM (EST) OK, got it.  That's a good idea for the sample application.
Paul Scarponcini	Scope of Highway Inventory Safety Schema Posted: Wednesday, January 12, 2005 7:47 AM (EST) Terry, Point well taken about the admissability of roadway characteristics being admissable in court. However, this information may be useful in analyzing crashes after the fact to determine causality patterns. Such information can be verified against the actual crash report if it is available in the crash report. But I suspect that the DOT has more information about the roadway than the reporting officer is likely to log. Paul Sacrponcini, Bentley Systems
Paul Scarponcini	Location specification Posted: Wednesday, January 12, 2005 11:13 AM (EST) Sorry for the delay in responding. Good idea to include some metadata about the crash location and I agree that a GPS location is not sufficient. A linear location is preferred as it includes the linear element (street, route, or whatever) that the location is along - if you follow the ISO standard. BTW, the standard does support address and intersection/midblock support. Following the Generalized Model for Linear Referencing, it was intended to support as many LRMs as possible and I have yet to meet one that it does not accommodate.
Stanley Trimble	Scope of Highway Inventory Safety Schema Posted: Wednesday, January 12, 2005 3:43 PM (EST) FAMU/FSU College of Engineering is current designing a traffic crash reporting system for Florida using the TraCS National Model.  We are using a location tool designed by CTRE of Iowa University to obtain the location of the crash.  We have GSP units attached to the laptops but we do not record the reading on the crash report.  On our form, the user clicks a button to start the locator tool.  When the locator tool starts, it takes the reading from the GPS unit, draws a map from GIS data then indicates where the GPS reading is.  This is close to the crash location. The average accuracy of the units we have been purchasing is about 25 feet. The officer clicks on the location of the crash on the map.  In a dense urban area this may actually be on a different street than the GPS unit has indicated.  The locator tool passed to our form data on the location of the crash.  We use the Lat Long from the GIS data on our form instead of the GPS Lat Long.  Included in the data is the name of the street of occurrence and the cross street.  Getting the street name from the GIS data means the name for a road will be consistent our crash report system.  When some roads can have several name: a local name, an official name and several US and state numbers.  Constant names can be a problem.
Terry Hale	Scope of Highway Inventory Safety Schema Posted: Wednesday, April 27, 2005 1:10 PM (EST) The recently published NCHRP Report 537, Recommended Guidelines for Curb and Curb-Barrier Installations has some interesting content, particularly on pages 32 and 33.  “Finally, Michigan provides an additional file not found in any other HSIS state: a Guardrail Inventory File...it has not been maintained by the Michigan DOT since 1992.  However, because this is the only known guardrail inventory file that can be linked with other roadway and traffic data...” Of more constructive note are the references on page 32 to the National Automative Sampling System - Crashworthiness Data System which “contains detailed crash reconstruction data collected on site by expert investigators.”  While such detailed data may not be needed in most cases, it would be good to see one of the schema, possibly the crash report schema, set up to permit standardization of the data into TransXML.   A related data system is NHTSA's National Automative Sampling System - General Estimates System.  This may have some good data structure as well.
Frances Harrison	Scope of Highway Inventory Safety Schema Posted: Wednesday, April 27, 2005 3:29 PM (EST) Terry- If you are interested in the Michigan guardrail file, you can find complete documentation on the FHWA HSIS web site - http://www.hsisinfo.org/pdf/MIvol1.pdf Our approach to the HSIS information was to use the FHWA SafetyAnalyst data structure as our base for the Highway Inventory for Safety Analysis schema -The SafetyAnalyst data structure was developed with the HSIS data elements in mind, with an eye towards common data elements that are needed for conducting highway safety analyses. We looked at both the NASS-GES and the CDS, but chose to rely more on FARS and MMUCC as the primary inputs to the crash schema.  The NASS is based on a sample of policy crash reports, and most of the elements are represented in MMUCC and FARS (though issues remain with respect to harmonization across the different data element definitions).