Below are the first 10 and last 10 pages of uncorrected machine-read text (when available) of this chapter, followed by the top 30 algorithmically extracted key phrases from the chapter as a whole.
Intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text on the opening pages of each chapter.
Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.
Do not use for reproduction, copying, pasting, or reading; exclusively for search engines.
OCR for page 55
56
APPENDIX G
Additional Feedback on Schemas
and UML Models
Comments from the TransXML community were sought The safety schema should include these and other data
on the UML models through August 30, 2005, and on the about the physical condition of the roadside and the evidence
TransXML schemas through December 31, 2005. Comments of the crash dynamics.
received beyond those dates could not be incorporated into The TransXML effort should develop draft schema additions
schema and sample applications developed in the course of for these needs rather than just passing on the suggestion to
this project. This additional feedback has been collected in NHTSA.
this appendix so that it can be addressed in future TransXML
development.
Additional Comments from Reviewer #2
G.1 Safety Business Area The comments below refer to the UML models docu-
mented in the section labeled "Highway Information Safety
Additional Comments from Reviewer #1
Analysis Package" which can be found on pages 73 through
The existing schema need to be supplemented in the area 100 of the UML Model Appendix to this report.
of site information. There is little allowance for informa-
tion that is needed for accident reconstruction and safety · Page 83, 7.2.23: urbanRural (Area Type) could be expanded
analysis. The length, location, and orientation of skid marks to include suburban
are crucial to estimating the speed of a vehicle and the
driver's actions at the time of the accident. The type of With respect to Intersections:
any barrier that was struck is essential to studies aimed at
evaluating the performance of those barriers. While acci- · The actual geometry of an intersection cannot be
dent reports may be available, a mechanism is needed to
determined/reconstructed from the data elements in the
sort to the ones that involve the specific barrier system of
schema (e.g., skew is not represented).
concern.
· The "Intersection" is a sub-element of "RoadLocation"
There is still a lot to be studied in regard to acceptable
widths of clear zones and clear areas. Accident data is key to and has two attributes named "locationReferenceMinor
those studies. The schema needs to allow the lateral travel of Road" and the "minorRoadName." This implies that the
errant vehicles to be documented, as well as the sideslopes road that is identified by "RoadLocation" is the major
of the clear area. Quality of the clear areas is also an open road for all of its intersections, which is not necessarily
question, as higher center of gravity vehicles are less likely true. The model cannot represent situations in which
to perform well on sideslopes that have been considered the roadway under analysis is the minor road at an inter-
acceptable for traditional personal vehicles. The schema section. This could be acceptable if an assumption is
needs to allow recording of both sideslopes and vehicle added to the model that an intersection is counted as a
rollover information. sub-element for a roadway only if the roadway is the
The amount of damage to a barrier system is a key piece of major road.
the accident record and also valuable to the maintenance · "Corner" data are not in the model.
effort to repair that guide rail. · "Turn Speeds" are not in the model.
OCR for page 56
57
With respect to Roadway Segments: G.2 Survey/Design Business Area
Additional Comments from Reviewer #1
· The following elements used in IHSDM are not explicitly
modeled: The comments below refer to the UML models docu-
Roadside hazard rating; mented in the section labeled "Geometric Roadway Design,
Ditches (defined implicitly via the cross-section 2nd Draft," which can be found on pages 172 through 254 of
elements); the UML Model Appendix to this report. The page number
Obstruction offset; references shown below refer to the numbering scheme used
Shoulder width and slope; within that section of the appendix, not to the page numbers
Curve widening; of the appendix itself.
Bridge presence/width;
Speeds: design and 85th percentile; and · Intersections are not modeled (but intersections are cov-
Percent RVs. ered in the "Highway Information Safety Analysis (HISA)
· "Average lane width" is provided (which includes the aux- Package").
iliary lane width), but the width of individual lanes cannot · Page 38, "Line," "dir[0. .1]" attribute: How is the direction
be defined. of the line defined (e.g., using N/S/E/W, azimuth, etc.)?
· Turn lanes are not explicitly defined, except for · Page 41, "Spiral," "Recommendation," line 7: Should the
TWLTLs. Under the Auxiliary Lane Type code list, there references to "begin length" and "end length" of a spiral
are "accelerationLane" and "decelerationLane"--are these instead be to "begin radius" and "end radius?"
meant to represent turn lanes? · Page 55, Superelevation>Carriage Way>Lane: Lane width
· Driveway Density is provided, but the locations of indi- is entered indirectly via offsets, but there does not appear
vidual drives cannot be specified (which might be needed to be a way to identify lane type (thru, turn, climbing,
for future IHSDM/HSM models). passing, etc.).
· It is unclear whether more than one auxiliary lane can be · Page 55, The proposed Superelevation model cannot model
modeled per direction. Also the relative placement of a break in cross-slope within a lane. (Not sure if this is
the auxiliary lane with respect to the thru lanes cannot be important.)
modeled. · Page 56, "Superelevation": For "standard AASHTO" tran-
· Only one shoulder type per direction can be modeled. sitions, it appears that the "beginStation" and "endStation"
Also, the "Composite" shoulder type that is included in attributes are redundant with the Critical Transition sta-
the schema was eliminated from the IHSDM roadway tions related to Transition Types "entryNormalCrown"
model. and "exitNormalCrown."
· The "Bikeway" attribute for each direction of a Road · Page 59, "Transition Type": The "specialTransition" attri-
Segment seems to duplicate the "bicycleLane" attribute in bute is defined as "Any special transition location." It is
"Auxiliary Lane Type." unclear whether the type (e.g., beginning of alignment) is to
· Curvature, superelevation, and grade data duplicate ele- be specified for the transition location, or just labeled as
ments in the Geometric Roadway Design section. "special transition" regardless of type?
· Page 64, "CrossSect": What does the "name" of a cross
section refer to?
Additional Comments from Reviewer #3
· Page 69, "DesignCrossSectSurf ": What does "typical width"
The developed Safety Schema do not cover crash dynamics refer to?
or roadside geometry concerns in any place close to the level · Taper locations (e.g., begin/end of turn-lane taper) are not
of detail that I was hoping for. My major motivation far par- explicitly modeled. However, they could be modeled using
ticipating was to ensure that the developed schema adequately cross-sections, if the "critical" points are captured.
addressed sideslopes, backslopes, guide rail types, terminal · Shoulder width and slope are not modeled. Only one
and attenuator types, etc. That did not happen. shoulder section can be modeled per side.
